SlideShare a Scribd company logo
“You’ve got to be very careful if you don’t know where you’re
going, because you might not get there.”
Yogi Berra
 The objective of software engineering is to get software with high
quality.
 Process is a framework for the tasks that are required to build
high-quality software.
 A software process is a set of activities and associated results,
which produces a software product. Software engineers carry out
the activities.
Chapter 2 Software Processes 2
 The common activities ca be categorized into:
3
• The functionality of the software and constraints on its
operation must be defined.
Software specification
• The software to meet the specification must be produced.
Software development
• The software must be validated to ensure that it does what
the customer wants.
Software validation
• The software must be evolved to meet the changing
requirements of customers.
Software evolution
 Plan-driven processes are processes where all of the
process activities are planned in advance and progress
is measured against this plan.
 In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
 In practice, most practical processes include elements
of both plan-driven and agile approaches.
 There are NO right or wrong software processes.
Chapter 2 Software Processes 4
A framework that describes the activities performed at each
stage of a software development project.
6
 Requirements – defines needed
information, function, behavior,
performance and interfaces.
 Design – data structures,
software architecture, interface
representations, algorithmic
details.
 Implementation – source code,
database, user documentation,
testing.
 Test – check if all code modules
work together and if the system
as a whole behaves as per the
specifications.
 Installation – deployment of
system, user-training.
 Maintenance – bug fixes, added
functionality (an on-going
process).
Easy to understand,
easy to use
Provides structure to
inexperienced staff
Milestones are well
understood
Sets requirements
stability
Good for management
control (plan, staff,
track)
Works well when quality
is more important than
cost or schedule
 All requirements must be known upfront
 Deliverables created for each phase are considered frozen –
inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until
it may be too late)
 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.
 A variant of the Waterfall that
emphasizes the verification
and validation of the product.
 Testing of the product is
planned in parallel with a
corresponding phase of
development
 Project and Requirements Planning
– allocate resources
 Product Requirements and
Specification Analysis – complete
specification of the software system
 Architecture or High-Level Design –
defines how software functions
fulfill the design
 Detailed Design – develop
algorithms for each architectural
component
 Production, operation and
maintenance – provide for
enhancement and corrections
 System and acceptance testing –
check the entire software system in
its environment
 Integration and Testing – check that
modules interconnect correctly
 Unit testing – check that each
module acts as expected
 Coding – transform algorithms into
software
 Emphasize planning for verification and validation of the
product in early stages of product development
 Each deliverable must be testable
 Project management can track progress by milestones
 Easy to use
 Does not easily handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
 Does not contain risk analysis activities
 Excellent choice for systems requiring high
reliability – hospital patient control
applications
 All requirements are known up-front
 When it can be modified to handle changing
requirements beyond analysis phase
 Solution and technology are known
Two ways:
 System prototyping
 Incremental delivery
Chapter 2 Software Processes 17
 What is software Prototyping?
◦ Prototype is working model of software with
some limited functionality.
 Stepwise approach to develop software
prototype
◦ Basic Requirement identification
◦ Developing the initial prototype
◦ Review of the prototype
◦ Revise and enhance the prototype
Throwaway
Rapid
Prototyping
Evolutionary
Prototype
 Objective - Derive end system requirements
Throw away prototyping is one type of approach
where an initial prototype is built mainly focusing
on the poorly understood requirements.
• Once the requirements are understood, prototype is
discarded. Requirements document is updated.
• Actual system is developed (i.e. a conventional
development process) with clear understanding of
requirements.
 Used to reduce requirements risk.
 Initial prototype is developed from outline
requirements, delivered for experiment,
and modified until risk is acceptably low.
 Examples of throwaway prototypes
include screen mock-ups and story boards.
 Developers may be pressurized to deliver a
throw-away prototype as the final system.
 This is problematic...
 It may be impossible to meet non-functional
requirements.
 The prototype is almost certainly undocumented.
 The system may be poorly structured and therefore
difficult to maintain.
 Normal quality standards may not have been applied.
Air Tank
Developer
User Mgmt
No, no, no! I
won’t deliver the
prototype to you!
Pressurizing the
Developer
 Developers build a prototype during the requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code is brought up to the
standards needed for a final product.
 A preliminary project plan is developed
 An partial high-level paper model is created
 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
Customers can “see” the system requirements as
they are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness
of additional needed functionality
 Tendency to discard structured program
development for “code-and-fix”
development
 Bad reputation for “quick-and-dirty”
methods
 Overall maintainability may be
overlooked
 Process may continue forever (scope
creep)
Requirements
are unstable or
have to be
clarified
Develop user
interfaces
Short-lived
demonstrations
New, original
development
 The system is developed as a series of versions (increments), with
each version adding functionality to the previous version.
 In Incremental Model, Project requirements are divided into
multiple modules and each module is developed separately.
 Finally developed modules are integrated with other modules.
 During development of each module, waterfall model is followed
for each module development separately.
 Each developed module in Incremental Model is standalone
feature and could be delivered to the end users to use it.
Chapter 2 Software Processes 30
Chapter 2 Software Processes 31
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
 Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower
 Risk, funding, schedule, program complexity, or need for
early realization of benefits.
 Most of the requirements are known up-front but are
expected to evolve over time
 A need to get basic functionality to the market early
 On projects which have lengthy development schedules
 On a project with new technology
 The CBD Solution
 Systems should be assembled from existing
components.
Chapter 2 Software Processes 35
 A software component is a program module
that can be used independently, or can operate
in conjunction with other components.
 Components should be executable to allow
independence.
Chapter 2 Software Processes 36
What is CBSE?
 Component-based software engineering is
the idea of building software from
established software components, as
opposed to building the software from the
ground up.
Chapter 2 Software Processes 37
 Based on systematic reuse where systems are
integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
 Reuse is now the standard approach for
building many types of business system
Chapter 2 Software Processes 38
 Advantages:
reducing cost and risk.
faster delivery of software
 Disadvantages:
Requirement compromises
Chapter 2 Software Processes 39
 Similar to the incremental model, with more emphasis placed
on risk analysis.
 Process is represented as a spiral, rather than as a sequence of
activities.
 Software project repeatedly passes through these phases in
iterations.
 Risks are explicitly assessed and resolved throughout the
process.
 Incremental releases of the product, or incremental refinement
through each iteration around the spiral.
Spiral model is an evolutionary software
process model which is a combination of an
iterative nature of prototyping and systematic
aspects of traditional waterfall model.
Development cycles through multiple (3-6) task regions
Figure 2.13
•The objectives, alternatives and constraints of the project are determined and are
documented.
Planning Phase
•All possible alternatives, which can help in developing a cost effective project are analyzed
•This phase identify and resolve all the possible risks in the project development.
Risk assessment and reduction
•The actual development of the project is carried out.
•The output of this phase is passed through all the phases iteratively in order to obtain
improvements in the same.
Development and validation
•Developed product is passed on to the customer in order to receive customer’s comments and
suggestions.
•This phase is very much similar to TESTING phase.
•And the next phase of the spiral is planned.
Customer Evaluation (Planning)
 Provides early indication of unsolvable
risks, without much cost
 Users see the system early because of
rapid prototyping tools
 Critical high-risk functions are
developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle
steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of potential
changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)
 Speed up or bypass one or more life cycle
phases
 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ disciplined
methods
Agile software development is a group of
software development methodologies based on
iterative and incremental development, where
requirements and solutions evolve through
collaboration between self-organizing, cross-
functional teams.
48
49

More Related Content

Similar to ISE_Lecture Week 2-SW Process Models.ppt

2-models.pptx
2-models.pptx2-models.pptx
2-models.pptx
ssuserd0fdaa
 
Ch2.Part2.Modified.ppt
Ch2.Part2.Modified.pptCh2.Part2.Modified.ppt
Ch2.Part2.Modified.ppt
Melisa521270
 
Lecture - 11-15.pptx
Lecture - 11-15.pptxLecture - 11-15.pptx
Lecture - 11-15.pptx
FarHana74914
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptx
ethiouniverse
 
SOFTWARE ENGINEERING PART 1
SOFTWARE ENGINEERING PART 1SOFTWARE ENGINEERING PART 1
SOFTWARE ENGINEERING PART 1
ravi gupta
 
Ch2
Ch2Ch2
Ch 2 Software Engineering
Ch 2 Software EngineeringCh 2 Software Engineering
Ch 2 Software Engineering
Imran Mirza
 
Sdpl1
Sdpl1Sdpl1
Ian Sommerville, Software Engineering, 9th Edition Ch2
Ian Sommerville,  Software Engineering, 9th Edition Ch2Ian Sommerville,  Software Engineering, 9th Edition Ch2
Ian Sommerville, Software Engineering, 9th Edition Ch2
Mohammed Romi
 
SE-Lecture-2.pptx
SE-Lecture-2.pptxSE-Lecture-2.pptx
SE-Lecture-2.pptx
vishal choudhary
 
16346915.ppt
16346915.ppt16346915.ppt
16346915.ppt
PunitGupta71
 
SE Sumerville 9th Chp 2
SE Sumerville 9th Chp 2SE Sumerville 9th Chp 2
SE Sumerville 9th Chp 2
Kashif Sohail
 
Kelis king - software development life cycle (sdlc)
Kelis king  - software development life cycle (sdlc)Kelis king  - software development life cycle (sdlc)
Kelis king - software development life cycle (sdlc)
KelisKing
 
Kelis king - software development life cycle (sdlc)
Kelis king -  software development life cycle (sdlc)Kelis king -  software development life cycle (sdlc)
Kelis king - software development life cycle (sdlc)
KelisKing
 
Fundamentals of software development
Fundamentals of software developmentFundamentals of software development
Fundamentals of software development
Pratik Devmurari
 
Software development process models
Software development process modelsSoftware development process models
Software development process models
Muhammed Afsal Villan
 
System analsis and design
System analsis and designSystem analsis and design
System analsis and design
Rizwan Kabir
 
3
33
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
Hassan A-j
 
2. Software process
2. Software process2. Software process
2. Software process
Ashis Kumar Chanda
 

Similar to ISE_Lecture Week 2-SW Process Models.ppt (20)

2-models.pptx
2-models.pptx2-models.pptx
2-models.pptx
 
Ch2.Part2.Modified.ppt
Ch2.Part2.Modified.pptCh2.Part2.Modified.ppt
Ch2.Part2.Modified.ppt
 
Lecture - 11-15.pptx
Lecture - 11-15.pptxLecture - 11-15.pptx
Lecture - 11-15.pptx
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptx
 
SOFTWARE ENGINEERING PART 1
SOFTWARE ENGINEERING PART 1SOFTWARE ENGINEERING PART 1
SOFTWARE ENGINEERING PART 1
 
Ch2
Ch2Ch2
Ch2
 
Ch 2 Software Engineering
Ch 2 Software EngineeringCh 2 Software Engineering
Ch 2 Software Engineering
 
Sdpl1
Sdpl1Sdpl1
Sdpl1
 
Ian Sommerville, Software Engineering, 9th Edition Ch2
Ian Sommerville,  Software Engineering, 9th Edition Ch2Ian Sommerville,  Software Engineering, 9th Edition Ch2
Ian Sommerville, Software Engineering, 9th Edition Ch2
 
SE-Lecture-2.pptx
SE-Lecture-2.pptxSE-Lecture-2.pptx
SE-Lecture-2.pptx
 
16346915.ppt
16346915.ppt16346915.ppt
16346915.ppt
 
SE Sumerville 9th Chp 2
SE Sumerville 9th Chp 2SE Sumerville 9th Chp 2
SE Sumerville 9th Chp 2
 
Kelis king - software development life cycle (sdlc)
Kelis king  - software development life cycle (sdlc)Kelis king  - software development life cycle (sdlc)
Kelis king - software development life cycle (sdlc)
 
Kelis king - software development life cycle (sdlc)
Kelis king -  software development life cycle (sdlc)Kelis king -  software development life cycle (sdlc)
Kelis king - software development life cycle (sdlc)
 
Fundamentals of software development
Fundamentals of software developmentFundamentals of software development
Fundamentals of software development
 
Software development process models
Software development process modelsSoftware development process models
Software development process models
 
System analsis and design
System analsis and designSystem analsis and design
System analsis and design
 
3
33
3
 
Software Process Models
Software Process ModelsSoftware Process Models
Software Process Models
 
2. Software process
2. Software process2. Software process
2. Software process
 

Recently uploaded

Lapbook sobre os Regimes Totalitários.pdf
Lapbook sobre os Regimes Totalitários.pdfLapbook sobre os Regimes Totalitários.pdf
Lapbook sobre os Regimes Totalitários.pdf
Jean Carlos Nunes Paixão
 
DRUGS AND ITS classification slide share
DRUGS AND ITS classification slide shareDRUGS AND ITS classification slide share
DRUGS AND ITS classification slide share
taiba qazi
 
PIMS Job Advertisement 2024.pdf Islamabad
PIMS Job Advertisement 2024.pdf IslamabadPIMS Job Advertisement 2024.pdf Islamabad
PIMS Job Advertisement 2024.pdf Islamabad
AyyanKhan40
 
Assessment and Planning in Educational technology.pptx
Assessment and Planning in Educational technology.pptxAssessment and Planning in Educational technology.pptx
Assessment and Planning in Educational technology.pptx
Kavitha Krishnan
 
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama UniversityNatural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Akanksha trivedi rama nursing college kanpur.
 
Top five deadliest dog breeds in America
Top five deadliest dog breeds in AmericaTop five deadliest dog breeds in America
Top five deadliest dog breeds in America
Bisnar Chase Personal Injury Attorneys
 
writing about opinions about Australia the movie
writing about opinions about Australia the moviewriting about opinions about Australia the movie
writing about opinions about Australia the movie
Nicholas Montgomery
 
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
RitikBhardwaj56
 
Your Skill Boost Masterclass: Strategies for Effective Upskilling
Your Skill Boost Masterclass: Strategies for Effective UpskillingYour Skill Boost Masterclass: Strategies for Effective Upskilling
Your Skill Boost Masterclass: Strategies for Effective Upskilling
Excellence Foundation for South Sudan
 
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat  Leveraging AI for Diversity, Equity, and InclusionExecutive Directors Chat  Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
TechSoup
 
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
Nguyen Thanh Tu Collection
 
Smart-Money for SMC traders good time and ICT
Smart-Money for SMC traders good time and ICTSmart-Money for SMC traders good time and ICT
Smart-Money for SMC traders good time and ICT
simonomuemu
 
CACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdfCACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdf
camakaiclarkmusic
 
Introduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp NetworkIntroduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp Network
TechSoup
 
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
PECB
 
Main Java[All of the Base Concepts}.docx
Main Java[All of the Base Concepts}.docxMain Java[All of the Base Concepts}.docx
Main Java[All of the Base Concepts}.docx
adhitya5119
 
How to Fix the Import Error in the Odoo 17
How to Fix the Import Error in the Odoo 17How to Fix the Import Error in the Odoo 17
How to Fix the Import Error in the Odoo 17
Celine George
 
The Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collectionThe Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collection
Israel Genealogy Research Association
 
Types of Herbal Cosmetics its standardization.
Types of Herbal Cosmetics its standardization.Types of Herbal Cosmetics its standardization.
Types of Herbal Cosmetics its standardization.
Ashokrao Mane college of Pharmacy Peth-Vadgaon
 
A Survey of Techniques for Maximizing LLM Performance.pptx
A Survey of Techniques for Maximizing LLM Performance.pptxA Survey of Techniques for Maximizing LLM Performance.pptx
A Survey of Techniques for Maximizing LLM Performance.pptx
thanhdowork
 

Recently uploaded (20)

Lapbook sobre os Regimes Totalitários.pdf
Lapbook sobre os Regimes Totalitários.pdfLapbook sobre os Regimes Totalitários.pdf
Lapbook sobre os Regimes Totalitários.pdf
 
DRUGS AND ITS classification slide share
DRUGS AND ITS classification slide shareDRUGS AND ITS classification slide share
DRUGS AND ITS classification slide share
 
PIMS Job Advertisement 2024.pdf Islamabad
PIMS Job Advertisement 2024.pdf IslamabadPIMS Job Advertisement 2024.pdf Islamabad
PIMS Job Advertisement 2024.pdf Islamabad
 
Assessment and Planning in Educational technology.pptx
Assessment and Planning in Educational technology.pptxAssessment and Planning in Educational technology.pptx
Assessment and Planning in Educational technology.pptx
 
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama UniversityNatural birth techniques - Mrs.Akanksha Trivedi Rama University
Natural birth techniques - Mrs.Akanksha Trivedi Rama University
 
Top five deadliest dog breeds in America
Top five deadliest dog breeds in AmericaTop five deadliest dog breeds in America
Top five deadliest dog breeds in America
 
writing about opinions about Australia the movie
writing about opinions about Australia the moviewriting about opinions about Australia the movie
writing about opinions about Australia the movie
 
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...The simplified electron and muon model, Oscillating Spacetime: The Foundation...
The simplified electron and muon model, Oscillating Spacetime: The Foundation...
 
Your Skill Boost Masterclass: Strategies for Effective Upskilling
Your Skill Boost Masterclass: Strategies for Effective UpskillingYour Skill Boost Masterclass: Strategies for Effective Upskilling
Your Skill Boost Masterclass: Strategies for Effective Upskilling
 
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat  Leveraging AI for Diversity, Equity, and InclusionExecutive Directors Chat  Leveraging AI for Diversity, Equity, and Inclusion
Executive Directors Chat Leveraging AI for Diversity, Equity, and Inclusion
 
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
BÀI TẬP BỔ TRỢ TIẾNG ANH 8 CẢ NĂM - GLOBAL SUCCESS - NĂM HỌC 2023-2024 (CÓ FI...
 
Smart-Money for SMC traders good time and ICT
Smart-Money for SMC traders good time and ICTSmart-Money for SMC traders good time and ICT
Smart-Money for SMC traders good time and ICT
 
CACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdfCACJapan - GROUP Presentation 1- Wk 4.pdf
CACJapan - GROUP Presentation 1- Wk 4.pdf
 
Introduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp NetworkIntroduction to AI for Nonprofits with Tapp Network
Introduction to AI for Nonprofits with Tapp Network
 
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...
 
Main Java[All of the Base Concepts}.docx
Main Java[All of the Base Concepts}.docxMain Java[All of the Base Concepts}.docx
Main Java[All of the Base Concepts}.docx
 
How to Fix the Import Error in the Odoo 17
How to Fix the Import Error in the Odoo 17How to Fix the Import Error in the Odoo 17
How to Fix the Import Error in the Odoo 17
 
The Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collectionThe Diamonds of 2023-2024 in the IGRA collection
The Diamonds of 2023-2024 in the IGRA collection
 
Types of Herbal Cosmetics its standardization.
Types of Herbal Cosmetics its standardization.Types of Herbal Cosmetics its standardization.
Types of Herbal Cosmetics its standardization.
 
A Survey of Techniques for Maximizing LLM Performance.pptx
A Survey of Techniques for Maximizing LLM Performance.pptxA Survey of Techniques for Maximizing LLM Performance.pptx
A Survey of Techniques for Maximizing LLM Performance.pptx
 

ISE_Lecture Week 2-SW Process Models.ppt

  • 1. “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” Yogi Berra
  • 2.  The objective of software engineering is to get software with high quality.  Process is a framework for the tasks that are required to build high-quality software.  A software process is a set of activities and associated results, which produces a software product. Software engineers carry out the activities. Chapter 2 Software Processes 2
  • 3.  The common activities ca be categorized into: 3 • The functionality of the software and constraints on its operation must be defined. Software specification • The software to meet the specification must be produced. Software development • The software must be validated to ensure that it does what the customer wants. Software validation • The software must be evolved to meet the changing requirements of customers. Software evolution
  • 4.  Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.  In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are NO right or wrong software processes. Chapter 2 Software Processes 4
  • 5. A framework that describes the activities performed at each stage of a software development project.
  • 6. 6
  • 7.  Requirements – defines needed information, function, behavior, performance and interfaces.  Design – data structures, software architecture, interface representations, algorithmic details.  Implementation – source code, database, user documentation, testing.
  • 8.  Test – check if all code modules work together and if the system as a whole behaves as per the specifications.  Installation – deployment of system, user-training.  Maintenance – bug fixes, added functionality (an on-going process).
  • 9. Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule
  • 10.  All requirements must be known upfront  Deliverables created for each phase are considered frozen – inhibits flexibility  Can give a false impression of progress  Does not reflect problem-solving nature of software development – iterations of phases  Integration is one big bang at the end  Little opportunity for customer to preview the system (until it may be too late)
  • 11.  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.
  • 12.  A variant of the Waterfall that emphasizes the verification and validation of the product.  Testing of the product is planned in parallel with a corresponding phase of development
  • 13.  Project and Requirements Planning – allocate resources  Product Requirements and Specification Analysis – complete specification of the software system  Architecture or High-Level Design – defines how software functions fulfill the design  Detailed Design – develop algorithms for each architectural component  Production, operation and maintenance – provide for enhancement and corrections  System and acceptance testing – check the entire software system in its environment  Integration and Testing – check that modules interconnect correctly  Unit testing – check that each module acts as expected  Coding – transform algorithms into software
  • 14.  Emphasize planning for verification and validation of the product in early stages of product development  Each deliverable must be testable  Project management can track progress by milestones  Easy to use
  • 15.  Does not easily handle concurrent events  Does not handle iterations or phases  Does not easily handle dynamic changes in requirements  Does not contain risk analysis activities
  • 16.  Excellent choice for systems requiring high reliability – hospital patient control applications  All requirements are known up-front  When it can be modified to handle changing requirements beyond analysis phase  Solution and technology are known
  • 17. Two ways:  System prototyping  Incremental delivery Chapter 2 Software Processes 17
  • 18.  What is software Prototyping? ◦ Prototype is working model of software with some limited functionality.  Stepwise approach to develop software prototype ◦ Basic Requirement identification ◦ Developing the initial prototype ◦ Review of the prototype ◦ Revise and enhance the prototype
  • 20.  Objective - Derive end system requirements Throw away prototyping is one type of approach where an initial prototype is built mainly focusing on the poorly understood requirements. • Once the requirements are understood, prototype is discarded. Requirements document is updated. • Actual system is developed (i.e. a conventional development process) with clear understanding of requirements.
  • 21.  Used to reduce requirements risk.  Initial prototype is developed from outline requirements, delivered for experiment, and modified until risk is acceptably low.  Examples of throwaway prototypes include screen mock-ups and story boards.
  • 22.  Developers may be pressurized to deliver a throw-away prototype as the final system.  This is problematic...  It may be impossible to meet non-functional requirements.  The prototype is almost certainly undocumented.  The system may be poorly structured and therefore difficult to maintain.  Normal quality standards may not have been applied.
  • 23. Air Tank Developer User Mgmt No, no, no! I won’t deliver the prototype to you! Pressurizing the Developer
  • 24.  Developers build a prototype during the requirements phase  Prototype is evaluated by end users  Users give corrective feedback  Developers further refine the prototype  When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
  • 25.  A preliminary project plan is developed  An partial high-level paper model is created  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
  • 26. Customers can “see” the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality
  • 27.  Tendency to discard structured program development for “code-and-fix” development  Bad reputation for “quick-and-dirty” methods  Overall maintainability may be overlooked  Process may continue forever (scope creep)
  • 28. Requirements are unstable or have to be clarified Develop user interfaces Short-lived demonstrations New, original development
  • 29.  The system is developed as a series of versions (increments), with each version adding functionality to the previous version.  In Incremental Model, Project requirements are divided into multiple modules and each module is developed separately.  Finally developed modules are integrated with other modules.  During development of each module, waterfall model is followed for each module development separately.  Each developed module in Incremental Model is standalone feature and could be delivered to the end users to use it.
  • 30. Chapter 2 Software Processes 30
  • 31. Chapter 2 Software Processes 31
  • 32.  Develop high-risk or major functions first  Each release delivers an operational product  Customer can respond to each build  Uses “divide and conquer” breakdown of tasks  Lowers initial delivery cost  Initial product delivery is faster  Customers get important functionality early  Risk of changing requirements is reduced
  • 33.  Requires good planning and design  Requires early definition of a complete and fully functional system to allow for the definition of increments  Well-defined module interfaces are required (some will be developed long before others)  Total cost of the complete system is not lower
  • 34.  Risk, funding, schedule, program complexity, or need for early realization of benefits.  Most of the requirements are known up-front but are expected to evolve over time  A need to get basic functionality to the market early  On projects which have lengthy development schedules  On a project with new technology
  • 35.  The CBD Solution  Systems should be assembled from existing components. Chapter 2 Software Processes 35
  • 36.  A software component is a program module that can be used independently, or can operate in conjunction with other components.  Components should be executable to allow independence. Chapter 2 Software Processes 36
  • 37. What is CBSE?  Component-based software engineering is the idea of building software from established software components, as opposed to building the software from the ground up. Chapter 2 Software Processes 37
  • 38.  Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.  Reuse is now the standard approach for building many types of business system Chapter 2 Software Processes 38
  • 39.  Advantages: reducing cost and risk. faster delivery of software  Disadvantages: Requirement compromises Chapter 2 Software Processes 39
  • 40.  Similar to the incremental model, with more emphasis placed on risk analysis.  Process is represented as a spiral, rather than as a sequence of activities.  Software project repeatedly passes through these phases in iterations.  Risks are explicitly assessed and resolved throughout the process.  Incremental releases of the product, or incremental refinement through each iteration around the spiral. Spiral model is an evolutionary software process model which is a combination of an iterative nature of prototyping and systematic aspects of traditional waterfall model.
  • 41. Development cycles through multiple (3-6) task regions
  • 43. •The objectives, alternatives and constraints of the project are determined and are documented. Planning Phase •All possible alternatives, which can help in developing a cost effective project are analyzed •This phase identify and resolve all the possible risks in the project development. Risk assessment and reduction •The actual development of the project is carried out. •The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same. Development and validation •Developed product is passed on to the customer in order to receive customer’s comments and suggestions. •This phase is very much similar to TESTING phase. •And the next phase of the spiral is planned. Customer Evaluation (Planning)
  • 44.  Provides early indication of unsolvable risks, without much cost  Users see the system early because of rapid prototyping tools  Critical high-risk functions are developed first  The design does not have to be perfect  Users can be closely tied to all lifecycle steps  Early and frequent feedback from users  Cumulative costs assessed frequently
  • 45.
  • 46.  When creation of a prototype is appropriate  When costs and risk evaluation is important  For medium to high-risk projects  Long-term project commitment unwise because of potential changes to economic priorities  Users are unsure of their needs  Requirements are complex  New product line  Significant changes are expected (research and exploration)
  • 47.  Speed up or bypass one or more life cycle phases  Usually less formal and reduced scope  Used for time-critical applications  Used in organizations that employ disciplined methods
  • 48. Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross- functional teams. 48
  • 49. 49