Software development (2.4)

Modern software development rarely starts from scratch. Developers use tools to speed up the process and improve quality. Two key aids are program libraries and program generators. A Program Library is a collection of pre-written, pre-tested code modules that can be 'called' by another program to perform common tasks. For example, instead of writing code to calculate a square root, a developer can use a function from a math library. A Program Generator is a tool that automatically writes source code based on a specification or model. They are often used to create 'boilerplate' code, such as the basic structure of a file, or to generate complex user interfaces by allowing a developer to drag and drop components.

Software errors, often called 'bugs' or 'faults', are an unavoidable part of creating complex software. They can be introduced at any stage: a misunderstanding of the client's needs (requirements analysis), a flaw in the overall structure (design), or a simple typo in the code (coding). The purpose of testing is not to prove that a program is 100% correct, which is practically impossible for complex systems. Instead, testing is a planned process of executing a program with the specific intention of finding errors. To be effective, testing must occur throughout the entire software development lifecycle. Finding and fixing a bug during the early design stage is significantly cheaper and easier than finding it in a finished product that has already been delivered to users.

Testers use several methodologies to find faults. A Dry Run is a mental or on-paper trace of an algorithm's logic, performed by the programmer to spot flaws before coding. A Walkthrough is a more formal peer-review process where a developer presents their code or design to colleagues, who ask questions and suggest improvements. White-box testing requires knowledge of the program's internal code and structure. Test cases are designed to exercise specific paths, loops, and conditions within the code. Black-box testing is the opposite; the tester has no knowledge of the internal workings and tests the software based purely on its requirements specification, checking if the correct outputs are produced for given inputs. Integration testing focuses on verifying that different modules or components of the software work together correctly when they are combined.

As software nears completion, it goes through distinct levels of testing. Alpha testing is the first full-scale test of the near-complete software. It is performed in-house by the organisation's own employees, usually the Quality Assurance (QA) team, in a controlled lab environment. The goal is to find as many bugs as possible before any external users see the product. After successful Alpha testing, the software moves to Beta testing. Here, a pre-release version is distributed to a limited number of external users—real people who are not employees—to use in their own real-world environments. This is invaluable for finding bugs related to different hardware configurations, network speeds, and unexpected user behaviours. Finally, Acceptance testing is performed by the client or end-user. Its purpose is to verify that the software meets all the business requirements agreed upon in the contract, before the client 'accepts' the final product and makes the final payment.

Effective testing is not random; it is a carefully planned activity. A Test Plan is a formal document that outlines the entire testing strategy, including the scope (what will be tested), schedule, resources, and success criteria. A critical part of any test plan is the selection of test data. For a given input, we can select three types of data: Normal data is sensible, valid data that the program is expected to accept and process correctly. Abnormal data (or invalid data) is data that the program should not accept, such as the wrong data type (e.g., text where a number is expected) or a value outside the allowed range. The program should handle this gracefully with an error message, not crash. Extreme/Boundary data is data at the very limits of the valid range. For example, if a valid range is 1-100, the boundary data would be 1 and 100. It is also vital to test the values just outside the boundary (e.g., 0 and 101), as this is where 'off-by-one' logic errors frequently occur.

A Gantt chart is a visual project management tool used to illustrate a project schedule over time. It is a type of bar chart where each bar represents a task. The position and length of the bar indicate the start date, end date, and duration of the task. Key features include: a list of tasks on the vertical axis, a time scale on the horizontal axis, and task bars that show timings. Gantt charts are excellent for showing the overall timeline of a project at a glance. They can also display task dependencies, often shown with arrows connecting the bars, which indicate that one task must be completed before another can begin. Milestones, which are significant deadlines or events, are typically marked with a diamond symbol. The chart can also be updated to show progress, for instance by shading the part of a task bar that has been completed.

A PERT (Program Evaluation and Review Technique) chart, also called a network diagram, is another project planning tool that focuses on tasks and their dependencies. Unlike a Gantt chart, it does not have a time scale. Instead, it uses a graph to represent the project's workflow. Nodes (circles) represent events or milestones (the start or finish of a task), and are numbered for reference. Arcs (arrows) represent the actual tasks, with the task name and its duration written on the arrow. The key strength of a PERT chart is its ability to identify the Critical Path. This is the sequence of tasks that has the longest total duration from the start of the project to the end. The length of the critical path determines the shortest possible time in which the entire project can be completed. Any delay to a task on the critical path will directly delay the project's completion date.