Software Development

Program Development Life cycle

Different projects come with varying requirements, constraints, and objectives, necessitating a flexible approach to
management and development strategies. Here, we'll delve into three primary development life cycle models: Waterfall,
Iterative, and Rapid Application Development (RAD), along with the general stages of the program development life
cycle.

Stages in the Program Development Life Cycle

1. Analysis: This stage involves gathering and analyzing requirements to understand what the software must do and
how it fits within existing systems or processes.

2. Design: Here, the software's architecture is planned, including how the software will be structured and how the
components will interact with each other.

3. Coding: The actual writing of the code based on the design documents, adhering to programming standards and

d
methodologies.

4. Testing: This phase involves verifying that the software works as intended, through unit testing, integration

hi
testing, system testing, and user acceptance testing.

5. Maintenance: After deployment, the software must be maintained. This includes fixing any bugs that are found
and adding new features or updates as required. Za
1. Waterfall Model

Principles: The Waterfall model is one of the earliest software development life cycle (SDLC) models. It is a linear and
sequential approach where each phase must be completed before the next phase can begin. The phases do not overlap.

Benefits:
a

• Simple and easy to understand and use.

• Well-structured approach, making it suitable for smaller projects where requirements are very well understood.
hr

Drawbacks:

• Difficult to incorporate changes after the process has begun.

•
Za

Poor model for complex and object-oriented projects.

• High amounts of risk and uncertainty.

2. Iterative Model

Principles: The Iterative model is based on the repetition of a cycle of software development, where the software is
gradually improved with each iteration. Each version is released in cycles, with each cycle including the phases of
planning, design, coding, and testing.

Benefits:

• Flexibility in accommodating changes and refining requirements over time.

• Early detection of design or requirement issues.

• Incremental testing and debugging during smaller iterations.

1|Page
Drawbacks:

• Can become more complex and difficult to manage than linear models.

• Requires more resources and can be more costly than the Waterfall model.

• Project progress can be hard to measure as everything is not planned in advance.

3. Rapid Application Development (RAD)

Principles: RAD focuses on quick development and delivery of high-quality systems with the least amount of detailed
planning. It encourages user feedback, and the project is designed in a series of iterations based on increasingly refined
requirements.

Benefits:

• Faster development and delivery.

d
• Increased customer satisfaction due to involvement in the development process.

hi
• Reduced development cost and time.

Drawbacks:

• Not suitable for smaller projects.

•
Za
Depends heavily on a strong team and individual performances for identifying business requirements.

• Can lead to a lack of scalability if not carefully managed.

Program Design
Structure Charts
a

Structure charts are used in software engineering for breaking down a system's architecture into smaller, manageable
parts or modules. These charts visually depict the hierarchy and the flow of control and data within the program.
hr

Example Scenario: Consider a simple book inventory system. The main system could be broken down into several sub-
modules: Add Book, Delete Book, Search Book, and Display Inventory.

• Main System: Book Inventory System

Za

• Add Book (parameters: title, author, ISBN)

• Delete Book (parameters: ISBN)

• Search Book (parameters: keyword; returns: list of books)

• Display Inventory (no parameters; returns: current inventory list)

In this structure, the Main System acts as the root, with each sub-task represented as a node stemming from it. Arrows
or lines between the nodes indicate the flow of information, showing how data is passed between different parts of the
system. For instance, Add Book would receive the title, author, and ISBN as inputs and add a new entry to the inventory
database.

2|Page
Purpose of State-Transition Diagrams

State-transition diagrams, on the other hand, are used to document an algorithm or system's behavior in response to
external inputs or events. These diagrams are particularly useful for representing systems that have a number of
different states and show how the system transitions from one state to another based on certain events or conditions.

Example Scenario: In the context of a login system, the states could include Logged Out, Logging In, Logged In, and
Error. The transitions might be triggered by events like Enter Credentials, Submit, Logout, and Error Occurred.

• Logged Out state transitions to Logging In on Enter Credentials.

• Logging In transitions to Logged In on Submit if the credentials are correct, or to Error if incorrect.

• Logged In transitions back to Logged Out on Logout.

• Error state can transition back to Logged Out on Retry.

d
State-transition diagrams help developers and stakeholders understand how the system behaves under various
conditions, providing clarity on the system's logic and flow. They are essential for designing systems with complex

hi
interactions and multiple possible states, such as web applications, payment processing systems, or any system that
needs to handle a variety of inputs and conditions.

Program Testing and Maintenance

Types of Errors and Correction Methods

Za
1. Syntax Errors: These errors occur when the code violates the rules of the programming language. Examples
include missing semicolons, unmatched parentheses, or misspelled keywords.

Correction: Use a code editor or IDE with syntax highlighting and error detection capabilities. Review compiler or
interpreter error messages which usually pinpoint the location and nature of the syntax error.
a

2. Logic Errors: Errors in the way the program logic is structured, leading to incorrect results. These are not caught
hr

by compilers or interpreters.

Correction: Conduct thorough testing, use debugging tools, and perform code reviews to identify and fix logic
errors.
Za

3. Run-time Errors: These errors occur during the execution of the program, such as division by zero or accessing an
out-of-bounds array index.

Correction: Implement error handling and input validation to prevent run-time errors. Use debugging tools to
trace the program execution flow and identify the source of the error.

3|Page
Methods of Testing and Selecting Appropriate Data

1. Dry Run: Manually simulating the execution of the program using pencil and paper to understand the flow of
control and identify potential errors.

2. Walkthrough: A peer review process where the developer explains the logic and flow of the program to
colleagues to identify errors.

3. White-box Testing: Testing the internal structures or workings of an application, as opposed to its functionality
('black-box testing'). It requires knowledge of the internal paths, structures, and implementation of the software
being tested.

4. Black-box Testing: Testing the functionality of an application without peering into its internal structures or
workings. This can be applied to system, integration, and acceptance testing.

5. Integration Testing: Testing combined parts of an application to determine if they function together correctly.

d
6. Alpha and Beta Testing: Alpha testing is conducted internally, while beta testing is distributed externally, to
ensure the product is ready for production.

hi
7. Acceptance Testing: Conducted to determine if the requirements of a specification or contract are met.

8. Stub Testing: Used in integration testing to simulate the behavior of missing components.

Test Data Types:

•
Za
Normal Data: Data that the program is expected to process under normal operation.

• Abnormal Data: Invalid data that should be rejected by the program to test its robustness.

• Extreme/Boundary Data: Data at the limits of what the program should be able to handle, to test the
boundaries of the program's capabilities.
a

Test Strategy and Test Plan

hr

A test strategy outlines the general approach to testing, including the testing objectives, resources, time schedule, and
methods of testing. A test plan is more detailed and includes specific test cases, conditions under which each test will be
conducted, and the expected outcomes.

Test Plan Contents might include:

Za

• Objectives and scope of testing

• Test items

• Features to be tested and not tested

• Test approach and methodology

• Pass/Fail criteria

• Test deliverables

• Test environment requirements

• Test schedule

4|Page
Continuing Maintenance of a System

Maintenance ensures the software continues to operate correctly throughout its life. Types of maintenance include:

1. Corrective Maintenance: Fixing bugs found in the software after it has been released.

2. Adaptive Maintenance: Modifying the software to work in a new or changed environment.

3. Perfective Maintenance: Enhancing the functionality of the software and improving performance.

Enhancing Functionality

Analysing and enhancing an existing program involves reviewing the current codebase, identifying areas for
improvement or addition, and implementing these changes while ensuring that the new code does not introduce new
errors. This process should include rigorous testing to validate the enhancements and ensure they meet the desired
objectives.

d
hi
Za
a
hr
Za

5|Page