Develop Software Iteratively – Yes

Iterative and incremental software development process is one of the best practices preached by RUP. For every iteration, it requires us to do planning, requirements, analysis and design, implementation, testing, and evaluation. For the current semester, we've gone through three iterations and for each iteration we've developed a project plan, requirements spec, architecture document, class diagrams, test document, code, and finally performed a review on the artifacts for the undertaken iteration. The individual artifacts for each iteration are ample proof of our following an iterative approach. At the same time, for every new iteration, we've developed our system a little bit more thereby following an incremental approach as well.

Managing Requirements -- Yes

Managing requirements is absolutely vital to any project and RUP does include this as one of its best practices. At the start of every single iteration that we have performed, we've identified any changes to our requirements and updated the requirements specification. At the same time, all major functional requirements that we've captured through use-cases have also undergone two iterations. This has helped us further track any decisions that we might have taken with respect to system requirements. The requirements spec. has undergone three iterations while the use-case details have undergone two.

Component-based s/w architecture – Yes

RUP emphasizes on architecting and designing the system upfront. It encourages the architecture to be based on components so as to maximize reuse, enable better cohesion, minimize coupling, and make the architecture as resilient as possible. For our project, we've used an OO language such as Java as our implementation language. This has helped us design our system in term of objects thereby maximizing the cohesion and minimizing coupling. At the same time, we've designed our system at a very high-level in terms of three layers. The three layers form the three major components in the system providing our system with three levels of abstraction. The architecture document has undergone three iterations and it clearly describes our layer/component based architecture in further details.

Visually Model Software – Yes

For the project, we've modelled our design using Unified Modelling Notation(UML) using a number of tools ranging from Visio 2000, Agro UML, & Visual Paradigm. Modelling with UML has allowed us to comprehend our system in its entirety. It has helped us to visualize, construct, and understand the behaviour of the individual components and the interaction of the various individual classes within each component. Modelling our system using UML has further helped us communicate the design decisions and details to the various members of our distributed team spread across three time-zone within and outside the country. The class diagrams have also undergone three iterations and depict how we've modelled our system using UML. Some of the inconsistencies, dependencies and inflexibilities of the design identified through using a UML notation such as this have also been fixed in the next iteration.

Continuously Verify Software Quality – Yes

The following has allowed us to verfiy our software quality at every iteration and within iterations
1) Writing system test cases based on scenarios for each iterations
2) Performing reviews of artifacts by using passaround review technique whereby the artifacts is passed to all the team members who in turn review the artifact individually and send their feedback to the author of the document. Upon the changes made after the review, this updated artifact is again passed around the team for final verification validation.
3) Although we are a distributed group, four of our developers are in the Chicago area. They have been able to get together in person from time to time which has led to better communication, code reviews in person and has contributed immensely in helping us develop a higher quality of code.

Control Changes to Software – Yes

We've recognized the need to use a Software Configuration Management tool right from the begining of the project even when we were an XP group. We decided to host our project on sourceforge and use CVS on sourceforge for setting up our repository for all project artifacts. Currently, we are using an alternate configuration management method instead of CVS on sourceforge for lack of resources mainly time on the part of our team members to set up the CVS on sourceforge. The CM plan identifies this alternate strategy in its document.

At the same time, we recognise the need to have a CCB(change control board) as identified by RUP for controlling any changes to the artifacts after they've been baselined. We've already set up a CCB to approve/reject such change requests and have identified a detailed baselining and change request workflow as part of the CM document.