documentation/plan/implementation-phases.txt

IMPLEMENTATION PHASES
=====================

tdb1, 17/10/00

Phase 1
-------

Host
  The host program will probably be written in basic Java,
  and simply take the output from running unix commands.
  This will either be parsed by the program, or more
  preferably by an external perl/awk/grep/sed program. The
  thinking behind this is that porting to C/C++ will be much
  faster if the external parts are already written. This
  will also allow for the whole basic Phase 1 to be 
  completed easily.

  If reading the data is becoming problematic it can be
  moved to Phase 2 and "simulation data" (ie. fake) used
  instead.

  It should only be implemented for the main platform, ie.
  Solaris/SPARC.

Server
  At this Phase the server will only echo output to the
  screen, and basic checking can be done to verify whether
  e-mail alerts should be sent (probably via sendmail
  directly).

Client
  No functionality at this stage.

Overall
  The aim of this Phase is to implement the basic protocol
  for communication between the hosts and server, and give
  us a basis for explansion.


Phase 2
-------

Host
  The implementation in Phase 1 should be ported into C/C++
  and all data should reflect the actual system  (no
  simulation). It is not necessary to make systems calls at
  this stage, the external scripts from Phase 1 can still be 
  used.

Server
  Database connectivity should be implement, even if it's 
  just a case of storing rows of data. This will require an 
  element of modularity to be introduced.

Client
  A basic web interface should be produced for debugging. 
  All that is required is to be able to view the data in the 
  database to check all is going to plan.

Overall
  The aim here is to get the host code into it's intended
  language, and bring the database into the system.


Phase 3
-------

Host
  The code should be becoming more modular, with clear
  sections for the network communications, and the system 
  interfacing. It should now be possible for the program to 
  implement some system monitoring without the aid of 
  external scripts, although if any are proving tricky they
  can be left for now. The key point is forming a "better" 
  program.

Server
  The server should now be taking a very modular design, and
  the system should be gaining more internal functionality. 
  Better checking of events should be deployed, and the 
  interfaces between components be more clearly defined. 
  This will allow for the client interaction in Phase 4 to 
  be more easily implemented.

Client
  If time permits, it could be possible to produce some more
  web pages to allow better viewing of information, although 
  this is the least important part at this stage.

Overall
  The system should be taking good shape by now, and still
  be in an almost working state. Delivery could almost be 
  possible. The main point is that the classes are being 
  clearly defined with a good OO approach in mind.


Phase 4
-------

Host
  The host code should be completely standalone at this
  stage, and capable of running without any outside scripts. 
  It should also be tidied to the point of being finished, 
  and all the proper error handling be implemented. It can 
  be considered complete for the current platform.

Server
  The client interface can now be developed to allow a
  client to connect and view data. This should just be raw 
  data, none of the "thinking" (ie. filtering of data for 
  clients) need be done.

  The collector should also be expanded to allow more 
  "thinking" to occur behind the scences. Key to this stage 
  is the implementation of a filter, to hopefully stop 
  floods of events going through.

Client
  A basic client (in Java?) should be implemented that will
  connect to the server and just read information. It need 
  not allow much user interaction, and need to act upon 
  events. The key point is the communication between the 
  client and the server.

Overall
  The plan here is to polish off the "host side" of the
  server and get the client side moving along.


Phase 5
-------

Host
  With a completed initial host application for
  Solaris/SPARC (?) porting should take place. Initially NT 
  should be done, but it could be possible for another 
  person to quickly port to the Solaris/Intel and Linux 
  platforms due to the similar code. The NT host application 
  could almost take a rewrite, but all the basic channels of 
  communication should remain the same. C/C++ should be used 
  throughout.

Server
  The client interface should be made more advanced with
  much more "thinking" stuff going on behind the scences. 
  Preferences may be received from the client to tailor data 
  sent, depending upon the design.

  If required, although we expect it won't be, the web
  interface should be written. However, we expect the 
  webpages will connect directly to the database. Any "live 
  applets" should be able to connect via the client 
  interface.

  The server should be effectively complete now, at this
  stage of the development process.

Client
  Client should be fully fledged, allowing configurabilty
  and use a full GUI. Graphical representation of the data
  is desired. This should be considered complete.

  The web interfaces should be finished off aswell,
  providing whatever features that have been planned.

Overall
  Basically bringing everything together. The whole system
  should be completed at this point. This last phase will 
  probably take quite a while to fully complete (porting 
  and GUI writing).


PUBLIC RELEASE 1
================

The system is now ready for the initial release. Although
testing at each phase should have been done, it is now time 
to rigoursly test the whole system... preferably before 
release.

Further features could be added, time pending of course, but
we have the core of the whole system done.

COMMENTS
========

This is not final, and should be reviewed with regard to the
features list to be produced. It is important that at the
end of each phase the following are completed.

- Documentation of code, and thoughts behind implementation.
- Review of code, possibly by others.
- Testing of code.
- Meeting to review progress, and prepare for next phase.

At all times code should be kept in CVS. Tagging will be
done at the completion of each phase. It is therefore 
important that all work be concluded before the next phase 
commences.

CVS trees should be decided upon at an early stage.
Revision:	1.1
Committed:	Wed Oct 25 18:22:27 2000 UTC (23 years, 6 months ago) by tdb
Content type:	text/plain
Branch:	MAIN
CVS Tags:	PROJECT_COMPLETION, HEAD
Log Message:	Plan of the first (and basic) release of our system. It divides the implementation into 5 manageable phases.
#	User	Rev	Content
1	tdb	1.1	IMPLEMENTATION PHASES
2			=====================
3
4			tdb1, 17/10/00
5
6			Phase 1
7			-------
8
9			Host
10			The host program will probably be written in basic Java,
11			and simply take the output from running unix commands.
12			This will either be parsed by the program, or more
13			preferably by an external perl/awk/grep/sed program. The
14			thinking behind this is that porting to C/C++ will be much
15			faster if the external parts are already written. This
16			will also allow for the whole basic Phase 1 to be
17			completed easily.
18
19			If reading the data is becoming problematic it can be
20			moved to Phase 2 and "simulation data" (ie. fake) used
21			instead.
22
23			It should only be implemented for the main platform, ie.
24			Solaris/SPARC.
25
26			Server
27			At this Phase the server will only echo output to the
28			screen, and basic checking can be done to verify whether
29			e-mail alerts should be sent (probably via sendmail
30			directly).
31
32			Client
33			No functionality at this stage.
34
35			Overall
36			The aim of this Phase is to implement the basic protocol
37			for communication between the hosts and server, and give
38			us a basis for explansion.
39
40
41			Phase 2
42			-------
43
44			Host
45			The implementation in Phase 1 should be ported into C/C++
46			and all data should reflect the actual system (no
47			simulation). It is not necessary to make systems calls at
48			this stage, the external scripts from Phase 1 can still be
49			used.
50
51			Server
52			Database connectivity should be implement, even if it's
53			just a case of storing rows of data. This will require an
54			element of modularity to be introduced.
55
56			Client
57			A basic web interface should be produced for debugging.
58			All that is required is to be able to view the data in the
59			database to check all is going to plan.
60
61			Overall
62			The aim here is to get the host code into it's intended
63			language, and bring the database into the system.
64
65
66			Phase 3
67			-------
68
69			Host
70			The code should be becoming more modular, with clear
71			sections for the network communications, and the system
72			interfacing. It should now be possible for the program to
73			implement some system monitoring without the aid of
74			external scripts, although if any are proving tricky they
75			can be left for now. The key point is forming a "better"
76			program.
77
78			Server
79			The server should now be taking a very modular design, and
80			the system should be gaining more internal functionality.
81			Better checking of events should be deployed, and the
82			interfaces between components be more clearly defined.
83			This will allow for the client interaction in Phase 4 to
84			be more easily implemented.
85
86			Client
87			If time permits, it could be possible to produce some more
88			web pages to allow better viewing of information, although
89			this is the least important part at this stage.
90
91			Overall
92			The system should be taking good shape by now, and still
93			be in an almost working state. Delivery could almost be
94			possible. The main point is that the classes are being
95			clearly defined with a good OO approach in mind.
96
97
98			Phase 4
99			-------
100
101			Host
102			The host code should be completely standalone at this
103			stage, and capable of running without any outside scripts.
104			It should also be tidied to the point of being finished,
105			and all the proper error handling be implemented. It can
106			be considered complete for the current platform.
107
108			Server
109			The client interface can now be developed to allow a
110			client to connect and view data. This should just be raw
111			data, none of the "thinking" (ie. filtering of data for
112			clients) need be done.
113
114			The collector should also be expanded to allow more
115			"thinking" to occur behind the scences. Key to this stage
116			is the implementation of a filter, to hopefully stop
117			floods of events going through.
118
119			Client
120			A basic client (in Java?) should be implemented that will
121			connect to the server and just read information. It need
122			not allow much user interaction, and need to act upon
123			events. The key point is the communication between the
124			client and the server.
125
126			Overall
127			The plan here is to polish off the "host side" of the
128			server and get the client side moving along.
129
130
131			Phase 5
132			-------
133
134			Host
135			With a completed initial host application for
136			Solaris/SPARC (?) porting should take place. Initially NT
137			should be done, but it could be possible for another
138			person to quickly port to the Solaris/Intel and Linux
139			platforms due to the similar code. The NT host application
140			could almost take a rewrite, but all the basic channels of
141			communication should remain the same. C/C++ should be used
142			throughout.
143
144			Server
145			The client interface should be made more advanced with
146			much more "thinking" stuff going on behind the scences.
147			Preferences may be received from the client to tailor data
148			sent, depending upon the design.
149
150			If required, although we expect it won't be, the web
151			interface should be written. However, we expect the
152			webpages will connect directly to the database. Any "live
153			applets" should be able to connect via the client
154			interface.
155
156			The server should be effectively complete now, at this
157			stage of the development process.
158
159			Client
160			Client should be fully fledged, allowing configurabilty
161			and use a full GUI. Graphical representation of the data
162			is desired. This should be considered complete.
163
164			The web interfaces should be finished off aswell,
165			providing whatever features that have been planned.
166
167			Overall
168			Basically bringing everything together. The whole system
169			should be completed at this point. This last phase will
170			probably take quite a while to fully complete (porting
171			and GUI writing).
172
173
174			PUBLIC RELEASE 1
175			================
176
177			The system is now ready for the initial release. Although
178			testing at each phase should have been done, it is now time
179			to rigoursly test the whole system... preferably before
180			release.
181
182			Further features could be added, time pending of course, but
183			we have the core of the whole system done.
184
185			COMMENTS
186			========
187
188			This is not final, and should be reviewed with regard to the
189			features list to be produced. It is important that at the
190			end of each phase the following are completed.
191
192			- Documentation of code, and thoughts behind implementation.
193			- Review of code, possibly by others.
194			- Testing of code.
195			- Meeting to review progress, and prepare for next phase.
196
197			At all times code should be kept in CVS. Tagging will be
198			done at the completion of each phase. It is therefore
199			important that all work be concluded before the next phase
200			commences.
201
202			CVS trees should be decided upon at an early stage.