The Software Development Process

From Higher Computing Science
Jump to: navigation, search

Key points

  • Software development is carried out by going through a series of stages. The stages may be carried out in order, but sometimes revisited if more work needs to be completed.
  • The stages are analysis, design, implementation, testing, documentation, evaluation and maintenance.
  • This approach is iterative - this means that stages, or groups of stages, may be repeated


  • In the analysis stage, the client and the systems analyst discuss the plans for the project.
  • In the analysis stage, the systems analyst tries to capture the most accurate description of what the client wants, using interviews, questionnaires and workplace observations
  • The systems analyst will produce a software specification, a legally binding document that acts as the agreement between the client and systems analyst, describing exactly what will be created in the project


  • In the design process, the software specification is turned into a design for a program.
  • The problem is broken down into main steps. This is called top down design.
  • The problem is broken into steps, which in turn can be broken into smaller steps. This is called step-wise refinement.
  • A diagram can be used to represent each of the main steps, and the steps within each main step. This is called a structure diagram.
  • Structure diagrams show the modular nature of a design as each box could be implemented as a subprogram
  • A design will also include a data dictionary, which is a list of all the variables and data structures that the program will share between modules.
  • A data flow diagram can be used to describe the relationship between different areas of the design. It can show where data is input and output, and how it is used by each area of the program.


  • In the implementation process, the code for the program is written.
  • The language used to write the code is determined by the type of program - it may be a domain-specific language (such as HTML or SQL) or a general purpose language (such as Python or Java)
  • The platform (operating system and hardware) for a program also determines how it is implemented.
  • When creating code, programmers must make their code readable. This means using meaningful variable names, indentation, and internal documentation (known as comments)
  • In a project shared between programmers, a house style may be adopted. This means variable names and subprograms should share a similar approach in terms of variable names and use of comments. This makes is easy for programmers to use each others’ code.


  • Testing is used to check for errors in the code. Testing is very important to make sure that code is robust (doesn’t crash when given the wrong input) and reliable (consistently works in the same manner)
  • Testing demonstrates that a program works, but only according to the tests you carry out. If an area of code is untested, then it cannot be shown to work.
  • There are three categories of test data:
    • Normal test data, which is data that they program should accept
    • Extreme data, which is data at the boundaries of what the program should accept, e.g. 1 and 100 for a percentage
    • Exceptional data, which is data that should not be accepted, e.g. the wrong type of data or the wrong length of string
  • Testing should be systematic - this means it follows a test plan
  • Testing carried out within the organisation is called alpha testing
  • Testing carried out with a test group that is independent from the organisation, in an environment similar to a real user’s environment is called beta testing
  • Beta testing is necessary to find environmental factors that could affect the program, as well as eliminating the biased views of the programmers, who may not spot their own mistakes


  • Documentation is the process of producing guides to the software
  • A user guide is a document that provides help for all the user-accessible features, such as menu options. This can be online (built into a menu in the program) or on paper.
  • A technical guide is a document that provides help for technical aspects of the software, such as installation instructions, system requirements and information on extendable aspects of the program


  • Evaluation is carried out to determine if the software is fit for purpose - it does what it was designed to do, as described in the analysis stage
  • Software is judged by a number of criteria:
    • Robustness - software should be able to cope with the wrong input without crashing, and handle unexpected events
    • Reliable - produces the expected results each time it runs, and does not stop working due to design faults
    • Maintainable - a program that is modular and readable can be easily maintained.
    • Efficient - a program should only use the RAM, backing storage and network bandwidth that it needs. Code should be written as efficiently as possible so that complex actions are not taking up CPU time unnecessarily.
    • The user interface - the program’s interface should be appropriate for the audience (age, level of skill etc), and customisable to allow the user to adjust to their liking. Interfaces should also be accessible, which means they support the use of text readers for the blind and high contrast display for the partially sighted. User interfaces should provide suitable error messages to make sure users understand what is going on.


  • Programs must be maintained after they are created. The Operating Systems used with the program might be updated, or the hardware platform could change, or the users could discover bugs or request new features.
  • Corrective maintenance involves fixing bugs in the code to make sure that the program works well.
  • Adaptive maintenance is maintenance carried out to ensure that a program works with new technologies and hardware, e.g. bigger tablet screen or newer OS.
  • Perfective maintenance is the maintenance carried out to add new features to software that were not in the original specification. This will usually cost the client money because it wasn’t agreed beforehand.

Resources for further reading

Teaching resources