SlideShare a Scribd company logo
Introduction to Software Engineering 
(CSC291) 
Instructor 
Humaira Afzal 
Lecturer 
humairaafzal@ciitlahore.edu.pk 
1
Generic software process models 
• The waterfall model and V model 
▫ Separate and distinct phases of specification and 
development 
• Evolutionary development 
▫ Specification and development are interleaved 
• Component-based development 
▫ The system is assembled from existing components
V Model 
• A variation of the waterfall model 
• It is also known as Verification and Validation model. 
• It is based on association of a testing phase for each 
corresponding development stage. 
• For every single phase in the development cycle there is a 
directly associated testing phase. 
• This is a highly disciplined model and next phase starts only 
after completion of the previous phase.
V Model Design
V Model Verification Phases 
Following are the Verification phases in V-Model 
Business Requirement Analysis: 
• This phase involves detailed communication with the customer to 
understand his expectations and exact requirement. 
• The acceptance test design planning is done at this stage as business 
requirements can be used as an input for acceptance testing. 
System Design: 
• System design would comprise of understanding and detailing the 
complete hardware and communication setup for the product under 
development. 
• System test plan is developed based on the system design.
V Model Verification Phases 
Architectural Design: 
• Based on the technical and financial feasibility the final decision is taken. 
• System design is broken down further into modules taking up different 
functionality. 
• High Level Design (HLD). 
• The data transfer and communication between the internal modules and 
with the outside world (other systems) is clearly understood and defined in 
this stage. 
• With this information, integration tests can be designed and documented 
during this stage. 
Module Design: 
• In this phase the detailed internal design for all the system modules is 
specified 
• Referred to as Low Level Design (LLD). 
• It is important that the design is compatible with the other modules in the 
system architecture and the other external systems. 
• Unit tests can be designed at this stage
V Model 
Coding Phase 
• The actual coding of the system modules designed in the design phase is 
taken up in the Coding phase. 
• The best suitable programming language is decided based on the system 
and architectural requirements. 
• The coding is performed based on the coding guidelines and standards. 
• The code goes through numerous code reviews and is optimized for best 
performance before the final build is checked into the repository.
V Model Validation Phases 
Following are the Validation phases in V-Model: 
Unit Testing: 
• Unit tests designed in the module design phase 
• Unit testing is the testing at code level and helps to eliminate bugs at an 
early stage 
Integration Testing: 
• Integration testing is associated with the architectural design phase. 
• Integration tests are performed to test the coexistence and communication 
of the internal modules within the system.
V Model Validation Phases 
System Testing: 
• System testing is directly associated with the System design phase. 
• System tests check the entire system functionality and the communication 
of the system under development with external systems. 
• Most of the software and hardware compatibility issues can be uncovered 
during system test execution. 
Acceptance Testing: 
• Acceptance testing is associated with the business requirement analysis 
phase and involves testing the product in user environment. 
• Acceptance tests uncover the compatibility issues with the other systems 
available in the user environment. 
• It also discovers the non functional issues such as load and performance 
defects in the actual user environment.
Advantages of V-model 
• Simple and easy to use. 
• Testing activities like planning, test designing ,happens well 
before coding. 
• Saves a lot of time. 
• Higher chances of success over the waterfall model. 
• Works well for small projects where requirements are easily 
understood.
V-Shaped Model Problems 
• No iteration of phases 
• Cannot handle dynamic changes in requirements throughout 
the life cycle 
• Requirements are tested too late to make changes without 
affecting the schedule 
• No risk analysis
When to use the V-model 
• The V-shaped model should be used for small to medium sized projects 
where requirements are clearly defined and fixed. 
• The V-Shaped model should be chosen when technical resources are 
available with needed technical expertise. 
• High confidence of customer is required for choosing the V-Shaped model 
approach. 
• Since, no prototypes are produced, there is a very high risk involved in 
meeting customer expectations.
Evolutionary Models 
Evolutionary Development: 
• Interleaves the activities of specification, development and 
validation 
• Initial system is developed from abstract specification 
• Then refined with customer input to produce a system that 
satisfies the customer’ s needs. 
Two types of evolutionary development 
1. Exploratory 
2. Prototyping 
13
Evolutionary Models 
Exploratory Model 
• Systems development method ( SDM ) 
• Used to design and develop a computer system or product 
• Consists of planning and trying different designs until one of 
them seems to be the right one to develop. 
• This model works best in situations where few, or none, of the 
system or product requirements are known in detail. 
• Work with customers to explore their requirements and 
deliver a final system from an initial outline specification.
There are several steps in the exploratory model 
• Step 1: A project is launched based on prior best-development 
efforts and designed to shed light on the system or expected 
algorithm. 
• Step 2: A basic model determined before the project begins is 
employed with information gathered during Step 1, in addition to 
new project development team ideas. 
• Step 3: The basic model of Step 2 is tested to determine and 
reinforce strengths, while improving and resolving weaknesses. 
• Step 4: Based on Steps 2 and 3, a new model is developed to include 
any improvements or modifications. 
• Step 5: The model is tested to evaluate performance and determine 
future potential improvements or modifications. 
• Step 6: The testing process is repeated throughout the project to 
fulfill user satisfaction and predetermined requirements.
16 
Exploratory Model 
Concurrent Activities 
Outline 
Description 
Initial 
Version 
Intermediate 
Version 
Final 
Version 
Specification 
Development 
Validation
Prototyping Model 
• When a customer defines a set of general objectives for a software but does 
not identify detailed I/O or processing requirements. 
• A prototype is built to understand the requirements. 
• By using this prototype, the client can get an “actual feel” of the system 
• The interactions with prototype can enable the client to better understand 
the requirements of the desired system. 
• Prototyping is an attractive idea for complicated and large systems 
Consists of 4 iterating phases: 
▫ Requirements gathering. 
▫ Design and build SW prototype. 
▫ Evaluate prototype with customer. 
▫ Refine requirements. 
. 
Evolutionary Models
18 
Prototyping Model 
1 / 4 
Listen to 
Customer 
2 
Build / Revise 
prototypes 
3 
Customer 
Test-Drives 
prototypes 
1. Requirements gathering. 
2. Design and build SW prototype. 
3. Evaluate prototype with customer. 
4. Refine requirements.
Advantages of Prototype model 
• Users are actively involved in the development 
• Users get a better understanding of the system being 
developed. 
• Errors can be detected much earlier. 
• Quicker user feedback is available leading to better solutions.
Disadvantages of Prototype model 
• Practically, this methodology may increase the complexity of 
the system as scope of the system may expand beyond original 
plans. 
• Incomplete application may cause application not to be used 
as the full system was designed 
• Incomplete problem analysis.
When to use Prototype model 
• Prototype model should be used when the desired system 
needs to have a lot of interaction with the end users. 
• Typically, online systems, web interfaces have a very high 
amount of interaction with end users, are best suited for 
Prototype model. 
• They are excellent for designing good human computer 
interface systems.
Evolutionary development 
• Problems 
▫ Lack of process visibility 
▫ Systems are often poorly structured 
▫ Special skills (e.g. in languages for rapid prototyping) may 
be required. 
• Applicability 
▫ For small or medium-size interactive systems; 
▫ For parts of large systems (e.g. the user interface); 
▫ For short-lifetime systems.
Component-based software engineering 
• Based on systematic reuse where systems are integrated from 
existing components. 
• People working on the project  Know of design or code 
(similar to that required) Modify them as needed  
incorporate them into their system 
• Process stages 
▫ Component analysis 
▫ Requirements modification 
▫ System design with reuse 
▫ Development and integration 
• This approach is becoming increasingly used as component 
standards have emerged.
Reuse-oriented development
Component-based software engineering 
Component analysis 
• Given the requirement specification 
• Search is made for components 
• Usually there is no exact match. 
Requirement Modification 
• Requirements are analyzed—using information of discovered components 
• If modifications are impossible— component analysis activity may be re-entered 
to search for alternate solution 
System Design with Reuse 
• Frame work of system is designed or an existing frame work is reused. 
Development and integration Software 
• Existing software /modified and newly developed components are 
integrated.
Component-based software engineering 
Advantages 
• Reduce the amount of software to be developed 
• Reducing cost and risk 
• Faster delivery of software 
Disadvantages 
• Requirement changes—may lead to a system that does not meet the real 
needs of users 
• Control over the system evolution is lost
Process iteration 
• Change is necessary in all large software projects. 
• Change? 
• What to do? 
• Iteration means earlier stages are reworked in the process for 
large systems 
• Iteration can be applied to any of the generic process models 
• Two (related) process models 
▫ Incremental delivery 
▫ Spiral development
Incremental delivery 
“The software specification, design and implementation are 
broken down into a series of increments that are each 
developed in turn” 
• Waterfall model & evolutionary approach?...in case of change 
• Incremental delivery—in-between approach 
• System development is decomposed into increments and each 
delivers a proportion of the system. 
• Increments are developed based on their requirement 
priorities.
Incremental development 
Validate 
increment 
Develop system 
increment 
Design system 
architecture 
Integrate 
increment 
Validate 
system 
Define outline 
requirements 
Assign requirements 
to increments 
System incomplete 
Final 
system
Incremental delivery(Steps) 
1.Customer identify—services provided by the system 
2. Then identify which of the services are most important and 
which are least important 
3. No of delivery increments are then identified with sub-set of 
the system functionality 
4.Highest priority services delivered first 
5. Requirements for the first increment are defined in detail 
6. First Increment is developed and delivered ..customer can put 
into service.(Benefit for customer?) 
7.During development ….further requirements analysis for later 
increments can take place
Incremental development advantages 
• Customer do not have to wait until the entire system is 
delivered 
• Customers can use the early increments...gain experience that 
informs their requirements for later system increments 
• Lower risk of overall project failure..? 
• The high priority system services receive more testing..how?
Incremental development Problems and 
example...?

More Related Content

PPTX
Software quality assurance
PPT
User Interface Design in Software Engineering SE15
PPTX
Waterfall model
ODP
Evolutionary process models se.ppt
PPTX
Software Process Models
PPTX
SQA - chapter 13 (Software Quality Infrastructure)
PDF
Software Engineering : Requirement Analysis & Specification
PPT
Software quality
Software quality assurance
User Interface Design in Software Engineering SE15
Waterfall model
Evolutionary process models se.ppt
Software Process Models
SQA - chapter 13 (Software Quality Infrastructure)
Software Engineering : Requirement Analysis & Specification
Software quality

What's hot (20)

PPT
CASE tools and their effects on software quality
DOCX
process models- software engineering
PPTX
The Extreme Programming (XP) Model
PDF
Software requirements
PPT
HCI 3e - Ch 6: HCI in the software process
PPTX
Software requirements specification
PPTX
Functional vs Non-functional Requirements - Which comes first?
PPTX
Software Testing Basics
PPT
Formal Specification in Software Engineering SE9
PPTX
Component Based Software Engineering
PDF
Software Process Models
PPTX
Evolutionary models
PPTX
System testing
PPT
PPTX
Software process
DOC
Srs template
PPTX
Software Engineering- Requirement Elicitation and Specification
PPT
Requirement specification (SRS)
PPTX
Sequence diagram
CASE tools and their effects on software quality
process models- software engineering
The Extreme Programming (XP) Model
Software requirements
HCI 3e - Ch 6: HCI in the software process
Software requirements specification
Functional vs Non-functional Requirements - Which comes first?
Software Testing Basics
Formal Specification in Software Engineering SE9
Component Based Software Engineering
Software Process Models
Evolutionary models
System testing
Software process
Srs template
Software Engineering- Requirement Elicitation and Specification
Requirement specification (SRS)
Sequence diagram
Ad

Viewers also liked (20)

PPT
Software Process Models
PPTX
Software Process Models
PPTX
Software Engg. process models
PPT
Process models
PPTX
Fundamental software engineering activities
PPTX
6 basic steps of software development process
PPT
Software Development Life Cycle (SDLC)
PPTX
Architectural patterns for real-time systems
PPTX
List of Software Development Model and Methods
PPTX
Introduction To Software Engineering
PDF
Software engineering lecture notes
PPTX
Software Development Process Models (SCRUM Methodology)
PPTX
Software Engineering Practice
PPTX
Ch1 introduction
PPT
Software Process Improvement
PPT
Unit1
PDF
Why is project management so hard?
PPT
software engineering
PPSX
Evolutionary Development Methodology
PPTX
Software Engineering Process Models
Software Process Models
Software Process Models
Software Engg. process models
Process models
Fundamental software engineering activities
6 basic steps of software development process
Software Development Life Cycle (SDLC)
Architectural patterns for real-time systems
List of Software Development Model and Methods
Introduction To Software Engineering
Software engineering lecture notes
Software Development Process Models (SCRUM Methodology)
Software Engineering Practice
Ch1 introduction
Software Process Improvement
Unit1
Why is project management so hard?
software engineering
Evolutionary Development Methodology
Software Engineering Process Models
Ad

Similar to Generic Software Process Models (20)

PPTX
V sdlc se
PPTX
Software development life cycle (SDLC) Models
PPTX
software process model is a structured framework used to guide the software d...
PPTX
System models of sdlc- v model
PPTX
SE-03.pptx
PPTX
The process
PDF
Software vjhghjjkhjkkkghhjhEngineering.pdf
PDF
Software development PROCESS
PPT
PPTX
PPT
Software development life cycle
PPT
Sdlc models
PPT
PPTX
ISTQB - Software development life cycle
PPT
Software Process in Software Engineering SE3
PPS
Software Devlopment Life Cycle
PDF
FSE Chap 2.pdf fundamental of software engineering for second year software e...
PPTX
2-models.pptx
PPT
Chapter 2 Software EngineeringSoftware Processes
PPTX
Unit1_Software_EngineeringGGGGGGGGGG.pptx
V sdlc se
Software development life cycle (SDLC) Models
software process model is a structured framework used to guide the software d...
System models of sdlc- v model
SE-03.pptx
The process
Software vjhghjjkhjkkkghhjhEngineering.pdf
Software development PROCESS
Software development life cycle
Sdlc models
ISTQB - Software development life cycle
Software Process in Software Engineering SE3
Software Devlopment Life Cycle
FSE Chap 2.pdf fundamental of software engineering for second year software e...
2-models.pptx
Chapter 2 Software EngineeringSoftware Processes
Unit1_Software_EngineeringGGGGGGGGGG.pptx

More from Education Front (20)

PPT
Improving Pronunciation
PPTX
2- Dimensional Arrays
PPTX
Problem Sloving
PPTX
Problem Solving - 1
PPTX
Introduction To Stack
PPTX
Process Models
PPTX
Process Models
PPTX
Data Representation
PPTX
Introduction to Algorithm
PPT
Revised Process of Communication
PPT
Importance of Language in Communication
PPT
Lecture1 (SE Introduction)
PPTX
Lecture 2 (Software Processes)
PPTX
Introduction to data structure
PPTX
Facing Today’s Communication Challenges
PPTX
Processor Basics
PPTX
Register & Memory
PPTX
Data Representation
PPTX
Computer Evolution
PPT
Assembly Language Basics
Improving Pronunciation
2- Dimensional Arrays
Problem Sloving
Problem Solving - 1
Introduction To Stack
Process Models
Process Models
Data Representation
Introduction to Algorithm
Revised Process of Communication
Importance of Language in Communication
Lecture1 (SE Introduction)
Lecture 2 (Software Processes)
Introduction to data structure
Facing Today’s Communication Challenges
Processor Basics
Register & Memory
Data Representation
Computer Evolution
Assembly Language Basics

Generic Software Process Models

  • 1. Introduction to Software Engineering (CSC291) Instructor Humaira Afzal Lecturer humairaafzal@ciitlahore.edu.pk 1
  • 2. Generic software process models • The waterfall model and V model ▫ Separate and distinct phases of specification and development • Evolutionary development ▫ Specification and development are interleaved • Component-based development ▫ The system is assembled from existing components
  • 3. V Model • A variation of the waterfall model • It is also known as Verification and Validation model. • It is based on association of a testing phase for each corresponding development stage. • For every single phase in the development cycle there is a directly associated testing phase. • This is a highly disciplined model and next phase starts only after completion of the previous phase.
  • 5. V Model Verification Phases Following are the Verification phases in V-Model Business Requirement Analysis: • This phase involves detailed communication with the customer to understand his expectations and exact requirement. • The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing. System Design: • System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. • System test plan is developed based on the system design.
  • 6. V Model Verification Phases Architectural Design: • Based on the technical and financial feasibility the final decision is taken. • System design is broken down further into modules taking up different functionality. • High Level Design (HLD). • The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. • With this information, integration tests can be designed and documented during this stage. Module Design: • In this phase the detailed internal design for all the system modules is specified • Referred to as Low Level Design (LLD). • It is important that the design is compatible with the other modules in the system architecture and the other external systems. • Unit tests can be designed at this stage
  • 7. V Model Coding Phase • The actual coding of the system modules designed in the design phase is taken up in the Coding phase. • The best suitable programming language is decided based on the system and architectural requirements. • The coding is performed based on the coding guidelines and standards. • The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.
  • 8. V Model Validation Phases Following are the Validation phases in V-Model: Unit Testing: • Unit tests designed in the module design phase • Unit testing is the testing at code level and helps to eliminate bugs at an early stage Integration Testing: • Integration testing is associated with the architectural design phase. • Integration tests are performed to test the coexistence and communication of the internal modules within the system.
  • 9. V Model Validation Phases System Testing: • System testing is directly associated with the System design phase. • System tests check the entire system functionality and the communication of the system under development with external systems. • Most of the software and hardware compatibility issues can be uncovered during system test execution. Acceptance Testing: • Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. • Acceptance tests uncover the compatibility issues with the other systems available in the user environment. • It also discovers the non functional issues such as load and performance defects in the actual user environment.
  • 10. Advantages of V-model • Simple and easy to use. • Testing activities like planning, test designing ,happens well before coding. • Saves a lot of time. • Higher chances of success over the waterfall model. • Works well for small projects where requirements are easily understood.
  • 11. V-Shaped Model Problems • No iteration of phases • Cannot handle dynamic changes in requirements throughout the life cycle • Requirements are tested too late to make changes without affecting the schedule • No risk analysis
  • 12. When to use the V-model • The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed. • The V-Shaped model should be chosen when technical resources are available with needed technical expertise. • High confidence of customer is required for choosing the V-Shaped model approach. • Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.
  • 13. Evolutionary Models Evolutionary Development: • Interleaves the activities of specification, development and validation • Initial system is developed from abstract specification • Then refined with customer input to produce a system that satisfies the customer’ s needs. Two types of evolutionary development 1. Exploratory 2. Prototyping 13
  • 14. Evolutionary Models Exploratory Model • Systems development method ( SDM ) • Used to design and develop a computer system or product • Consists of planning and trying different designs until one of them seems to be the right one to develop. • This model works best in situations where few, or none, of the system or product requirements are known in detail. • Work with customers to explore their requirements and deliver a final system from an initial outline specification.
  • 15. There are several steps in the exploratory model • Step 1: A project is launched based on prior best-development efforts and designed to shed light on the system or expected algorithm. • Step 2: A basic model determined before the project begins is employed with information gathered during Step 1, in addition to new project development team ideas. • Step 3: The basic model of Step 2 is tested to determine and reinforce strengths, while improving and resolving weaknesses. • Step 4: Based on Steps 2 and 3, a new model is developed to include any improvements or modifications. • Step 5: The model is tested to evaluate performance and determine future potential improvements or modifications. • Step 6: The testing process is repeated throughout the project to fulfill user satisfaction and predetermined requirements.
  • 16. 16 Exploratory Model Concurrent Activities Outline Description Initial Version Intermediate Version Final Version Specification Development Validation
  • 17. Prototyping Model • When a customer defines a set of general objectives for a software but does not identify detailed I/O or processing requirements. • A prototype is built to understand the requirements. • By using this prototype, the client can get an “actual feel” of the system • The interactions with prototype can enable the client to better understand the requirements of the desired system. • Prototyping is an attractive idea for complicated and large systems Consists of 4 iterating phases: ▫ Requirements gathering. ▫ Design and build SW prototype. ▫ Evaluate prototype with customer. ▫ Refine requirements. . Evolutionary Models
  • 18. 18 Prototyping Model 1 / 4 Listen to Customer 2 Build / Revise prototypes 3 Customer Test-Drives prototypes 1. Requirements gathering. 2. Design and build SW prototype. 3. Evaluate prototype with customer. 4. Refine requirements.
  • 19. Advantages of Prototype model • Users are actively involved in the development • Users get a better understanding of the system being developed. • Errors can be detected much earlier. • Quicker user feedback is available leading to better solutions.
  • 20. Disadvantages of Prototype model • Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. • Incomplete application may cause application not to be used as the full system was designed • Incomplete problem analysis.
  • 21. When to use Prototype model • Prototype model should be used when the desired system needs to have a lot of interaction with the end users. • Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. • They are excellent for designing good human computer interface systems.
  • 22. Evolutionary development • Problems ▫ Lack of process visibility ▫ Systems are often poorly structured ▫ Special skills (e.g. in languages for rapid prototyping) may be required. • Applicability ▫ For small or medium-size interactive systems; ▫ For parts of large systems (e.g. the user interface); ▫ For short-lifetime systems.
  • 23. Component-based software engineering • Based on systematic reuse where systems are integrated from existing components. • People working on the project  Know of design or code (similar to that required) Modify them as needed  incorporate them into their system • Process stages ▫ Component analysis ▫ Requirements modification ▫ System design with reuse ▫ Development and integration • This approach is becoming increasingly used as component standards have emerged.
  • 25. Component-based software engineering Component analysis • Given the requirement specification • Search is made for components • Usually there is no exact match. Requirement Modification • Requirements are analyzed—using information of discovered components • If modifications are impossible— component analysis activity may be re-entered to search for alternate solution System Design with Reuse • Frame work of system is designed or an existing frame work is reused. Development and integration Software • Existing software /modified and newly developed components are integrated.
  • 26. Component-based software engineering Advantages • Reduce the amount of software to be developed • Reducing cost and risk • Faster delivery of software Disadvantages • Requirement changes—may lead to a system that does not meet the real needs of users • Control over the system evolution is lost
  • 27. Process iteration • Change is necessary in all large software projects. • Change? • What to do? • Iteration means earlier stages are reworked in the process for large systems • Iteration can be applied to any of the generic process models • Two (related) process models ▫ Incremental delivery ▫ Spiral development
  • 28. Incremental delivery “The software specification, design and implementation are broken down into a series of increments that are each developed in turn” • Waterfall model & evolutionary approach?...in case of change • Incremental delivery—in-between approach • System development is decomposed into increments and each delivers a proportion of the system. • Increments are developed based on their requirement priorities.
  • 29. Incremental development Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
  • 30. Incremental delivery(Steps) 1.Customer identify—services provided by the system 2. Then identify which of the services are most important and which are least important 3. No of delivery increments are then identified with sub-set of the system functionality 4.Highest priority services delivered first 5. Requirements for the first increment are defined in detail 6. First Increment is developed and delivered ..customer can put into service.(Benefit for customer?) 7.During development ….further requirements analysis for later increments can take place
  • 31. Incremental development advantages • Customer do not have to wait until the entire system is delivered • Customers can use the early increments...gain experience that informs their requirements for later system increments • Lower risk of overall project failure..? • The high priority system services receive more testing..how?