In this class we will be using a version control system called subversion. Subversion is free and by all accounts is wonderful at version control. It is also command line driven and that can be a pain. There is a nice free (both as in beer and as in speech) graphical client for windows called tortoise. As many of you know, I have lots of my classes work with linux/unix rather than windows so I want a nice solution (also free) for linux. Thats where this class comes in.
Your group assignments have been made, If there is someone unable to work in the groups as assigned for personal or scheduling reasons, let me know immediately since there is limited time and I had to make some of the assignments randomly.
Your assignment is to meet with a representative of the client (that would be your instructor) and begin developing a set of requirements documents. The meetings will probably take about a half hour. Please bring any questions you have about the project with you and I will answer them at that time. I will also be available by email, but more irregularly at other time.
Your documents will include:
A short domain Analysis document (1-3 pages as needed including the sections discussed in class, some may be empty if they are not applicable)
A requirements document which contains short, clear, objectively testable requirements for at least the following types of requirements:
Describe what the system should do
Constraints on the design to meet specified levels of quality
Constraints on the environment and technology of the system
A series of use cases describing likely interactions between users and administrators of your product and the product itself. You should have at least 5, but as many as needed to make a good analysis of the project.
Your group should try to make an appointment in the following sets of time which I will try to keep available for this class in the next week till the groups have all make appointments.
Tuesday from 11am-1pm
Wednesday from 9am-11am or from 3:30-4:30
Thursday <candidate is here>
Friday from 10:30-3:30
Monday from 9am-11am
Tuesday Feb 10 10am-12:30pm
Your group should make an appointment with me by 4pm on Wednesday.
the first draft of this document will be due Wednesday Feb 11th by 4:30pm, feel free to slip it under my door.
It is now time to begin designing your software solution to the
problem. Finish reading chapter 9 and read chapter 6 (which we are
seeing in the lecture this week) and understand it. Then start
designing the software. Your group will need to make a number of
design decisions. Keep track of the major decisions and the reasons
Your design assignment should include the following parts in the first draft:
A UML class diagram showing all of the classes in your solution including the instance variables and methods in those classes and the relationships between the classes. (Umbrello is a good UML tool, but others will do)
A document which accompanies the UML that summarizes what the methods are supposed to do and what the instance variables model/represent.
A document describing the major design decisions made and the reasons for those decisions.
An informal document that shows how each of the functional requirements will be implemented and in what class(es) and method(s).
In your design you should look to increase cohesion and reduce coupling as discussed in class and in chapter 9. Discuss briefly what your group did to reduce coupling and to increase cohesion in your design in a section of your documentation. You have relatively free reign, but when picking a language for implementation, you need to make sure that you choose one that is/can be object oriented.
The first draft is due on March 25th (Wednesday) In class.
Due Monday May 4th by 5pm. Test cases and results in hard copy.
Your automated testing code by email.
Testing: Write a set of test cases for testing another group's program. You will be testing the program from your group number + 1, group 4 will test group 1's program. Describe the equivalence classes to be used along with the testing regimen to be used. Categorize the tests as level 1, 2, or 3 tests as defined by your book. Include any automated testing mechanisms that you use in your submission.
Actually run the test cases. Record any bugs found and fix them (or describe why not.) remember I have your original code submitted to me and I'll run some of these tests myself.