CDP5042

Software Technologies and Techniques Individual Report Project: Morabaraba

http://code.google.com/p/morabaraba/

Author:

Bruce McLachlan 10 April 2007

1. Introduction
The purpose of his document is to describe my individual contribution made in the group assignment for developing a Moarabaraba software application. This introduction will summarize the phases of the project and briefly overview my role during each of those phases. During the Role assignment phase I was nominated to be the lead designer for the project. This was mainly due to my interest in the design and architecture of the proposed system. I had also expressed a thorough understanding of the problem domain during these initial stages. The Requirements analysis phase was mostly handled by the two analysts, Pieter Holmes and Kingsley Webb. There were some group meetings where the requirements were discussed and I was consulted at. In order to investigate some proposed technologies, a Research phase was initiated, during which I was tasked to evaluate IDEs (Integrated Development Environment) for design. I was also tasked to evaluate different means of connectivity that could potentially be used by the application. Scope definition phase was done in the form of group meetings. There the required functionality to be delivered was discussed. After scoping was completed I commenced with the Initial design phase, where I produced an initial design for the proposed system. Once the initial design was in place, a Resource allocation phase commenced where the development resources where allocated to the various components of the system. When our group merged with another group, I was involved in providing the new resources with an overview of the design, and also re-allocating these resources to specific development tasks. Development continued for a short while, when most of the resources decided to withdraw from the project. This only left me and Chris Lebuso to complete the proposed system. An official Development phase was started, and the development of the revised scope was commenced. During the Integration phase Chris Lebuso and myself integrated the various components that we had developed. All documentation provided for this project was completed by Chris Lebuso an myself. The sections outlined above will now be discussed in further detail.

2. Role Assignment Phase

Role assignment was on of the issues that where discussed and resolved during the initial meetings of the groups. Roles were allocated based on the individual interest in a given area of software development and group consensus. I had expressed interest in the design and architecture domain from the conception of the project and was therefore nominated as lead designer for the project.

3. Requirements Analysis Phase

Pieter Holmes and Kinsley Webb were elected as analysts for the project. The requirements were discussed during team meetings and it was decided to adopt the Course Project: 2007 [1] as the requirements specification for the system.

4. Research Phase
At this stage we had an understanding of the requirements and a Research Phase was initiated to investigate possible technologies that could be used in the implementation for the system. I was tasked with researching a design IDE and possible networking technologies. The design tools that I considered during my research were: Rational XDE and Enterprise Architect (EA). One key feature the design tool had to provide was PIM (Platform Independent Modeling). Rational XDE provided all the required features of a good design tool but because of costly licensing fees, was disregarded as an option. EA provided the same features as Rational XDE and had a significantly smaller license fee. This, combined with the fact that all the developers already had access to EA at work, made EA the most appropriate design tool for this project. Networking Technologies that I investigated included: Bluetooth, IR (Infra-red), RMI, Sockets and HTTP. If a mobile application was to be developed the most appropriate networking option would have been Bluetooth because support by most mobile phones and other devices. Bluetooth was chosen over IR because of its longer range and ease of implementation. I could not find enough information on IR implementation, so that also contributed to IR being disregarded as and option. Also from my research I found that RMI or Sockets are tedious to implement on a mobile platform. HTTP was disregarded as a solution because of its request/response architecture. This would have been inappropriate for the proposed system. For a Java SE application Sockets was the most appropriate option, as it is easy to implement and could support multiple client-server configurations (as opposed to RMI that requires a remote RMI server to be available). Sockets are also light-weight and suited the requirements for the project. During the research phase Danie Rothman was tasked was tasked to research development methodologies, and the outcome from his research was that a Spiral approach would be most suited for this project. I was consulted in my capacity as

lead designer on this issue, and the final choice of methodology was made by both me and Danie Rothman. Available source code (that could potentially be reused by our application) was investigated by all group members. I came across a game framework that had potential to be reused and it was considered as a base to start our development from. This framework however proved insufficient at later stages, and was disregarded as a solution.

5. Scope Definition Phase

Scope definition phase was done in a group meeting forum where the requirements and research from previous phases were taken into account to propose the scope for the system. Following the Spiral methodology, the project was structured to be developed in three phases that would involve two prototyping phases and a final release phase. My involvement here was to define the contents of each phase, and the outcome of that was as follows: The first prototype would include a command line interface to the game, a game engine, a hard-coded rule engine and a client/server implementation. The second prototype would include XML encoded rules and enhancements to the game engine (to make it more configurable). The final release would include a Graphical User Interface.

6. Initial Design Phase

The initial design phase was solely my responsibility, and my aim during this phase was to define an API (Application Programming Interface) for the major components of the system. This would allow development of individual components to happen in isolation, independent of other components. The components I identified and designed an API for were the game engine, the rule engine, the game board and the client/server implementation. This was completed and communicated to the rest of the group via design sessions. Detail of the design is included as Appendix C in the Group Report. The framework for the system was designed in such a way that it would be generic and that various types of games could be implemented on the framework. The framework also supports different implementations and configurations of rules, GUIs, game boards, client/server implementations and environments.

7. Resource Allocation Phase

Development resources were allocated according to the components as specified by the design. I volunteered, and was subsequently assigned, to develop the game engine and the client/server implementations.

8. Merging of Teams
Another group was forced to join out group because most of their members decided to withdraw from the project. This added another two valuable resources to our group. During this period I was presenting design sessions to provide both the existing and the new group members with an understanding of the design of the system.

9. Team Restructure
The initial development continued for a short while, when the project suffered a major setback. Most of the resources decided to withdraw from the project. This only left me and Chris Lebuso to complete the proposed system. We worked together at redefining the original scope, and it was determined that it would only be feasible to deliver the first prototype that was proposed. I was still tasked with delivering the game engine and the client/server implementation, and Chris Lebuso was assigned to deliver the rule engine.

10. Development Phase

As tasked, I developed and completed, on time, the implementation of the game engine and the client/server integration. This was done as per definition of the design and the final implementation supports my objectives as defined by the design.

11. Integration Phase

The integration of the rule engine, developed by Chris Lebuso, with the game engine and client/server implementation, developed by myself was easier that expected. The initial specification of an API that made the process of integration almost seamless. The only area where difficulties were experienced was where the implementation deviated from the API, but these issues were quickly resolved.

12. Conclusion
The components of the project hat I would consider my sole and primary contributions are all design aspects of the software architecture and the implementation of the game engine and client/server integration. I also made lesser contributions to the implementation of the rule engine (developed by Chris Lebuso) and the integration of the game board (partially developed by Danie Rothman).

13. References
[1] Course Project: 2007, http://school.eie.wits.ac.za/~nixon/swtnt/project/swtnt-proj-2007.pdf (last accessed 9 April 2007)