Lecture 5-6-7-8 Software Process Models 20200926

What Do We Mean by a Process?
Is a series of steps involving activities, constraints, and

resources to produce an intended output
Prepare for exams
Conduct a software competition
Organize a trip
Write a term project report
Involves a set of tools and techniques
Block diagrams
Notations
How is a Process Useful?
Impose consistency and structure on a set of activities
Guide us to understand, control, examine, and
improve the activities
Enable us to capture our experiences and pass them
along
Characteristics of a Process
Prescribes all major process activities
Uses resources, subject to set of constraints (such as
schedule)
Produces intermediate and final products
May be composed of sub-processes with hierarchy or links
Each process activity has entry and exit criteria
Activities are organized in sequence, so timing is clear
Each process guiding principles, including goals of each
activity
Constraints may apply to an activity, resource or product
Software Lifecycle
When a process involves building a software (product), the
process may be referred to as software (product) lifecycle
Requirements analysis and definition
System (architecture) design
Program (detailed/procedural) design
Writing programs (coding/implementation)
Testing: unit, integration, system
System delivery (deployment)
Maintenance
What is a Process Model?
Description of a process, evolved overtime, in a
certain format
May use text, pictures, or a combination
Contains key process features
Why is a Process Model Needed?
To form a common understanding
To find inconsistencies, redundancies, omissions
To find and evaluate appropriate activities for
reaching process goals
To tailor a general process for a particular situation
in which it will be used
Nature of Software Process Model?
Models that prescribe how should development of
software progress
Models that describe how is software developed in
actuality
Framework Activities
Communication
customer, other stakeholders
Planning
Roadmap, project plan
Modeling
Understanding requirements, provide design
Construction
Code generation, testing
Deployment
Delivery to customer, feedback and evaluation
Process Flow
Software Development Process Models
Waterfall model
Classical
With prototyping
V model
Prototyping model
Phased development: increments and iterations
Spiral model
Unified process
Rapid Application Development (RAD)
Agile methods
XP
Scrum
Kanban
Waterfall Model
One of the first process development models proposed
Works for well understood problems with minimal or no
changes in the requirements
Simple and easy to explain to customers
It presents
a very high-level view of the development process
sequence of process activities
Each major phase is marked by milestones and
deliverables (artefacts)
Waterfall Model (Contd.)
Provides no guidance how to handle changes to products and
activities during development (assumes requirements can be
frozen)
Views software development as manufacturing process rather
than as building process
There are no iterative activities that lead to building a final
product
Long wait before a final product
Generates lots of documentation
Considered suitable for large projects
Uncontrolled Software Development Process
No Iterations in WF?
Loop: Problem Definition, Technical Design and Development, Integration, Operations and Maintenance
Waterfall Model with Prototyping
A prototype is a partially developed product
Prototyping helps
developers assess alternative design strategies (design
prototype)
users understand what the system will be like (user
interface prototype)
Waterfall Model with Prototyping
V Model
A variant of the waterfall model
Uses unit testing to verify procedural design
Uses integration testing to verify architectural
(system) design
Uses acceptance testing to validate the requirements
If problems are found during verification and
validation, the left side of the V can be re-executed
before testing on the right side is re-enacted
Verification: Each function works correctly
Validation: All requirements have been implemented and each functionality can be traced
back to a particular requirement
V Model (Contd.)
Phased Development
Cycle time
Time between when requirements document was written and when
the system was delivered
Shorter cycle time
Decomposed system
System delivered in pieces
 enables customers to have some functionality while the rest is being
developed
Two systems functioning in parallel
the production system (release n): currently being used
the development system (release n+1): the next version
Phased Development (Contd.)
Incremental
development:
starts with small
functional
subsystem and adds
functionality with
each new release
Training on early release
Responsive developers
Markets for early functionality
Quick and Global fixing on unanticipated
problems
Ability to work on different areas of expertise with
different releases
Prototyping Model
Allows repeated investigation of the requirements or
design
Reduces risk and uncertainty in the development
Prototyping Model (Contd.)
Features
User involvement?
Smaller projects?
Spiral Model
Suggested by Boehm (1988)
Combines development activities with risk management
to minimize and control risks
The model is presented as a spiral in which each iteration
is represented by a circuit around four major activities
Plan
Determine goals, alternatives and constraints
Evaluate alternatives and risks
Develop and test
Spiral Model (Contd.)
Unified Process Model
Object-oriented system development methodology
(system development process)
 Offered by Rational/IBM, UP developed by Booch,
Rumbaugh, and Jacobson
 UP should be tailored to organizational and project
needs
 Highly iterative life cycle
 Project will be use-case driven and modeled using
UML
Unified Process Model (Contd.)
UP life cycle:
Includes four phases which consist of iterations
Iterations are “mini-projects”
 Four Phases:
Inception – develop and refine system vision
Elaboration – define requirements and design and
implement core architecture
Construction – continue design and implementation of
routine, less risky parts
Transition – move the system into operational mode
Images’ Source: Systems Analysis and Design in a Changing World, 4th Edition
Related development activities are called disciplines
UP disciplines:
Business modeling, requirements, design,
implementation, testing, deployment, project
management, configuration and change management,
and environment
 Each iteration includes activities from all disciplines
 Activities in each discipline produce artefacts –
models, documents, source code, and executables
ng World, 4th Edition

Rapid Application
Development
Cycle Time?
Requirements? if not?
Resources? Teams? Scope?
Commitment?
Modular? If not?
High technical risks?
New app?
New technology?
Interoperability?
Agile Methods
Emphasis on flexibility in producing software quickly
and capably in rapidly changing environment
Market condition
End-user needs
Competitive threats
Process models can deal with software engineers
frailty in 2 ways:
Discipline?
Tolerance?
Agile Methods, Chapter 05, SE Book by Pressman et al.
Agile Methods
Assumptions to be addressed:
Which requirements will persist/change? How willy the
i lit
customer priorities change?
tab
d c
The extent/amount of design work beforeicoding and testing?
Planning of all engineering activities?pr
e
U n
 Adaptable?
Progress or no progress?
Incremental
Customer feedback
Portion of an operational system
Agile Methods
Agile manifesto
Concentrate on responding to change rather than on
creating a plan and then following it (chaordic)
Value individuals and interactions over process and
tools
Prefer to invest time in producing working software
rather than in producing comprehensive documentation
Focus on customer collaboration rather than contract
negotiation
Agile Methods
Agile Methods (Contd.)
Extreme Programming (XP)
XP
Development
Approach
Scrum:
A quick, adaptive, and self-organizing development
methodology
Responds to a current situation as rapidly and positively
as possible
Scrum Philosophy
Responsive to a highly changing, dynamic environment
Focuses primarily on the team level
 Team exerts total control over its own organization and work
processes
Uses a product backlog as the basic control mechanism
 Prioritized list of user requirements used to choose work to be
done during a Scrum project
Scrum Organization
Product owner
 The client stakeholder for whom a system is being built
 Maintains the product backlog list and priorities
Scrum master
 Person in charge of a Scrum project, leads meetings, assesses
responses
Scrum team or teams
 Small group of developers
 Set their own goals and distribute work among themselves
Scrum Process Flow
Scrum Practices
Sprint
 The basic work process in Scrum
 A time-controlled mini-project
 Firm 30-day time box with a specific goal or deliverable
 Parts of a sprint
Begins with a one-day planning session
A short daily Scrum meeting to report progress
Ends with a final half-day review
Human Factors
Competence
 Knowledge of the process
Common focus
 Deliver a working s/w increment within promised time
Collaboration
 Assess, analyze, use, create information
Decision making ability
 autonomy
Fuzzy problem solving ability
Mutual trust and respect
Self organization
 Itslef
 Process
 Work
Cost of Change and Agile Methods
Process Models (Recap)
Waterfall model
Classical
With prototyping
V model
Incremental Models
Phased development in increment
Rapid Application Development (RAD)
Evolutionary Models
Prototyping model
Spiral model
Unified process
Agile methods
XP
Scrum
Kanban
Framework Activities
Communication
customer, other stakeholders
Planning
Roadmap, project plan
Modeling
Understanding requirements, provide design
Construction
Code generation, testing
Deployment
Delivery to customer, feedback and evaluation
Umbrella Activities
Quality Assurance
Configuration Management
Technical Reviews
Project Tracking and Control
Risk Management
Software Engineering Practice
Understand the problem
Plan a solution
Carry out the plan
Examine the results for accuracy
Software Engineering Practice
Understand the problem (communication, analysis)
Plan a solution (modeling and design)
Carry out the plan (code generation)
Examine the results for accuracy (testing and QA)
Software Engineering Principles
Provide value to customer
Design should be as simple as possible
Maintain a clear vision
Always specify design, implement accordingly so that
others can understand
Software should be ready to adapt to changes
Plan ahead for reuse
Place clear, complete thought before action

Lecture 5-6-7-8 Software Process Models 20200926

Uploaded by

Copyright:

Available Formats

Lecture 5-6-7-8 Software Process Models 20200926

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 5-6-7-8 Software Process Models 20200926

Uploaded by

Copyright:

Available Formats

What Do We Mean by a Process?

Is a series of steps involving activities, constraints, and

ng World, 4th Edition

You might also like