Structured Approach

Previous | Index | Next

The structured design approach helps developers deal with the size and complexity of large scale projects. The structured approach is a process oriented approach, aiming to break a large complex project into a series of smaller, more manageable modules. 

The Structured approach is usually associated with projects that have the following characteristics :

  • long time periods : The time involved in a structured approach is generally measured in months, or even years.

  • large-scale projects : The structured approach is usually applied to large projects which involve a huge amount of detail and coordination between various parts of the business and other systems.

  • large budgets : Large projects will involve a large number of people and will employ them over a long time scale. The budget, consequently,  will be large. New hardware and software is often required for completion of the project, elevating the cost of the project - though the amount spent upon personnel is usually the highest cost factor.

This approach, however, may be implemented as part of each of the other design approaches studied in this course. For example, an end user creating their own solution to a problem, may follow ( in a simplified form) the steps of the structured approach. Similarly, the Rapid Application Development paradigm is an iterative approach (meaning the product may undergo many "incarnations" before a final product is developed). Each of the iterations may follow a simplified structured design approach.

The steps of the Structured approach are as follows :

  • Defining the problem. In this stage, the requirements for the software are gathered and analyzed, to produce a complete and unambiguous specification of what the software is required to do. The problem will need careful analysis so that the "true" issues involved are identified. For example, if your car won't start, your "problem" is "My car is not working". However, this is merely an analysis of the "symptoms". Deeper analysis may reveal that there is no petrol in the car, or the battery is flat or some other problem. Until the true cause of the problem is discovered, a useable solution can not be developed. This stage is sometimes called Requirements Analysis.

  • Planning. During this phase, a software architecture for the implementation of the requirements is designed and specified, identifying the components within the software and the relationships between the components. Inputs, Outputs and Processes required for  the new system are identified and a basic plan in the form of flowcharts or pseudocode are developed. A "Top Down" approach would almost certainly be used. This involves breaking a larger and complex problem into smaller more manageable modules - each module being coded separately. Thus, a structure chart is an important document developed during this phase. This stage is sometimes called Architectural and Detailed design.

  • Building. This is the Code and Test phase, in which each component of the software is coded and tested to verify that it faithfully implements the detailed design outlined in the previous phase. Finally, once all of the modules have been coded and tested the software is integrated. Progressively larger groups of tested software components are integrated and tested until the software works as a whole. This process is sometimes called Software Integration.

  • Checking the solution. This involves Acceptance Testing, where tests are applied and witnessed to validate that the software faithfully implements the specified requirements. Real data may be used and this is compared to outputs from a previous system. The system may also be tested under full load. A program may work well for a small data set, but have problems when thousands or millions of records and transactions are required of it. Beta testing may be used during application software development.  Users are also involved in this process to ensure that their expectations of the system are fulfilled. In addition to the feedback that the development team receives, users also benefit by being able to use the system. In addition to checking that the program can process the data correctly, the user interface is evaluated for ease of use and intuitive design. 

  • Modifying the solution.  During the testing phase, problems or possible improvements (from beta testing) may be found. If problems are found, modifications may be made to solve the problems and another round of testing will occur.

The structured Approach  to the software development lifecycle begins with the identification of a requirement for software and ends with the formal verification of the developed software against that requirement. Traditionally, the models used for the software development lifecycle have been sequential, with the development progressing through a number of well defined phases as shown in the diagram below:

This is sometimes called a Waterfall Model. The steps are sequential, starting at the top with a problem to solve and continuing to the bottom with a final solution. This style of development contrasts with other circular or Iterative styles of software development in which the finished product is developed over the course of a number of revolutions (iterations) and the specification of the problem may change and evolve over the course of the development process.

Advantages and Disadvantages of the structured Approach

Advantages

  • Problem is addressed in a detailed and systematic way. Therefore, unexpected problems encountered during the development phase should be avoided by careful planning.

  • Solution is robust and will fulfil the requirements described in the initial stage. Careful planning will result in a system that fulfils the requirements of the system, as described in the initial phases.

  • Solution is well documented and supported by a team of programmers. The solution is not "ad-hoc", but is the result of a careful, well documented work by a team of professionals. Therefore, should further development be needed in the future, those who follow should have the benefit of a clear understanding of what went before them.

Disadvantages

  • The timescale for development is very long - in some cases so long that the initial requirements may have changed before the development is completed, rendering the newly developed system obsolete.

  • The system may be expensive in terms of money and man-hours. It can be monolithic, unwieldy and unable to cater for fast paced changes to business requirements.

In the following pages we will examine the prototyping approach to software development.

Assessment Task

You are to use the structured approach to create an Address book in QBASIC. The assignment details are here.

Students should be aware of the advantages and disadvantages of each of the different software development approaches introduced in the Preliminary course.