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 (25 years 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.
#	Content
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.