Aspects of software development study guide

Build the process as a chain

Start by defining the problem. The requirements describe what the system must provide, so they should be established through interaction with intended users rather than being inferred solely by the developer. A data model represents the aspects of the external world that are relevant to the program. Abstraction is useful because the model focuses on relevant aspects instead of attempting to represent everything.

Next, explain how the requirements become a design. The design should specify data structures for the data model, algorithms for processing, a modular structure and the human user interface. When discussing modules, refer to clear, documented interfaces: this makes the responsibilities and interactions of modular parts explicit. Design is not necessarily a one-off activity; prototyping or an agile approach can allow the design to change as requirements become clearer.

For implementation questions, connect the model and algorithms to data structures and code. A strong explanation does more than state that code was written: it explains how the program works and uses logical reasoning, test data and user feedback to argue for correctness and efficiency. In an iterative approach, the critical path can be solved first so that the essential part of the solution is developed before less critical parts.

Apply testing precisely

When asked to design tests, identify the input category and its purpose. Normal data represents typical valid input. Boundary data explores relevant limits. Erroneous data is invalid and should test the system's response to errors. A set containing only normal data cannot demonstrate that boundary and erroneous cases have been considered. Testing is concerned with finding errors in the implementation; it should not be presented as proof that the system automatically satisfies every user requirement.

Acceptance testing has a different emphasis. Intended users should assess whether the solution meets its specification, and the evidence required is user feedback, not a description of every test carried out by the end user. In an evaluation response, use the criteria for evaluating a computer system and relate the judgement to the developed solution rather than merely listing tests.

Self-check

Can you distinguish a requirement from a design decision? Can you explain why a data model and abstraction are used? Can you identify data structures, algorithms, modules and interface design as parts of design? Can you justify the inclusion of normal, boundary and erroneous test data? Can you distinguish implementation testing from acceptance testing and evaluation? Finally, can you explain how prototyping or an agile approach may affect requirements, design and implementation without treating development as a completely fixed sequence?