Software Project Management Plan : Network Subsystem

3.2.1 Assumptions

• Database will handle all caching of information.
• All information, requests, events, and other messages will all be handled the same by the network (i.e. We will treat everything as a bit string and it will be the responsibility of the receiving party to "listen" for the message.).
• Rebuilt messages will stay in the message queue at the receiving end until all subsystems have notified us that they have finished with it.
• Events that the network subsystem will publish include, but are not exclusive to, MessageHasArrived, NetworkIsDown, and UnspecifiedFailure.
• Database or Authentication will handle encryption of all sensitive data before sending or give an API to allow us to do so after compression of the message. If the latter is followed, the clear text message must be marked with a flag as sensitive material if encryption is necessary.
• Routing for Network involves only specifying the destination server for the packets and developing a scheme to choose another to improve performance. This does not involve routing the individual packets at the intermediate routers.
• The dealer to server ratio will be about 150:1 with the dealer making about 5-7 requests for information per network session.

3.2.2 Dependencies

Network:

• We depend on event/learning, authentication, and the database subsystems to communicate their assumptions or needs relevant to us freely and in a time efficient manner.
• Furthermore, we depend on the architecture team to point out/clarify any discrepancies existent in the assumptions made in our RAD with assumptions made in the RADs' of other subsystems.
• We depend on the correctness and stability of existing software that we will be using (i.e. - Voyager, Marimba, TogetherJ, etc.)
• We depend on the client to make timely responses and clarifications to items that we post to the client bboard.

3.2.3 Constraints

• System will be developed in Java (ver 1.1).
• Object and CASE models will be developed in TogetherJ
• Source control will be handled using CVS
• Voyager will be used to handle RMIs.

3.3 Risk Management

• Risk: For some reason the network becomes unreliable or goes down during the transmission of data.
• Contingency: We will cancel the request and notify both ends of the transmission that the network has gone down and the request has been canceled.

• Risk: Our system may not be scalable.
• Contingency: We are operating under the assumption that the dealer to server ratio will be about 150:1. If this changes dramatically, our system needs to be adaptable to handle other ratios.

• Risk: The client fails to clarify issues completely or in time for us to be able to make the appropriate changes.
• Contingency: We can re-post to the client bboard. If that does not elicit further response, we should talk to the coaches and make a best guess as to what functionality is needed and expected.