Each executive is able to specify the responsibilities that he/she is comfortable performing at a business meeting. These preferences are collated and stored in a manner that is easily accessible and modifiable when needed. X Inc. would like to use your Schedule Generator to generate monthly schedules for its business meetings.
The men of the congregation are able to express their preferences and availably for performing the various roles in worship and Bible study. These preferences are easily accessible and maintainable when needed. Church on the Block would like to use your Schedule Generator to generate monthly schedules for its meetings. Here is a sample schedule that represents the type of schedules that Church on the Block uses to manage its meetings.
This is a team assignment. My intention is not that you “divide and conquer” as much as that you have people to talk with as you write and test this program.
Everything that you submit for this project should be understood by all team members. It is your responsibility to (a) not submit anything without first discussing it with your teammates, and (b) not let something your teammates write go “over your head” without making a strong effort to understand it (including having a teammate explain it to you, of course).
Your SVN repository for this assignment is:
http://svn.csse.rose-hulman.edu/repos/csse221-201410-sgXXwhere XX is your team number given here. You should check out the
ScheduleGenerator project from this repository, and all
subsequent work should be placed in this project folder and committed
back to your repository.
Milestone dates are listed in the table below. The rest of this section describes the artifacts due at each milestone. Follow the instructions carefully. Your team may want to print a copy of this document, highlight the key things to do, and check them off as you do them.
| Cycle | Due Date |
Deliverables
(due at start of class on the given date unless specified) |
|---|---|---|
| Cycle 0 | Tues, Oct. 29 | End of class: CRC Cards, UML Class Diagram, Cycle 1 User Stories |
| Cycle 1 | Fri, Nov. 1 | Cycle 1 Status Report, Cycle 2 User Stories |
| Cycle 2 | Tues, Nov. 5 | Cycle 2 Status Report, Cycle 3 User Stories |
| Cycle 3 | Fri, Nov. 8 | Cycle 3 Status Report, Cycle 4 User Stories |
| Cycle 4 | Tues, Nov. 12 | Cycle 4 Status Report, Final working software |
| — | Wed, Nov. 13 | Project Presentation, Presentation schedule |
| — | Thurs, Nov. 14 | Team evaluation survey |
Because you will need some time to prepare capsule presentations, I will let your team skip any one of Cycles 1-3 during the project. Just commit a file named CycleXskip.txt to your Design folder to let me know. In any case, the final project is still due on October 31. I do not plan to assign written homework during this time period, but there is an exam, and there will be about an hour of videos on C programming to watch to prepare for class on Oct. 30.
You must use the object-oriented design technique discussed in the book
and in class to generate CRC Cards and a UML Class Diagram for your
project. Name your class with the main() method Main.
Before brainstorming candidate classes, you will probably find it helpful to do two things. First, decide as a team which features (see Features below) sound most interesting to do and which you'll want to do first. Second, make some sketches of potential screen layouts for your project.
You must draw your UML Class Diagram using UMLet.
Your CRC cards (index cards are OK, nothing electronic)
Your UML Class Diagram, drawn using UMLet or a similar program. Save it in your Eclipse project, replacing the existing UML.uxf document in the Planning folder, and commit it. You should save also a pdf version of your UML diagram in your Planning folder.
Short development cycles are a key feature of Extreme Programming. This is especially useful for projects where the development team—that’s you—is unfamiliar with the problem to be solved. At the start of each development cycle, the team negotiates with the customer on the work to be accomplished during that cycle.
The customer suggests user stories to be completed. These are short, often one sentence, descriptions of what the user would be able to do with the software. Using a drawing program as an example,
User launches program and sees a blank drawing area and some buttons representing actions that could be taken.
This story doesn’t say anything about the buttons actually working, so that is not part of this user story. A user story for a button working might be something like,
User clicks the Rectangle button and can then draw a rectangle in the drawing area by clicking and dragging the mouse.
User stories are powerful in two important ways. First, they make it very clear how to test whether the story has been completed. Second, they keep the development team focused on the importance of meeting the needs of the user.
After the customer has suggested some user stories for the cycle, the development team will decide whether it is reasonable to complete them all in the time available. If not, the customer will withdraw some of the proposed stories until an achievable set of stories is agreed upon.
For this assignment you’ll play both the customer role and that of the development team. As a customer, the number of features completed will help determine your grade (and how much fun you have with the project). As a development team, you’ll have to do the work to implement the user stories.
Each user story should have an estimate in ideal development time (likely between 30 mins and 4 hours). Calculate the total estimated time for this cycle and include it at the end of the list.
At the start of each development
cycle, you will commit a text document to your project repository
listing the user stories that you plan to complete during that cycle.
You can use the existing documents in your Eclipse project, in the Planning folder, named “Cycle N User Stories.txt”, where N is the cycle number.
Commit the file to your repository.
At the end of each development cycle, you will commit a text document to your project repository that lists the user stories and estimated times, then add the actual time you spent on each. Indicate either that you completed all of the user stories for the cycle or else list any user stories the team planned to complete but was not able to. Briefly state any complications that prevented you from completing the stories, for example, “We underestimated how hard it would be to implement input processing.”
You can just modify the document named “Cycle N Status
Report.txt”, where N is the cycle number just completed, in the Planning folder.
Commit the file to your repository.
You should be using good process as you go. Thus, for each cycle, your code must run, have good style and complete documentation. It should also have no other warnings, but sometimes these are inevitable (like if you have declared a variable you will use in the next cycle).
You must also complete the brief evaluation on Moodle identifying areas of improvement for your team.
We’ll grade the version of your software committed to your repository at the Project Presentation deadline. Your code should be well-commented and should use appropriate class, method, field, and variable names. No Eclipse warnings should remain for your final code according to our standard Eclipse preferences for CSSE 221. The Rules and Practices of Extreme Programming provide some excellent tips for engineering your solution.
Commit your code often. And don’t forget to update your code before working and before committing. The chances of SVN conflicts grow exponentially with the number of team members, but they decrease with the number of lines of code in the project. The net result is that you’ll have more trouble at the beginning of a project. For this reason it makes a lot of sense to program as a group or to carefully work on completely different classes in the beginning.
Your team will give a 10 minute presentation on your project, which will be open to the Rose-Hulman community. Your goals for this presentation are:
Every team member should play a significant role in the delivery of your presentation.
We will post a team evaluation survey on Moodle. You will receive individual points for completing the survey. I will also use the survey results to help decide whether to give different assignment scores to different team members. Perhaps most importantly, the survey results will help me identify where you are doing well as a teammate and where you can improve. Along with this is an individual reflection. It helps you introspect on what went well in the project and how you can do even better on your next project. You will be graded on the thoughtfulness of your answers.
The subsequent subsections list the features that your program is required to have and several potential additional features. An “A” project would include all of the required and additional features. A team that delivers all of the milestones, well done and on time, and produces a project that correctly implements all the required features will earn at least 70% on this assignment.
A Project Evaluation Form that we plan to use to evaluate your project is available for you to fill. You must enter your team information, check the features you implemented, and describe other notable features that you added to your design. This sheet must be handed to your instructor when you give your project presentation.
The subsequent subsections list the features that your program is required to have and several potential additional features. At this point, my thought is that an “A” project would include all of the required and additional features. A team that delivers all of the milestones, well done and on time, and produces a project that correctly implements all the required features will earn at least 70% on this assignment.
A successful program must include all of the following features:
Once your team completes the required features, you should try to complete as many of these additional features as time permits.
If your team completes all of the required and additional features above, then you can implement some of these bonus features. I’ll only award bonus points for these if all of the required and additional features are also implemented correctly.