ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/projects/cms/documentation/plan/implementation-phases.txt
Revision: 1.1
Committed: Wed Oct 25 18:22:27 2000 UTC (23 years, 5 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.

File Contents

# 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.