0% found this document useful (0 votes)
60 views52 pages

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

This document discusses processes and process models for software development. It defines a process as a series of steps involving activities, constraints, and resources to produce an intended output. Key characteristics of processes include prescribed activities, use of resources subject to constraints, and production of intermediate and final products. Common software process models described include waterfall, prototyping, spiral, unified process, rapid application development (RAD), and agile methods like extreme programming (XP) and Scrum.

Uploaded by

xxx
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
60 views52 pages

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

This document discusses processes and process models for software development. It defines a process as a series of steps involving activities, constraints, and resources to produce an intended output. Key characteristics of processes include prescribed activities, use of resources subject to constraints, and production of intermediate and final products. Common software process models described include waterfall, prototyping, spiral, unified process, rapid application development (RAD), and agile methods like extreme programming (XP) and Scrum.

Uploaded by

xxx
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 52

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.)
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
Waterfall Model (Contd.)
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.)
Phased Development (Contd.)
Incremental
development:
starts with small
functional
subsystem and adds
functionality with
each new release
Phased Development (Contd.)
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
Unified Process Model (Contd.)

Images’ Source: Systems Analysis and Design in a Changing World, 4th Edition
Unified Process Model (Contd.)
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
Unified Process Model (Contd.)

ng World, 4th Edition


Unified Process Model (Contd.)
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.)
Agile Methods (Contd.)
Extreme Programming (XP)
XP
Development
Approach
Agile Methods (Contd.)
Scrum:
A quick, adaptive, and self-organizing development
methodology
Responds to a current situation as rapidly and positively
as possible
Agile Methods (Contd.)
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
Agile Methods (Contd.)
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
Agile Methods (Contd.)
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
Agile Methods (Contd.)
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

You might also like