5. System Outline

The system is to be built in several stages, as defined by the software engineering discipline:

5.1 Requirement Analysis

At this Stage the requested result is to be discovered and analyzed. It is important that it is assured that this project will evolve into a non-trivial entity - one which will make this project 'one of a kind' and, therefore, more interesting to analyze and discuss.

5.2 Specification

This phase will produce some clear description of what is to be achieved without having us concerned about how to implement everything.

5.3 System Design

We are now looking at how the system will be implemented. This can be logically divided into two different stages:

High-level Design

Also Functional design. We need to agree on which modules the system will comprise of and what each one of them is responsible for. Diagrams could, indeed, be useful here as we are interested in some structural representation, which will ease our process of understanding the system.

Low-level Design

We would need to incorporate the above and develop some pseudo-code incrementally. This will be a very time consuming stage where programming skills are essential. Also, efficiency issues should be addressed here, otherwise they will have to wait to a much later stage where the effort spent will be greater.

5.4 Implementation

Using the output of the above stage (diagrams, paper or text) we need to code what was agreed on previously. If C is used, a Makefile needs to be created to link all the different parts of the overall system and the pseudo code needs to be translated into (lower-level) imperative code.

5.5 Testing

Stability

Is our program robust enough to allow all games to played safely without crashing? If exceptions occur, does the system catch them? Does it handle them appropriately? All of these factors should be taken into consideration if we wish to extend the system comfortably and see if it is going through unexpected and undesirable paths.

Performance

Let us check if the system is operating quickly enough. Should we probably impose some constraints on the time that the CPU can spend computing a move? Should we modify the graphical engine to allow more frames to be generated in a given time?

Strength

It is highly advisable that Othello Master is then put against as many other othello playing applications as possible. Testing it against other playing engines will give us an indication of how well it plays against other engines with (possibly) different approaches. Allowing experienced human players to play against Othello Master may also prove to be useful since more constructive analysis and feedback can be obtained. The drawback of this idea is the fact that this can be slow and tedious.

5.6 Documentation

User Manual

The user needs to have a help feature within the program, but is that enough? Perhaps the user may wish to use some non-trivial options too. We can provide some command-line options specification, as well as a user's manual, which will explain how to use the system in more detail.

Programmer's Manual and documentation

1. It needs to be assured that the code is well documented, preferably with comments where appropriate.
2. A functional and modular summary is necessary to give a system overview. This can also prove to be useful if we want to re-use the code, let us say, for some new chess application. Finding the functions is more trivial in this way.
3. A diagram of the system structure would be highly appreciated.
4. A report of how the system works as a whole, how to compile it, platform dependent code and debugging tools are a necessity. It is a very common phenomenon for a programmer to find himself/herself lost with a piece of code that is unreadable, unusable or lacks the compilation facilities.

5.7 Simulation

This is a phase that is applicable in our project, but not necessarily in other software engineering development processes. We now can utilise batch facilities to have the program play itself. Most impotantly, if we have written different game-playing algorithms (corresponding to different approaches) we can now gather some game statistics which will indicate which approach is stronger than another or which seems to have special weaknesses against specific other approaches.

We may have to derive more complex analysis that will produce graphs and tables. These will be highly recommended for the later project report.

5.8 Maintenance and Extension

When the system as it was initially intended to look like is finished (specified within the main objectives) , we might want to extend it, improve it and add more features. This stage is a never-ending process which would be classified as 'just a possibility' at this point. The tasks listed as secondary objectives should be taken into consideration here.

Shall any other ideas come up during development, given that it is of some importance of use, we may add them to the list of the secondary tasks too. It is quite likely that some of these features that are identified later are even more useful than the ones currently suggested.