This is the section where the method used to solve the problem specified in the Objectives of the Selection, Analysis and Formulation of the Problem Section is selected and designed. Remember to refer to the Objectives regularly in order to ensure that your design meets the user's requirements.

This section is again divided into a number of sub-sections.

You need to be clear in your own mind as to how you intend to design the solution. Remember to use the Top Down Design method using self-contained modules. The method used should be described showing the links between the modules, and also there should be clear description have the data flow in your system, possible using the Data Flow Diagram or similar.

If you are solving a multimedia/ www site problem, the content of the pages should be given, and the links between them using the storyboard technique.

Remember it is based on the Objectives.

• A block diagram showing the relationship between the modules;
• A brief description of the task performed by each module;
• Description of data flow (diagram?).

This section explains possible methods of solving the problem. Include both software and hardware designs, but concentrate on the software side. Specify the type of package or programming language, but do not specify the actual package or programming language used. Similarly with the hardware.

At this stage your project should be independent of any particular programming language or package, and also of any specific hardware device, if possible.

• If the system exists, how can the current method of performing the tasks be improved, else, how could the tasks be done;
• What are the advantages and disadvantages of these methods;
• Select the method that you are going to use, and explain why.

This section describes how the data is organised and stored. Alternatives could be considered, and choices justified. Details of how the data is stored internally and externally needs to be described.

• Internal data structures. Alternatives considered and choices justified.
• External data structures. Where appropriate, alternatives considered and choices justified.
• Validation techniques should be described and justified.
• If a database is used ER diagrams and data structure tables in normal form should be included.

Here how the pages are organised within the site needs to explained. Again alternatives need to be considered and selections justified.

• Evaluation and selection of site structure.
• Diagram showing this structure
• Any validation techniques used, or justification of non-use.

This section deals with the Human Computer Interface (HCI) i.e. how the user and the computer system communicate with each other. It may be useful in some projects to split this section to Input Requirements and Output Requirements at some stage. Initially the type of User Interface (UI) needs to be considered and selection justified, before moving on to consider details.

The I/O designs should be discussed in terms of user friendliness, suitability, consistency and robustness. Think about the target users, decide on basic standards, such as colour, fonts, controls, consistent format, jumping to various sections of the program etc. These designs need to be included.

In addition to the screen designs, are than any paper based forms which need to be designed e.g. Data Capture Forms (DCFs), Hardcopy Output?

What inputs are required by the system? What outputs need to be displayed? These may have to be justified.

• Evaluation of possible type of UIs and justification of UI selected.
• Prototypes or drawings of Input Screens, with justification of format and inputs required.
• Prototypes or drawings of Output Screens, with justification of format and outputs required.
• Drawings or Prototypes of any DCFs, with justification of format and content.
• Drawings or Prototypes of any Hardcopy, with justification of format and content.

In this style of project, pages may have a similar format and content. To avoid unnecessary repetition, where pages are very similar, include one example and provide a list of the other similar pages, and indicate where they differ.

This can be a time consuming task, but it is worth while to do it properly for a number of reasons.

• You are displaying a number of skills which will give you credit.
• You are bringing a number of sub-sections together in order to produce the whole.
• It shows the systematic way you are following in order to design the solution.
• It will make the task of implementation far easier.

In the Overall Plan you described how you are using the Top-Down Design Method, with modules performing self-contained tasks. We now have to describe how the modules perform these processes, using algorithms written in pseudocode.

Follow the Top-Down Method, and take each module in turn. Before writing the algorithm, ensure that the module has a meaningful identifier, and give a brief description of the task carried out by the module.

Also it may be useful to provide a Data Table of any data items used by the module. Remember use meaningful identifiers, and refer to the Data Structure Designs when necessary. In this table indicate what data types they are, whether they are local or global, and whether they are value or reference parameters. The Data Table could be included before or after the actual algorithm.

Write the actual algorithm in pseudocode, not in any particular programming language. At this stage, remember, it should be independent of any particular programming language or package.

Do not be afraid to use the Step-Wise Refinement method, and include the various refinements.

Keep your modules short and simple. Avoid complex algorithms and clever tricks no one else will understand. Annotate the algorithms where necessary, especially when a complex task or control structure is being used. Read through each module, and dry run the module to check for any logical errors.

• Meaningful module identifier;
• Brief description of the task carried out;
• Data Table
• A clear annotated Algorithm, including the various refinements where appropriate. (The various refinements could be placed in an Appendix in order to make the documentation clearer, and only the final algorithm included here.)

As you possible do not use algorithms and modules in the same way as described above, the following should be included in your project.

In this case your modular design is based on your pages.

Each page should have a meaningful identifier, and a brief description of the purpose of the page given.

Identify the resources required for each page. Resources for each page may differ, but sometimes they may be more or less the same. To avoid unnecessary repetition, where pages require very similar resources, include one example and provide a list of the other similar pages, and indicate where they differ.

Resources can include text boxes, pictures and graphics, sounds, animation and video. It also include links to other pages, input boxes, search engines and so on. The content of the input box, or the button pressed, may determine the next link! This should be shown in this section.

A diagrammatic representation may be more useful than a written one.

• Meaningful page identifier.
• Brief description of the purpose of the page.
• Resources used on the page.
• Links to other pages, and how determined.

As nothing has actually been created as yet, at this stage you can only describe how you intend to test your solution. The actual testing takes place later.

You should specify that, each module will be tested individually, using appropriate test data, to ensure that it works. Then it is added to the other modules in the program, and this is then tested to ensure that the solution works so far. If the testing is successful, then move on to create and test the next module, otherwise find and correct the error.

When the final module has been individually tested and added to the whole, and this has been tested, then we can say that the testing is complete.

• Logical errors, which can be tested by Dry Running or Running the program using suitable Test Data.
• Syntax and semantic errors which can be done during Compilation.
• Run-time errors. Running modules and program with test data, to check that all possible paths through the program have been tested, and the program does not crash or be caught in a perpetual loop.

Test Data should be carefully thought out and selected, in order to test the modules and program thoroughly. Test data should include:

• Normal Data
• Extreme Values
• Illegal (or Invalid) Data

This section requires the following:

• Outline your overall strategy for testing;
• Type of testing to be undertaken;
• Method used to select Test Data.

Testing for these types of projects may differ to the above project. However, there may be some similarities.

• Each page should be tested in turn before moving on to the next page.
• Any input should be tested and suitable Test Data selected.
• Links from one page to other pages should be tested to ensure that we actually go to the expected page. (This could be shown in diagrammatic form.)

Nôl