Introduction to Software Development

Program Development Life Cycle (PDLC)

The Program Development Life Cycle is a systematic process used to design, develop, test, and
maintain software programs. It ensures that the final product meets user requirements, functions
correctly, and is efficient and reliable.

The PDLC consists of four main stages:

1. Analysis (Problem Definition)
Description

The analysis stage involves understanding and clearly defining the problem that the program is
intended to solve. It forms the foundation of the entire development process.

Key Activities

Requirements Specification

 Identify functional requirements (what the system should do)

 Identify technical requirements (hardware, software, constraints)
 Identify operational requirements (user interaction, environment)
 Produce a requirements document that acts as a blueprint for development

Problem Understanding

 Define the inputs, processes, and outputs

 Identify users and their needs
 Determine constraints and limitations

Approaches to Planning a Solution

Bottom-Up Approach

 Start by developing smaller components or modules

 Combine them to form a complete system
 Encourages reusability and modular design

Top-Down Approach

 Begin with an overview of the entire system

 Break it down into smaller, manageable components
 Provides a clear structure and hierarchy

Importance

 Prevents ambiguity and misunderstandings

 Reduces errors in later stages
 Saves time and cost by avoiding rework
2. Design (Solution Planning)
Description

In this stage, the solution to the problem is planned in detail before implementation begins. It
focuses on how the system will operate internally.

Key Activities

Algorithm Design

 Develop a step-by-step procedure to solve the problem logically

Data Structure Selection

 Choose appropriate ways to store and manage data

o Arrays, lists, stacks, queues, or databases

Tools Used

Flowcharts

 Graphical representation of the program logic

 Use symbols to show processes, decisions, and flow

Pseudocode

 Structured, human-readable representation of the algorithm

Example:

START
INPUT number
IF number > 0
PRINT "Positive"
ELSE
PRINT "Negative"
END

Objective

 Provide a clear and structured blueprint

 Reduce complexity during coding
 Ensure logical correctness before implementation
3. Coding (Implementation)
Description

The coding stage involves translating the design into a programming language to create a
functional program.

Key Activities

Selection of Programming Language

 Based on:
o Application type
o Performance requirements
o Platform compatibility

Examples include Python, Java, and C++.

Program Development

 Write code according to the algorithm and design

 Use proper structure, naming conventions, and comments
 Organize code into modules or functions

Debugging

 Identify and correct errors:

o Syntax errors (violations of language rules)
o Runtime errors (occur during execution)
o Logical errors (incorrect results despite correct execution)

Objective

 Convert the planned solution into an executable program

 Ensure readability, maintainability, and efficiency
4. Testing (Verification and Validation)
Description

Testing ensures that the program operates correctly and meets all specified requirements.

Types of Testing

Unit Testing

 Tests individual components or modules

Integration Testing

 Tests combined modules to ensure they work together

System Testing

 Tests the entire system as a whole

User Acceptance Testing (UAT)

 Confirms that the system meets user expectations and requirements

Key Activities

 Execute test cases

 Compare expected results with actual outputs
 Identify and fix defects
 Retest after corrections

Objective

 Ensure accuracy, reliability, and performance

 Deliver a high-quality, error-free program

Iterative Nature of PDLC

Although the stages are presented sequentially, the PDLC is often iterative. Issues discovered
during testing may require revisiting earlier stages such as design or analysis. This iterative
approach improves the overall quality of the software.

Summary Table
Stage Purpose Output

Analysis Understand and define the problem Requirements specification

Design Plan the solution Algorithms, flowcharts

Coding Implement the solution Source code

Testing Verify correctness Tested and validated software

Waterfall Model
The Waterfall Model is a linear and sequential software development approach in which
progress flows in one direction—downwards—through a series of distinct phases. Each phase
must be completed before the next begins, and there is minimal overlap between stages.

It is one of the earliest and most structured models used in software development.

Key Characteristics
 Sequential progression through phases
 Each stage depends on the completion of the previous one
 Clear documentation at every stage
 Limited flexibility once development begins

Phases of the Waterfall Model

1. Analysis (Requirements Gathering)
Description

This phase involves collecting and defining all system requirements in detail.

Activities

 Identify user needs and expectations

 Define system functionality and constraints
 Document requirements in a formal specification

Output

 Requirements Specification Document

Importance

Errors at this stage can affect all subsequent phases, making accuracy critical.
2. Design (System Planning)
Description

The system architecture and design are created based on the requirements.

Activities

 Develop algorithms and workflows

 Design system architecture (high-level and detailed)
 Select data structures and technologies

Tools

 Flowcharts
 Pseudocode
 System diagrams

Output

 Design Document

3. Coding (Implementation)
Description

The design is translated into a working program using a programming language.

Activities

 Write source code

 Implement modules and components
 Follow coding standards and structure

Output

 Executable program or software system

4. Testing (Verification)
Description

The system is tested to ensure it meets the specified requirements and is free of defects.
Activities

 Perform unit, integration, and system testing

 Identify and fix errors
 Validate outputs against expected results

Output

 Tested and verified software

5. Maintenance (Post-Deployment Support)

Description

After deployment, the software is maintained to ensure continued functionality and

improvement.

Activities

 Fix bugs discovered after release

 Update system features
 Adapt to changes in environment or user needs

Types of Maintenance

 Corrective (fixing errors)

 Adaptive (adjusting to environment changes)
 Perfective (enhancing features)

Flow of the Model

Downward Arrows

 Represent progression to the next stage

 The output of one phase becomes the input for the next

Upward Arrows

 Indicate the need to return to a previous phase

 Occur when issues are found that require earlier corrections
Advantages
 Simple and easy to understand
 Well-structured with clear stages
 Strong documentation at each phase
 Suitable for small projects with well-defined requirements

Disadvantages
 Inflexible to changes once development starts
 Errors discovered late can be costly to fix
 Limited user involvement after the analysis phase
 Not suitable for complex or evolving projects

When to Use the Waterfall Model

 Requirements are clearly defined and unlikely to change
 The project is small or straightforward
 High emphasis on documentation is required
 The development environment is stable

Example Scenario
Developing a basic payroll system:

1. Analysis
o Define salary calculations, employee data requirements
2. Design
o Plan database structure and calculation algorithms
3. Coding
o Implement payroll processing logic
4. Testing
o Verify salary calculations and data handling
5. Maintenance
o Update tax rules or fix errors after deployment
Your statement is partially correct, but it needs refinement for accuracy.

Clarification of the Waterfall Model

In the Waterfall Model, it is generally assumed that:

 Each phase must be fully completed before moving to the next

 There is no planned return to earlier stages
 Changes are difficult and costly once a phase is finished

Can We Go Back to Earlier Stages?

Theoretical Perspective

In the pure Waterfall Model:

 You do not go back to earlier phases

 The process is strictly linear and one-directional

Practical (Real-World) Perspective

In reality:

 It is possible to go back, but:

o It is not intended
o It is expensive and time-consuming
o It may require redoing documentation, design, and code

This is what the upward arrows in your diagram represent:

 Returning to a previous stage when a problem is discovered

Correct Way to State It

Instead of saying:
"We cannot make changes back to the first part"

A more accurate statement would be:

 "The Waterfall Model does not easily allow returning to earlier stages once a phase is
completed."
 "Changes in earlier stages are difficult and costly in the Waterfall Model."
 "The model is designed to be sequential, with minimal backward movement."

Key Insight
The limitation you mentioned is actually one of the main disadvantages of the Waterfall Model:

 Lack of flexibility
 Poor adaptability to changing requirements
Iterative Model
The Iterative Model is a software development approach in which the system is developed
through repeated cycles (iterations). Each iteration goes through a series of phases, gradually
refining and expanding the system until it is complete.

Unlike linear models, it allows for continuous improvement and flexibility throughout
development.

Key Characteristics
 Development occurs in small, repeated cycles
 Each iteration produces a working version of the software
 Requirements can be refined over time
 Feedback is incorporated at every stage
 Errors are identified and corrected early

Core Concept
Instead of building the entire system at once, the process:

 Starts with a small subset of requirements

 Develops a basic version of the system
 Improves and expands it through successive iterations
Phases in Each Iteration
Each cycle typically includes the following stages:

1. Analysis (Requirements Identification)

Description

A subset of requirements is selected and analyzed for the current iteration.

Activities

 Identify features to be developed in this cycle

 Understand user needs for those features
 Define inputs, processes, and expected outputs

Output

 Iteration-specific requirements

2. Design (Solution Planning)

Description

Design solutions for the selected requirements.

Activities

 Create algorithms and workflows

 Plan system structure for the iteration
 Choose appropriate data structures

Output

 Design for the current version

3. Coding (Implementation)
Description

Develop the selected features based on the design.

Activities

 Write and integrate code

 Build functional components
 Ensure code follows standards

Output

 Working version of the software (partial system)

4. Testing (Evaluation)
Description

Test the implemented features to ensure correctness.

Activities

 Perform unit and integration testing

 Identify and fix errors
 Validate against requirements

Output

 Tested and improved version

Iteration Cycle
After testing:

 Feedback is collected
 Improvements are identified
 The next iteration begins

Each cycle adds new features or enhances existing ones until the system is complete.

Flow of the Model

  The process is cyclical rather than linear
 Each stage feeds into the next within the same iteration
 After completion of one cycle, the process repeats

Advantages
 Flexible and adaptable to changing requirements
 Early delivery of partial working systems
 Continuous user feedback improves quality
 Errors are detected and resolved early
 Reduced risk compared to linear models

Disadvantages
 Requires careful planning and management
 Can be more complex than linear models
 May lead to scope creep if not controlled
 Documentation may be less structured

When to Use the Iterative Model

 Requirements are not fully defined at the beginning
 The project is large or complex
 Continuous user feedback is important
 Early versions of the system are needed

Example Scenario
Developing an online shopping system:

Iteration 1:

 Basic user login and product viewing

Iteration 2:

 Add shopping cart functionality

Iteration 3:

 Implement payment system

Iteration 4:

 Enhance user interface and add recommendations

Each iteration improves the system until it is complete.

Comparison with Waterfall Model

Aspect Waterfall Model Iterative Model

Structure Linear and sequential Cyclical and repetitive

Flexibility Low High

Requirement Fixed at the start Evolving over time

Testing After development In every iteration

User Feedback Limited Continuous

It’s a software development approach used to build applications quickly by focusing on:

 Rapid prototyping (creating early versions of the software)

 Frequent user feedback
 Short development cycles (iterations)

In simple terms:

Instead of spending a long time planning everything upfront, RAD builds a quick working
version, shows it to users, improves it, and repeats this process until the final product is ready.
Key idea:

👉 Build fast → get feedback → improve → repeat

Example:

If you're making an app:

 You first create a basic version (prototype)

 Users try it and give feedback
 You update it quickly
 Keep refining until it’s complete

It’s especially useful when:

 Requirements may change

 Speed is important
 User experience matters a lot
This image shows an example of iteration (looping) in programming.

What it is:

It’s demonstrating how a program repeatedly performs steps to generate values from 1² up to N²
(squares of numbers).

Key concept:

👉 Iteration means repeating a set of instructions until a condition is met.

What’s happening in the diagram:

1. INPUT N → You enter a number (like 5)

2. Initialize values → Set a counter (start at 1)
3. The program loops:
o Square it → calculate (1^2, 2^2, 3^2...)
o Output result
o Increment count → move to the next number
4. Stop condition → when the count becomes greater than N
Simple example:

If N = 3, the program will output:

 1² = 1
 2² = 4
 3² = 9

In short:

🔁 It’s a loop that:

starts → repeats steps → stops when done

If you want, I can show you how this looks in actual code (Python, Java, etc.).
Types of Error:
Got it—let’s explain each point in a very simple way:

1. Bad code (syntax or logic errors)

 What it means: The programmer wrote something wrong.

 Example: Missing a bracket, or writing the wrong formula.
 Result: Program crashes or gives wrong answers.

2. Building the wrong thing (requirement errors)

 What it means: The software doesn’t match what users actually need.
 Example: A login system that doesn’t allow password reset.
 Result: It works technically, but is useless or frustrating.

3. Design problems (architecture/logic flaws)

 What it means: The overall plan of the software is poorly designed.

 Example: Parts of the system don’t communicate properly.
 Result: Bugs, slow performance, or strange behavior.

4. Confusing interface (UI errors)

 What it means: The app is hard to use.

 Example: Buttons are unclear, or instructions are missing.
 Result: Users make mistakes or get frustrated.

5. Hardware problems

 What it means: The physical computer parts fail.

 Example: RAM errors, hard disk failure.
 Result: Crashes, lost data, or corrupted files.
TESTING:

The image explains stub testing.

In simple terms, stub testing means creating small, fake versions of parts of a program that are
not ready yet. These fake parts are called stubs.

Instead of building the whole system, developers:

 Replace missing or unfinished parts with simple dummy functions

 Make those functions return basic or fixed data
 Test how the rest of the program behaves

In the code shown:

 fetch_user_info() is a stub that pretends to get user data but just returns None
 process_user_info() works with whatever data it gets
 display_processed_info() pretends to show results
 The main() function connects everything and runs it

So, even though the real data-fetching part is not built yet, the program can still be tested.
Black Box Testing means testing a program without looking at how it works inside.

In simple words:

 You only care about what you put in (input) and what you get out (output)
 You do not look at the code or internal logic

Think of it like using a vending machine:

 You press a button (input)

 You get a drink (output)
 You don’t need to know how the machine works inside

Key idea:

 Check if the system behaves correctly based on requirements

 Focus on results, not the internal process

Example:
If you test a login system:

 Enter username and password

 Check if it logs in correctly or shows an error
 You don’t care how the login is coded internally

Why it’s useful:

 Tests the system from a user’s point of view

 Helps find missing or incorrect functionality
 Does not require programming knowledge