Software development (4.4)

Modern software is rarely built by a single person. Large projects are developed by teams, often spread across different locations. To manage this complexity and work efficiently, developers use various tools. Key among these are program libraries and program generators. A program library is a collection of pre-written, pre-tested code (like functions or subroutines) that can be reused in many different projects. This saves significant time and effort. For example, instead of writing code to draw a window on the screen from scratch, a developer can use a routine from a graphics library. A program generator is a tool that creates source code automatically from a higher-level description, such as a diagram or a set of parameters, which further speeds up routine coding tasks.

An error, or 'bug', is a fault in a program that causes it to behave in an unintended way. Understanding the different types of errors is the first step to fixing them. There are three main categories:

1. Syntax Errors: These are grammatical mistakes that violate the rules of the programming language. For example, misspelling a keyword like `PRNT` instead of `PRINT`. The compiler or interpreter will detect these errors and prevent the program from running.
2. Logic Errors: The program runs, but produces the wrong output or behaves incorrectly. The syntax is correct, but the algorithm itself is flawed. For example, calculating an average by dividing by the wrong number of items.
3. Run-time Errors: These errors occur while the program is executing. They are often caused by unexpected circumstances, like trying to divide by zero or attempting to open a file that doesn't exist. These errors typically cause the program to crash.

To find errors, developers use a variety of testing methods. These can be broadly categorized as static or dynamic. Static testing involves examining the code or documentation without executing the program. It's like proofreading an essay. The main static methods are:

• Dry Run: A developer manually steps through an algorithm using a set of test data, often with a trace table to track variable values. This is a mental or on-paper exercise to check the logic.
• Walkthrough: A formal review process where a developer presents their code to a small group of peers. The team asks questions and provides feedback to identify potential issues, inconsistencies, or logical flaws.

Dynamic testing involves executing the program with test data to see how it behaves. This is where the program is actually run on a computer. The two main approaches to dynamic testing are white-box and black-box testing.

White-box and black-box testing are two fundamental approaches to dynamic testing. The key difference is the tester's knowledge of the software's internal structure.

White-Box Testing: In this method, the tester has full access to the source code and understands the internal logic, data structures, and paths through the program. The goal is to test these internal structures. Test cases are designed to ensure that every statement is executed, every branch (e.g., in an IF or CASE statement) is taken, and every loop is tested. It is also known as structural or glass-box testing.

Black-Box Testing: In this method, the tester has no knowledge of the internal code or logic. The software is treated as a 'black box'. The tester only knows what the software is supposed to do, based on its requirements specification. Test cases are created based on inputs and the expected outputs. This method is focused entirely on functionality and is also known as functional testing.

Software testing is not a single event but a series of activities that occur at different stages of the development lifecycle. These stages are known as levels of testing.

1. Integration Testing: After individual modules or components have been tested in isolation (unit testing), they are combined and tested as a group. Integration testing aims to find errors in the interfaces and interactions between these integrated modules.
2. Alpha Testing: This is the first phase of testing by end-users. It is performed in-house by the organisation's own QA team or testers before the product is released externally. The goal is to find as many bugs as possible in a controlled environment.
3. Beta Testing: After passing alpha testing, the software is released to a limited number of external users (beta testers) in the real world. These users use the software in their own environment and report back any bugs or issues they find. This is often the final stage of testing before a general release.
4. Acceptance Testing: This is the final testing phase, performed by the client or customer. They test the software to ensure it meets all the requirements laid out in the contract and is 'fit for purpose'. If the software passes acceptance testing, the client formally 'accepts' the product.

Effective testing is not random; it is a planned and systematic process. A Test Plan is a formal document that outlines the entire testing strategy. It details the scope of testing, the features to be tested, the resources required, the schedule, and the specific test cases. A crucial part of a test plan is the selection of appropriate test data. Test data is chosen to systematically check the software's behaviour. There are three main types:

1. Normal Data: Sensible, valid data that the program should accept and process correctly. This tests the program's normal operation.
2. Abnormal (or Erroneous) Data: Data that is invalid and should be rejected by the program. This tests the program's error-handling capabilities, ensuring it doesn't crash and provides a helpful error message.
3. Extreme/Boundary Data: Data that is at the very limits of the valid range. This is used to check how the program handles edge cases. For a given range, there are typically two boundary values (the lower and upper limit) and values just outside the boundary.

Managing a software project involves coordinating many tasks, people, and deadlines. Project planning techniques are essential for this. A Gantt chart is a popular tool for visualizing a project schedule. It is a type of bar chart where the vertical axis lists the tasks to be performed, and the horizontal axis represents time. Each task is represented by a bar; the position and length of the bar reflect the start date, duration, and end date of the task. Gantt charts are excellent for showing 'what' needs to be done and 'when'. They can also show dependencies between tasks, often with arrows linking the end of one task to the beginning of another. This helps managers see which tasks must be completed before others can start, and allows them to track progress against the original plan.

While Gantt charts are good for scheduling, PERT (Program Evaluation and Review Technique) charts excel at showing the dependencies and logical flow of a project. A PERT chart is a network diagram. It consists of:

• Nodes (circles or boxes): These represent project milestones or events (the start or end of a task).
• Arcs (arrows): These represent the actual tasks, showing the dependency between nodes. Each arc is labelled with the task name and its duration.

A key concept in PERT is the Critical Path. This is the longest possible path of sequential tasks through the network diagram from the start node to the finish node. The length of the critical path determines the minimum time required to complete the entire project. Any delay in a task that lies on the critical path will delay the entire project. Tasks not on the critical path have 'float' or 'slack', meaning they can be delayed slightly without affecting the project's overall finish date.