1

BCS-Certificate in IT

BCS – Higher Education Qualifications

Information Systems
ICTM Campus

- Uditha Priyanga -
 2

BCS-Certificate-IS

Information Systems
Software Process Models
 3

What is Software

▪ Software is a general term for the various kinds of programs

used to operate computers and related devices.

▪ program is a set instructions given to a computer, when

executed perform a particular task for the user or the computer
system.
 4

Characteristics of Software

▪ Software is developed or engineered, is not manufactured in the

classical sense.

▪ Although some similarities exist between software development

and hardware manufacturing, the two activities are
fundamentally different.
 5

Characteristics of Software

▪ Software is intangible – cannot touch

▪ Increase use will not introduce any defects
▪ Software is configurable – build by combining set of components
▪ Software does not wear out like hardware
▪ Can change the product easily by re-implementing it without changing
the design.
▪ Custom built - Most software is made upon contract.
 6
Generic Vs Bespoke

Generic Software Bespoke Software

Sold on the open market For a particular customer
Off the shelf products Custom built products
Less Expensive More Expensive
More reliable Less reliable
Immediate installation Delay due to high development time
More user friendly Less user friendly
User requirements are not completely satisfied Completely satisfies user requirements
Cannot accommodate future changes Can easily accommodate future changes
 7
Software Products Attribute

 Maintainability : Easy to change and Flexible to meet new

customer needs

 Dependability : Reliability (trust), Safety, Security and Should

not case physical or Economic damage in system failure

 Efficiency : Should not waste money & processer time

 Usability : Easy to use and Should have appropriate user

interface & enough documentation
 8

What is software Process

▪ A set of ordered tasks involving activities, constraints and resources that

produce a software system
▪ A process usually involves a set of tools and techniques.
▪ Also called the software life cycle
▪ It describes the life of a software product from its Inception to its
implementation, delivery, use, and maintenance.
 9

SDLC

▪ Systems Development Life Cycle (SDLC) or

▪ Software Development Life Cycle
▪ The process of creating or altering software systems
▪ Also include the Methodologies, Techniques and Tools used to develop
software systems.
 10

Why Process is Important

▪ Process is important because they impose consistency and structure on

a set of activities.
▪ The process structure guides our actions by allowing us to examine,
understand, control, and improve the activities that comprise the process.
▪ Processes are also important for enabling us to capture our experiences
and pass them along to others.
 11

Process Activities

Generic activities in all software processes are:

▪ Specification - what the system should do and its development constraints

▪ Development - production of the software system

▪ Validation - checking that the software is doing what the customer wants

▪ Evolution - changing the software in response to changing demands.

 12

Process Models

▪ Many process models are available in software engineering.

▪ Some are prescriptions for the way software development should progress
▪ Others are descriptions of the way software development is actually done.
▪ Many Software process Models available to develop software
 13

Type of Process Models

1. Waterfall model 6. Formal Development model

2. Prototyping models 7. V model
3. Incremental model 8. RAD models
4. Iterative model 9. Unified Process model
5. Spiral model 10. Agile Process models
 14

Waterfall Model

▪ First process model

▪ The stages are depicted, as cascading from one to another
▪ One development stage should be completed before the next begins.
▪ The model presents very high-level view of what goes on during
development process
▪ Suitable for projects which have clear and stable requirements.
 15

Waterfall Model

▪ Useful for developers to lay out what they need to do.

▪ Customers can easily understand the development steps and intermediate

products of development process with waterfall model.

▪ Many complex models are evolved from the waterfall model ,

incorporating feedback loops and extra activities.
 16

Stages of Waterfall Model

 17

Extended Waterfall Model

 18

Requirement Analysis

▪ The system’s services, constraints and goals are established with the
consultation with the users.
▪ This would include the understanding of the information domain for the
software, functionality, behavior, performance, interfaces, security and
exceptional requirements.
▪ Requirements are then specified in a manner which is understandable by
both users and the development staff.
 19

Software Design

▪ The design process translates requirements into a representation of the

software that can be implemented using software tools.
▪ The major objectives of this stage are
• identification of the software component
• the software architecture
• User interfaces
• Data structures and algorithms
 20

Coding / Development

▪ The design must be translated to a machine readable form.

▪ During this stage the software design is realized as a set of programs or

program units.

▪ Programming languages or CASE tools can be used to develop software.

 21

Testing

▪ The testing process must ensure that the system works correctly and
satisfies the requirements specified.
▪ The testing stages are
• Unit testing
• Integration testing
• System testing
• Acceptance Testing
▪ After testing, the software system is delivered to the customer.
 22

Maintenance

▪ Software will undoubtedly undergo changes after it is delivered to the

customer.

▪ Errors in the system should be corrected and the system should be

modified and updated to suit new user requirements.
 23

Advantage of waterfall model

▪ Clearly defined deliverables at the completion of each stage

▪ Deliverable of one stage are used as input to the next stage
▪ Increase visibility facilitate better monitoring and control of the project.
▪ Easy to assess the progress of the development process
▪ Well suited for large systems developments
▪ Supports maintainability by repeating some or all previous stages
 24

Problems of waterfall model

▪ Real projects rarely follow the sequential flow that the model proposes.
▪ It is often very difficult for the customer to state all requirements at the
beginning of projects.
▪ A working version of the software will not be available until end of the
development process
▪ One phase has to be completed before moving onto the next phase.
▪ Few business systems have stable requirements.
 25

Prototyping

▪ It is very difficult for end-users to anticipate how they will use new
software systems to support their work.

▪ If the system is large and complex, it is probably impossible to make this

assessment before the system is built and put into use.
 26

Prototype

▪ A prototype is a working version of the system that can be used to clear

the requirements.
▪ A prototype should be evaluated with the user participation.
▪ A prototype is a working model that is functionally equivalent to a
product
 27

Throw away Prototyping

▪ The objective is to understand the system requirements clearly.

▪ Start with poorly understood requirements.

▪ Once the requirements are cleared, the model will be thrown and the
system will be developed from the beginning.

▪ This model is suitable if the requirements are vague but stable.

 28

Throw away Prototype

Poorly
Get the
Understood Final
Feedback
Requirements Prototype
from Client No Changes Required

Need Changes

Create a Modify the Create

Prototype Prototype Requirement
Specification
 29

Problems of Throw away Prototyping

▪ Important features may have been left out due rapid implementation.

▪ Not possible to prototype most important parts of a system such as safety-

critical functions.

▪ An implementation has no legal standing as a contract between customer

and contractor.

▪ Non-functional requirements cannot be adequately tested in a prototype

implementation.
 30

Evolutionary Prototyping

▪ The objective is to work with customers and to evolve a final system

from the initial outline specification.

▪ The system grows by adding new features as they are proposed by

customers.

▪ This model is suitable if the requirements are vague and unstable.

 31

Evolutionary Prototype

Work with
Outline Create a Prototype
Requirements Prototype (System)

New Requirements
All requirements are Met

Upgrade
the
Final
Prototype
System
 32

Advantages of Evolutionary Prototyping

▪ Effort of prototype is not wasted

▪ Iterative a incremental development

▪ A working system is available early in the process.

▪ Misunderstandings between users and developers are exposed

▪ Mainly suitable for projects with vague and unstable requirements.

 33

Problems of Evolutionary Prototyping

▪ It is not cost effective to produce great deal of documentation

▪ Continual change tends to corrupt the structure of the prototype system.

▪ Need range of skills for this mode of development.

▪ Languages which are good for prototyping not always best for final
product.
 34

Comparison of models

Requirements
Model
Clear Stable
Waterfall Model yes Yes
Throwaway Prototype No Yes
Evolutionary Prototype No No
 35

Phase Development

▪ Cycle time is the time taken to deliver the system to the client soon after
requirements are fully identified

▪ One way reduce cycle time is to use phased development.

▪ The system is designed so that it can be delivered in pieces, enabling the

users to have some functionality while the rest is being developed.
 36

Incremental Development
 37

Incremental Development

System

A B C D

Phase 1 : Develop and Release Module A BA D

B C
Phase 2 : Develop and Release Module B

Phase 3 : Develop and Release Module C

Phase 4 : Develop and Release Module D

 38

Incremental Development

▪ The releases are defined by beginning with one small functional

subsystem and then adding functionality with each new release.

▪ Incremental development slowly builds up to full functionality with each

new release.
 39

Iterative Development

Iterative development
delivers a full system
at the very beginning
and then change,
improve and enhance
the functionality in
each new release.
 40

Iterative Development

System

System Version 1 : 1st Release with all functionalty

System Version 2 : 2nd Release with improvements B

V1 V2 V3 V4

System Version 3 : 3rd Release with improvements

System Version 4 : 4th Release with improvements

 41

Iterative + Incremental

▪ In reality many organizations use a combination of iterative and

incremental development.

▪ A new release may include some new functionalities , while existing

functionalities are improved and enhanced.

▪ This approach is much suitable to develop software for rapidly changing

business requirements in today’s organisations
 42

Iterative + Incremental

System

A B C D

Version 1 : Release Module A B

V1 V4
V2 V3
Version 2 : Release Module B with (A)+

Version 3 : Release Module C with (AB)+

Version 4 : Release Module D and (ABC)+

 43

Spiral Model

▪ Spiral model focus on risk identification and reduction

▪ Risk is simply something that can go wrong.

▪ There are no fixed phases in this model

▪ Management must decide how to structure the project into phases.

 44
Determine objectives

Spiral Model
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analy sis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 45

Spiral Model

▪ Each loop in the spiral represents a phase as defined by the management.

▪ innermost loop might be concerned with system feasibility,

▪ the next loop with system requirements definition,

▪ the next loop with system design and so on.

 46
Objective Setting Risk Assessment & Reduction
Spiral Model

Planning Development & Validation

 47

Spiral Model

▪ Each loop in the spiral is split into four sectors:

1. Objective setting

2. Risk assessment and reduction

3. Development and validation

4. Planning
 48

Objective setting

▪ Specific objectives of each phase are defined.

▪ Constraints on the process and the product are identified

▪ a detailed management plan is drawn up.

▪ Project risks are identified.

▪ Alternative strategies, depending on these risks, maybe planned.

 49

Risk assessment and reduction

▪ For each of the identified project risks, a detailed analysis is carried out.

▪ Steps are taken to reduce the risk.

▪ For example, if there is a risk that requirement are inappropriate, a

prototype system may be developed.
 50

Development and validation

▪ A development model for the system is then chosen.

▪ if user interface risks are dominant, an appropriate development model

might be Evolutionary prototyping.

▪ If the safety risks are the main consideration, a development based on

formal transformations may be the most appropriate and so on.

▪ one phase may use one model while another phase may use a different
model.
 51

Plaining

▪ The project is reviewed and a decision made whether to continue with a

further loop of the spiral.

▪ If it is decided to continue, plans are drawn up for the next phase of the
project.
 52

Benefits Spiral Model

▪ Process is represented as a spiral rather than as a sequence of activities

with backtracking

▪ Each loop in the spiral represents a phase in the process.

▪ No fixed phases such as specification or design - loops in the spiral are

chosen depending on what is required
 53

Benefits Spiral Model

▪ Risks are explicitly assessed and resolved throughout the process

▪ Project manager can shut off the process at any time.

▪ Different techniques can be used in different loops in the spiral.

 54

V Model
 55

V Model

▪ V model is a variation of the waterfall model

▪ Shows how the testing activities are related to analysis and designing

▪ Coding forms the point of the V

▪ Analysis and design on the left side of point of V

▪ Testing and maintenance on the right side of point of V

 56

V Model

▪ V model suggests that

1. Unit testing used to verify the program design

2. Integration testing should verify the system design

3. System testing should verify the Functional specification

4. Acceptance testing validates the customer requirements

 57

RAD Model

▪ Rapid Application Development Model

▪ Model is based on prototyping iterative and incremental development

▪ The functional modules are developed in parallel as prototypes

▪ All models are integrated to make the complete product for faster
delivery.
 58

RAD Model

▪ Easier to incorporate changes within the development process.

▪ RAD projects follow iterative and incremental model

▪ Have small teams comprising of developers, domain experts, customer

representatives and other IT resources

▪ They work progressively on component or prototype.

▪ The prototypes developed are reusable.

 59

RAD Model Design

 60

RAD Model Design

▪ RAD model distributes the analysis, design, build and test phases into a series of
short, iterative development cycles.

▪ Following are the various phases of the RAD Model

1. Business Modelling
2. Data Modelling
3. Process Modelling
4. Application Generation
5. Testing and Turnover
 61

Business Modelling

▪ A complete business analysis is performed to find the vital information

for business, how it can be obtained, how and when is the information
processed and what are the factors driving successful flow of information

▪ On basis of the flow of information and distribution between various

business channels, the product is designed
 62

Data Modelling

▪ The information gathered in the Business Modelling phase is reviewed

and analyzed to form sets of data objects vital for the business.

▪ The attributes of all data sets is identified and defined.

▪ The relation between these data objects are established and defined in
detail in relevance to the business model.
 63

Process Modelling

▪ The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific
business objectives as per the business model.

▪ The process model for any changes or enhancements to the data object
sets is defined in this phase. Process descriptions for adding, deleting,
retrieving or modifying a data object are given.
 64

Application Generation

▪ Automated tools are used for the construction of the software, to convert
process and data models into prototypes
▪ Application Generators
▪ Report Generators
▪ Database tools
▪ User interface development tools
 65

Testing and Turnover

▪ The overall testing time is reduced in the RAD model

▪ As the prototypes are independently tested during every iteration.

▪ The data flow and the interfaces between all the components need to be
thoroughly tested

▪ Risk is reduced, since already tested programming components are used

to develop systems.
 66

RAD Application

▪ RAD should be used only when a system can be modularized to be

delivered in an incremental manner.

▪ It should be used if there is a high availability of designers for Modelling.

▪ It should be used only if the budget permits use of automated code

generating tools.
 67

RAD Application

▪ RAD model should be chosen only if domain experts are available with
relevant business knowledge.

▪ Should be used where the requirements change during the project and
working prototypes are to be presented to customer in small iterations of
2-3 months.
 68

Advantages of RAD Model

▪ Changing requirements can be accommodated.

▪ Progress can be measured.

▪ Iteration time can be short with use of powerful RAD tools.

▪ Productivity with fewer people in a short time.

▪ Reduced development time.

 69

Advantages of RAD Model

▪ Increases reusability of components.

▪ Quick initial reviews occur.

▪ Encourages customer feedback.

▪ Integration from very beginning solves a lot of integration issues.

 70

Disadvantages of RAD Model

▪ Dependency on technically strong team members for identifying business

requirements.

▪ Only system that can be modularized can be built using RAD.

▪ Requires highly skilled developers/designers.

▪ High dependency on Modelling skills.

▪ Management complexity is more.

 71

Agile Development
 72

Agile Development

▪ Agile has introduced new concepts of iterative and incremental

development methods to ensure foolproof and accelerated delivery.

▪ Allows backward tracking and enables the development team to build a

broader feature set in time-boxed cycles.

▪ It follows a typical development process from requirement gatherings to

maintenance.
 73

Agile Development

▪ An advanced approach to develop software with flexibility and speed.

▪ Agile methods support business application development where the

system requirements usually changed rapidly during the development
process.

▪ Agile methods deliver working software quickly to customers, who can

then propose new and change requirements to be included later iterations
of the system.
 74

Agile Vs Waterfall
 75

Agile Development

▪ The process in Agile methodology is divided into sprints or iterations.

▪ At the beginning of each iteration or Sprint, the development team decides

what can be accomplished within this time frame and what sets of features
will be delivered.

▪ At the end of each Sprint, the software is placed in a production

environment so the client can take a look and provide their feedback.
 76

12 Agile Principles

1 2 3
 77

12 Agile Principles
4 5 6
 78

12 Agile Principles
8
7 9
 79

12 Agile Principles
10
12
11
 80

Agile Development methods

▪ Extreme programming
▪ Scrum
▪ Kanban
▪ Crystal
▪ Adaptive Software Development
▪ DSDM
▪ Feature Driven Development.
 81

Disadvantages of Agile

▪ it is difficult to assess the effort required at the beginning of the software

development life cycle.

▪ There is lack of emphasis on necessary designing and documentation.

▪ The project can easily get taken off track if the customer representative is
not clear what final outcome that they want.

▪ Only senior programmers are capable of taking the kind of decisions

required during the development process.
 82

Thank you…

K. K. Uditha Priyanga
PGD-SITM, BCS-PGD, Dip-ACS,NCC-IDCS-UK,MBCS,MCS
Managing Director / Senior Lecturer – ICTM Campus