Formal Methods
The project is to be designed using formal methods . Under this the Project Manager must undertake the following steps :-
Put together a requirement specification for the whole project . A requirement specification is a fairly general specification that is designed to outline how the whole project basically goes together and what it's basic functionality is - what is required of the project . Design the project architecture . This shows the relationships between the various modules and components within the project . Allocate the modules to the individual engineers . The individual engineers will :- Put together a set of specifications for the components - inputs , operations and outputs . Specify the linkage of the components to the module . Specify the Application Program Interfaces . The main ( module ) API must be specified by the Project Manager . Design and develop the individual components . Put together a development report for the project . Put together a set of test specifications for the modules . Arrange for the test engineers , or the individual programmers , to put together a set of test harnesses . Ensure that the modules are tested and the results are recorded . During the development - handle any issues brought up by the engineers .
A very good method of running project development is to use Headline Points - Event Points . This allows the project to be broken down into the basic individual requirements on a point by point basis . The project should then be drilled down from this point .
Architecture , componentisation and coding standards ( for software development ) are all very important . They impact on general project design issues and on code maintainability and upgrade ability . It is very important that the project is designed in such a manner that the maintenance ( updates , reconfiguration and bug fixes ) costs are minimised and that the life of  the software is maximised . The project should be designed in such a manner that whenever changes are carried out only minimal changes are necessary and the changes propagate through the project thus updating anything associated . This means that relationships must be set up - such as using enumeration's , macros and typedef's . Also table drive as much as possible . IE. don't forget the Theory of Knowledge - maximise the Locus of Validity . Don't hard code . Use single definitions . Use as much commonality as possible . Keep things simple but not simplistic . Simple is optimal . Simplistic can , in fact , end up making things much more complex .
Communication is very important . It is important to maintain full and effective communication with all the staff . Have regular - daily - brief meetings and get a short - 2 minute max. - report from each staff member on what was achieved the previous day and on what the aims are for the current day . This helps keep everything on course . Don't forget - it's your responsibility to ensure that the project directions and the corresponding aims are clearly understood and achieved . The staff have to know where you want to go and you have to make sure that they are achieving those aims . If they are not you have to find out why and then provide them with the facilities such that they can achieve the aims . It is important to be constructive and to assume that the staff want to achieve the aims .
Documentation is very important . The documentation must be clear and complete . Do not write in context . Spell everything out clearly . It is vitally important that the documents can be read easily and quickly . Documents should have the document name and number ( within the document data base ) at the top left hand position . The page number should be placed at the top right hand position . Page no. of no. of pages should be placed at the bottom middle . If the document has a single author the author's name should be placed at the bottom left . Alternatively the document number can be placed at the bottom left .
It is very important to maintain a bi-directional documentation chain - setting of specifications and documenting that the specifications have been met and how they have been met . A very useful technique is to issue a set of requirement specifications to the development engineers , let them develop the components specifications in conjunction with the project manager and use the tester to continuously evaluate the project as the project is being developed .
Code wise - the code should be heavily commented . The comments should be the bottom end of the drill down process . It is a good idea to put details of the project design within the code as the code can often become seperated from any associated documents .