Generic Process Model
The software development process has five main activities:
1. Communication:
Talk with the customer to understand their needs and collect requirements.
2. Planning:
Make a project plan that lists the work, risks, resources, and timeline.
3. Modeling:
Create models (like diagrams) to understand requirements and design the solution.
4. Construction:
Write the code and test it to find and fix errors.
5. Deployment:
Give the software to the customer and get feedback.
---
These five activities can be used for:
Small programs
Large web applications
Complex systems
Along with these, there are umbrella activities like:
Tracking progress
Managing risks
Ensuring quality
Managing changes
Reviewing work
---
Process Flows (How Activities are Done):
1. Linear Flow:
Activities happen one after another, step by step.
2. Iterative Flow:
Some activities are repeated before moving ahead.
3. Evolutionary Flow:
Activities are repeated in a cycle, each time improving the software.
4. Parallel Flow:
Some activities happen at the same time.
Task Set
A task set means the actual steps to complete a specific software activity.
For example, to gather requirements for a small project, the task set can be:
1. List all people involved in the project (stakeholders).
2. Call everyone for a simple meeting.
3. Ask each person to list the features and functions they need.
4. Discuss and create a final list of requirements.
5. Decide which requirements are most important.
6. Write down any unclear or confusing points.
Process Pattern
A process pattern is a common, reusable solution to a regular problem that happens during
software development.
It explains:
The problem faced in the software process.
The situation where the problem happens.
A proven solution to fix the problem.
---
Template for Process Pattern (by Ambler):
1. Pattern Name:
A meaningful name (example: Technical Reviews).
2. Forces:
The situation or issues that cause the problem.
3. Type:
Three types of patterns:
Stage pattern: Problem in a big activity (framework activity).
Task pattern: Problem in a smaller action or task.
Phase pattern: Order of activities in the process.
4. Initial Context:
When and where this pattern is useful.
5. Problem:
What needs to be solved.
6. Solution:
How to fix the problem.
7. Resulting Context:
What the situation looks like after applying the solution.
8. Related Patterns:
Other patterns connected to this one.
9. Known Uses and Examples:
Where this pattern has been used before.
---
Why Process Patterns are Useful:
They help solve common process problems.
They can be used at different levels (big activities or small tasks).
They help create a step-by-step guide from general to detailed activities.
Process Assessment and Improvement
Having a software process doesn’t always mean the software will:
Be delivered on time
Meet customer needs
Have good quality
To make sure the process is effective, it must be checked (assessed) and improved
regularly.
---
Software Process Improvement (SPI) Cycle:
1. Process Measurement:
Measure the current process.
2. Process Analysis:
Study the process to find problems.
3. Process Change:
Make improvements based on the analysis.
---
Approaches to Process Assessment and Improvement:
---
1. CMM & CMMI (Capability Maturity Models)
Used to check how mature (organized) an organization’s software process is.
CMM’s 5 Maturity Levels:
1. Initial: No proper process; success depends on individuals.
2. Repeatable: Some management; past successes can be repeated.
3. Defined: Standard processes used across projects.
4. Managed: Processes tracked using data and numbers.
5. Optimizing: Continuous improvement using feedback.
CMMI Capability Levels:
Level 0: Incomplete (process not fully done)
Level 1: Performed (some work done but not well-managed)
Level 2: Managed (work is tracked and controlled)
Level 3: Defined (standard processes are followed)
Level 4: Quantitatively Managed (uses numbers and data)
Level 5: Optimized (always improving)
---
2. SPICE (ISO/IEC 15504)
A standard to check and improve software processes.
6 Levels in SPICE:
1. Not Performed
2. Performed Informally
3. Planned and Tracked
4. Well Defined
5. Quantitatively Controlled
6. Continuously Improved
---
3. ISO 9001:2000
A quality standard for any organization, including software companies.
It follows the PDCA Cycle:
1. Plan: Decide what to do and how to do it.
2. Do: Carry out the plan.
3. Check: See if the work meets quality standards.
4. Act: Make improvements based on the results.
Software Development Life Cycle (SDLC)
SDLC is a step-by-step process followed to design and develop software properly.
---
Steps of SDLC:
1. Communication:
The user tells the company what software they need.
2. Requirement Gathering:
The development team talks to users and collects all necessary information about what the
software should do.
3. Feasibility Study:
The team checks if the project is possible—technically, financially, and practically.
4. System Analysis:
The team studies the current system, identifies problems, and plans the new software
accordingly.
5. Software Design:
The team creates a blueprint of the software (both logical and physical design) using
diagrams and notes.
6. Coding (Programming):
Developers write the actual program using coding languages.
7. Testing:
The software is tested to find and fix errors. It is tested at different levels to make sure it
works correctly.
8. Integration:
The software is connected with other systems like databases or existing programs.
9. Implementation:
The software is installed on users' computers and set up for use.
10. Operation and Maintenance:
The software is kept up-to-date, bugs are fixed, and users are helped if they face any issues.
What is a Prescriptive Process Model?
It is a fixed step-by-step method to make software.
You have to follow each step in a specific order.
Waterfall Model
Work flows like water in a waterfall — one step after another.
You finish one step, then go to the next.
No going back to previous steps.
Steps in Waterfall Model:
1. Requirements
What should the software do?
Example: The user wants a mobile app to order food.
Output: Requirement document
2. Design
How will the software work?
Includes:
Data structure (how data is stored),
Architecture (overall structure),
Interface (user screens/buttons),
Algorithms (step-by-step logic)
Output: Design diagrams, UI mockups
3. Implementation (Coding)
Write the actual program (source code)
Also includes:
Database creation
User documentation
Initial testing
Output: Working software
4. Testing
Find and fix bugs
Check if software works correctly
5. Deployment
Give the software to users
6. Maintenance (Support)
Fix issues after release
Add new features if needed
Advantages
Very simple and easy to follow.
Good for new teams.
You know what to do at each step.
Works well when the project is clear and stable.
Disadvantages
You can’t make changes easily after a step is done.
Real progress is seen only at the end.
Not good if the requirements keep changing.
If you find a big mistake late, it’s hard to fix.
The Waterfall model is like a step-by-step recipe to build software.
It’s good for simple projects where everything is known in advance.
What is the V-Model?
The V-Model is a modified version of the Waterfall Model.
It shows how each development step (on the left side of the V) is matched with a testing step
(on the right side of the V).
It helps with verification and validation (checking if software is built correctly and works
correctly).
Vmodel
V-Model Simple Steps:
1. Project Planning – Plan team, time, and work.
2. Requirements – What should the software do?
3. Design – How will it work? (High level + detailed)
4. Coding – Write the actual program.
5. Testing – After coding, test step-by-step:
Unit Testing – Test small parts (units).
Integration Testing – Test parts working together.
System Testing – Test the whole system.
Acceptance Testing – Check if the user is happy.
6. Maintenance – Fix problems after delivery.
Good Points of V-Model:
Testing is planned early.
Easy to track each development step with a matching test.
More careful checking of software.
---
Problems with V-Model (same as Waterfall):
1. Real projects don’t always go in order. You may need to go back and change something.
2. Customers often don’t know all the requirements in the beginning.
3. Customers need patience – they only see the full product at the end.
In Short:
The V-Model is like the Waterfall Model, but shaped like a V.
It shows that for every building step, there's a testing step.
It improves quality but is still not flexible for changing needs.
What is the Incremental Model?
The Incremental Model builds the software step by step (in small parts).
Each step is called an increment.
Every increment adds new features to the software.
The first increment gives a basic working version (core product).
Later increments improve and add more features.
How it Works:
1. Start with a basic version of the software (core product).
2. Give it to the customer to use and give feedback.
3. Plan and build the next version with more features.
4. Repeat until the full software is complete.
Example:
Let’s say you’re making a food delivery app:
Increment 1: The user can see the menu and place order.
Increment 2: Add payment feature.
Increment 3: Add order tracking.
Increment 4: Add ratings and feedback.
Each step adds new features. The user gets to use the app early and gives feedback.
Advantages (Strengths):
High-risk features first - You can build and test the most important parts early.
Each step is useful - Every increment gives a working product.
Early feedback - Customers can use and give suggestions after each step.
Divide and conquer -Break big projects into small parts (easy to manage).
Low starting cost - You don’t need big money or a team to start.
Faster delivery Customers get something useful early.
Disadvantages (Weaknesses):
Needs good planning - You must plan the whole system well from the start.
Full system should be known early -You need to know what the final software will include.
Interfaces must be clear - Different parts (modules) must fit together smoothly.
In Short:
Build software in pieces (increments).
The first version is simple, the next versions add more.
The customer sees progress early, and gives feedback.
Good for big projects, tight deadlines, or small teams.
What is the Evolutionary Model?
Software is built step-by-step, getting better and more complete each time.
It is iterative – means we repeat and improve the software after each version.
It is useful when requirements keep changing or are not clear at the beginning.
Two Main Types of Evolutionary Models:
1. Prototyping Model (Most common)
2. Spiral model
What is Prototyping?
A prototype is a rough version of the software, built quickly to show how it works.
It is not the final product.
It helps the customer see and test the idea before building the full software.
Simple Steps in Prototyping:
1. Talk to the customer – understand basic needs (not full details).
2. Make a quick design – simple screens and flow.
3. Build the prototype – only the main parts.
4. Show it to the customer – get feedback.
5. Improve the prototype – fix or add things based on feedback.
6. Repeat until everyone is happy and the final design is clear.
7. Use the prototype to build the real software.
Example:
You are building a mobile app.
The customer is unsure about the design.
You build a basic app (buttons, simple layout) and show it.
The customer says: "Change the color", "Add another screen".
You update and show again.
After a few tries, the customer is happy. Now you build the final app properly.
Advantages (Good points):
Find missing parts - Easy to spot things that were forgotten.
Clear communication - Customers and developers understand each other.
Customer is happy They see results early and give feedback.
Re-use possible You can use the prototype later in design or similar projects.
Fewer rejections Less chances for customers to say “this is not what I wanted.”
Early bug finding Problems are found early.
Disadvantages (Problems):
● Can be costly - Making many versions takes time and money.
● Weak documentation - Too many changes make it hard to write clean documents.
● Too many changes - Customers keep changing their mind – confusing the team.
● Customers may lose interest -If the early version looks bad, they may reject it.
● The problem may be unclear -Not fully understanding the problem causes trouble.
● The system gets complex–Too many changes can make it messy.
In Short:
Prototyping = Build a sample version first, show it to customers, improve it based on
feedback.
Great for unclear or changing requirements.
Helps build the right product with better customer satisfaction.
But can be costly, messy, and hard to manage if not done carefully.
What is the Spiral Model?
The Spiral Model is a step-by-step process that helps you build software in circles (spirals).
Each spiral = one round of development.
After each round, the software gets better and bigger.
It combines:
Prototyping (building & improving)
Waterfall (organized planning)
Risk checking (seeing what can go wrong early)
This model is used again and again until the final software is ready.
Steps in One Spiral (One Round):
1. Plan – Decide what to do in this round.
2. Risk Analysis – Think about what might go wrong and how to solve it.
3. Design and Build – Make part of the software.
4. Test and Review – Check the result and get feedback.
Then repeat for the next spiral!
Advantages (Good Things):
● Early working product. - Software is ready to use early.
● Handles risks well - Finds and fixes risks early.
● Flexible – Easy to change requirements later.
● Great for big projects – Good for large and complex software.
● Customer involved - Customers give feedback early and often.
● Good documentation - Everything is clearly recorded.
● Safe for high-risk projects – Good when a project needs custom features or has
changing needs.
-Disadvantages (Problems):
Disadvantage Simple Meaning
● CostlyNot good for small or simple projects.
● Complex The process is hard to manage and understand.
● Depends on experts Needs skilled people to do risk analysis.
● Time issues Hard to say when the project will finish.
● Can go on forever If not controlled, the spirals may never end.
● No clear end You may not know the final deadline early.
● Not for low-risk work Not needed if the project is simple or low risk.
In Short:
Model type Evolutionary and risk-based
Used for Big, high-risk, changing projects
Working styleRepeat cycles (spirals) of building and testing
Goal Improve software step-by-step while reducing risks
What is the Concurrent Development Model?
The Concurrent Model is like doing many tasks at the same time.
It means different parts of the software development process are happening together, not
one after the other.
That’s why it is also called Concurrent Engineering.
Simple Example:
Imagine you are building a house:
The electric work, plumbing, and painting might happen at the same time, not one after the
other.
If the owner wants to change something in the plan, the team quickly updates it without
waiting for everything else to finish.
This is how the Concurrent Model works in software development.
How It Works:
Activities like planning, designing, coding, and testing can all be in different stages at the
same time.
Each activity has states, like:
Not started
Under development
Awaiting changes
Completed
These activities move between states based on what happens in the project.
Example in a Software Project:
Planning: Completed
Designing: Under development
Coding: Not started yet
Testing: Waiting until coding is done
If the customer asks for a change:
Design may move back to "awaiting changes"
Planning might also need a small update
Everything is connected and can change anytime based on project needs.
Advantages (Good Points):
Everything runs in parallel Many tasks happen at the same time.
Shows real-time project stateYou always know which task is in which stage.
Easy to handle changes Requirements can be changed anytime.
Works for all projectsCan be used for any type of software.
Saves time Faster than step-by-step models.
Disadvantages (Problems):
Can be confusing Many things happen at once – hard to manage.
Needs good planningThe team must coordinate well.
Hard to document May be tough to track everything clearly.
In Short:
● What is it? A model where different software tasks happen together
(concurrently).
● How does it works? Each task has a state (not started, in progress, waiting for
changes, done).
● Good for Projects with changing needs, or where speed and flexibility are
important.
Specialized Process Models
These models are used for specific types of software projects that need a focused approach.
1. Component-Based Development Model
This model builds software by reusing already-made software parts (called components),
instead of creating everything from scratch. It follows an iterative (repeating) and
evolutionary process.
Steps:
Search for existing software components related to the project.
Check how these components can be joined together.
Design the overall system to fit these components.
Combine (integrate) the components into the system.
Test the full system to make sure everything works properly.
Benefits:
Encourages reuse of code.
Helps reduce development time and cost.
2. Formal Methods Model
This model uses mathematics to define and verify software before it is built. It aims to make
sure the software is correct and error-free by using formal (mathematical) specifications.
Advantages:
Helps find and fix problems early (like unclear or incomplete designs).
Makes it easier to verify the software’s correctness.
Drawbacks:
Takes a lot of time and is costly.
Most developers need special training to understand and use it.
Not suitable for clients who are not technically skilled, as it is hard to understand
What is Agility?
Agility means being flexible and quick in responding to changes during software
development. It helps reduce the cost and effort of making changes, even late in the project.
Key Features of Agile:
Focus on customer satisfaction
Early and regular delivery of software
Small, motivated teams
Use of simple and informal methods
Minimal documentation
Strong team collaboration
Agile Process Steps:
1. Communication – Talk with customer to understand needs
2. Planning – Decide what to build and when
3. Modeling – Create basic design/structure
4. Construction – Build and test the software
5. Deployment – Deliver working software to users
Why Agile?
Change is common in software (requirements, team, technology)
Agile teams adapt quickly and work in small parts (increments)
Changes are easy to handle in small steps
Frequent customer feedback helps improve the product
Agile Principles (12):
1. Satisfy the customer with early and continuous delivery
2. Accept changes even late in development
3. Deliver working software often (every 1–2 weeks)
4. Developers and business people must work together
5. Build around motivated people and trust them
6. Prefer face-to-face conversation
7. Working software is the main measure of progress
8. Keep a steady development pace
9. Focus on technical quality and good design
10. Keep things simple—do only what’s needed
11. Let teams self-organize to find the best solutions
12. Regularly reflect and improve the team’s work
Summary:
Agile is about building software in a flexible, fast, and customer-focused way by breaking
work into small parts, getting feedback regularly, and improving continuously.
Human Factors in Agile Teams
Agile focuses a lot on people. Success depends on how well the team works together.
Key Qualities Needed in an Agile Team:
1. Competence
Team members should have the right skills, talent, and knowledge.
2. Common Focus
Everyone should work toward a single goal: deliver working software on time.
3. Collaboration
Team members must work closely with each other and with customers.
4. Decision-Making Ability
Teams should have the freedom to make decisions about their work.
5. Fuzzy Problem Solving
Agile teams should be ready to handle unclear problems and constant changes.
6. Mutual Trust and Respect
Team members should trust and respect each other. A strong team feels united (a "jelled"
team).
7. Self-Organization
The team should manage:
How they work
Their own processes
Their own schedules
Summary:
Agile teams succeed when they are skilled, united, trusted, flexible, and self-organizing.
Extreme Programming (XP)
What is XP?
Extreme Programming (XP) is one of the most popular agile development methods. It
focuses on quick feedback, teamwork, and simple code. It was developed by Kent Beck.
XP Values (Core Beliefs):
1. Communication – Constant and clear talk between team and customer
2. Simplicity – Only build what is needed right now
3. Feedback – From the software, customer, and team
4. Courage – Don’t over-plan for the future; be ready to change
5. Respect – Team members respect each other and the work
XP Process = 4 Main Activities:
1. Planning
Customers write user stories (features) on cards
Each story is given a value (importance) and cost (time needed)
Big stories are split into smaller ones
Stories are grouped into releases
After first release, project velocity (stories completed per release) is calculated to plan future
work
2. Design
Keep design simple (KIS – Keep It Simple)
Use CRC cards to plan classes and their responsibilities
Create spike solutions (small prototypes) to try out risky parts
Use refactoring to improve code without changing behavior
3. Coding
Write unit tests before writing code
Focus on making code pass the tests
Use pair programming – two developers write code together for better quality
4. Testing
Unit tests check small parts of the code
Customer acceptance tests check full features and are written by the customer
All tests are automated for easy re-testing (regression testing)
Key XP Practices:
User stories drive development
Continuous feedback and improvement
Small, frequent releases
Team collaboration and trust
Simple, clean, and tested code
Summary:
XP is about writing code in small steps, getting quick feedback, and working closely with the
customer. It uses practices like pair programming, unit testing, and simple design to build
better software quickly and efficiently.
Industrial Extreme Programming (IXP)
What is IXP?
IXP is an improved version of XP, suitable for large organizations. It still follows XP’s core
ideas but adds more management involvement, customer roles, and stronger technical
practices.
6 New Practices in IXP:
1. Readiness Assessment
Check if the team, tools, and organization are ready for IXP
2. Project Community
Include all important people: developers, customers, managers, etc.
3. Project Chartering
Understand how the project fits in with current systems
4. Test-Driven Management
Set clear goals (called "destinations") and track if they are met
5. Retrospectives
Review each completed increment to learn and improve
6. Continuous Learning
Team members are encouraged to keep learning new skills and techniques
Other Agile Models (Besides XP)
There are several other agile methods used in the industry:
🔹 1. Adaptive Software Development (ASD)
Created by Jim Highsmith
Best for complex projects
Focuses on:
Speculation: Plan based on initial requirements and constraints
Collaboration: Teamwork and creativity are key
Learning: Improve through feedback (focus groups, reviews, postmortems)
2. Scrum
Work is divided into sprints (short time-boxed periods)
Daily meetings (scrum meetings)
Focus on team roles, tasks, and progress tracking
3. Dynamic Systems Development Method (DSDM)
Focus on business needs, active user involvement, and frequent delivery
4. Feature-Driven Development (FDD)
Focuses on designing and building features
Features are small, client-valued pieces of functionality
5. Lean Software Development (LSD)
Inspired by lean manufacturing
Focus on eliminating waste, fast delivery, and continuous improvement
6. Agile Modeling (AM)
Promotes lightweight and practical modeling
Focus on just enough design to move forward
7. Agile Unified Process (AUP)
Simplified version of the Rational Unified Process (RUP)
Agile way to handle modeling, design, coding, and testing
8. Crystal
A family of agile methods
Focuses on team size, project priorities, and safety
Summary:
IXP enhances XP for big organizations with more structure
Other agile models like ASD, Scrum, FDD, DSDM, etc., offer different ways to manage
software projects, but all focus on people, teamwork, and frequent delivery
SCRUM
What is Scrum?
Scrum is an Agile method created by Jeff Sutherland. It breaks the project into small,
manageable time blocks called Sprints.
Key Concepts:
Backlog: A list of features/tasks prioritized by the customer
Sprint: A short (1–4 weeks) development cycle to complete selected backlog items
Scrum Meeting (Daily Stand-up):
Lasts 15 mins
Each team member answers:
What did I do yesterday?
What will I do today?
What problems am I facing?
Scrum Master: Team leader who removes obstacles and facilitates meetings
Demo: At the end of a sprint, working software is shown to the customer
DSDM – Dynamic Systems Development Method
What is DSDM?
DSDM is an Agile method that focuses on fast delivery using incremental prototyping.
DSDM Life Cycle Steps:
1. Feasibility Study – Check if the project is worth doing
2. Business Study – Understand business needs and system structure
3. Functional Model Iteration – Build prototypes for feedback
4. Design and Build Iteration – Improve and finalize prototypes
5. Implementation – Deploy the final product
🔁 Follows 80% Rule – Focus on delivering 80% of value quickly
FDD – Feature-Driven Development
What is FDD?
FDD is an Agile method best for object-oriented projects. Developed by Peter Coad,
improved by Stephen Palmer.
FDD Core Ideas:
1. Feature-Based: Divide the system into small features (e.g., "Calculate total price")
2. Team Collaboration: Developers work closely together
3. Step-by-Step Process (5 Steps):
Develop overall model
Build feature list
Plan by feature
Design by feature
Build by feature
Other Highlights:
Encourages quality: design/code inspections, reviews, metrics
Uses diagrams, text, and discussions to communicate
Focuses on delivering working features continuously
Summary Table:
Method Key Focus Special TermsBest For
Scrum Sprints, daily updatesBacklog, Scrum Master All team sizes
DSDM Fast delivery via prototypes80% rule, Iterations Time-bound projects
FDD. Build by small features Feature list, Code reviews Object-oriented,
larger teams
Lean Software Development (LSD)
What is LSD?
LSD is an Agile method inspired by Lean manufacturing. It aims to deliver value quickly by
removing waste, improving efficiency, and respecting people.
7 Lean Principles:
1. Eliminate Waste
Avoid extra features, unnecessary steps, and delays
Share info clearly and test well to avoid rework
2. Build Quality In
Use automated tests, code reviews, and rigorous testing from the start
3. Create Knowledge
Learn continuously during the development process
4. Defer Commitment
Delay important decisions until the last responsible moment
5. Deliver Fast
Focus on quick delivery of working software
6. Respect People
Trust and value every team member’s input and skills
7. Optimize the Whole
Improve the entire workflow, not just individual tasks
Summary:
LSD is all about working smart, reducing waste, and building quality software quickly with
team respect and collaboration.
Agile Modeling (AM) –
What is AM?
AM is a flexible way to model and document software during Agile projects. It helps handle
complex systems by focusing only on what’s necessary.
Core Modeling Principles in AM:
1. Model with a Purpose
Only create models that serve a clear goal
2. Use Multiple Models
Different diagrams show different things—choose what fits the need
3. Travel Light
Keep only useful models; discard the rest
4. Content over Looks
What a model shows is more important than how it looks
5. Know Your Tools and Models
Understand how and when to use each model effectively
6. Adapt Locally
Adjust your modeling style to your team’s specific needs
Summary:
Agile Modeling is a lightweight, purposeful way of creating only the needed models that help
the team understand, plan, and improve the system.
Agile Unified Process (AUP)
What is AUP?
AUP is a blend of traditional and agile methods. It follows the Unified Process (UP) phases
but uses agile principles like quick delivery and flexibility.
"Serial in the large, iterative in the small" means:
Overall project follows traditional steps (big picture = serial)
Each step is done in small, repeated cycles (details = iterative)
Phases of AUP:
1. Inception – Understand goals and scope
2. Elaboration – Plan the system structure
3. Construction – Build the software incrementally
4. Transition – Deliver the final product and get user feedback
Activities in Each Iteration:
Modeling: Create simple UML diagrams – just enough to move forward
Implementation: Write source code based on models
Testing: Run tests to catch bugs and check if software meets requirements
Deployment: Deliver working software and collect feedback
Supporting Activities:
Configuration & Project Management:
Manage changes, risks, and work progress
Coordinate team tasks and track progress
Environment Management:
Set up tools, standards, and technologies for smooth development
Summary:
AUP is good for projects that need some structure but also want agile flexibility. It uses small
iterations to develop, test, and deliver working software step-by-step.