 |
|
|
In this phase of the project, you will begin the software construction process. Your priorities during this phase will be setting up and learning to use your project’s version control repository and automating your build
Your reference materials for this phase include
These have been updated since phase 2 with info on the 3rd party libraries you will need to use and the training data for the project.
You should also review your grades from Phase 2 (stories). The detailed grade spreadsheet contains my own list of stories. If you are missing any of them, you may have failed to account for portions of the work required to finish this project. You should consider adding some of those to your own list of stories on RedMine, because I will continue to use those, in the future phases, as a basis for estimating how much of the project functionality you have implemented. If you do not have statements that describe the work you have done, you might not get credit for having done it.
Working from your GitLab project area, create a git repository for your project.
Your project directories should be organized according to the Apache or Android conventions.
Work on implementing the stories for the at least the first increment.
Follow this process to track your progress on this increment.
Using ant or gradle, automate the build of the project components so far. This should include all unit tests. The build should run all unit tests and (for now) whether those are passed or not, package the non-test components of the project as a Jar file.
As you add components to the project, check them into the repository using git.
Material placed under version control should include all source code, hand-edited data files, etc., as well as the build manager settings files.
Do not include binaries produced by compiling your own code, Jars or other binaries of 3rd-party libraries you have imported, etc.
Do include the Eclipse .project and .classpath files and the .gitignore file(s).
You may use branches to explore implementation alternatives. But your team’s main codeline should be the master/origin branch. That is where I will look for you code, and your grade will be pased in part upon your contributions to that branch.
Your project will eventually make use of a number of third-party libraries. Refer to the Design Notes linked at the top of this document for details.
When starting out, you may not need all of these. Use the Ant get task to fetch libraries and store them into a convenient location (e.g., within your build/ or target/ directory. (Gradle users remember: you can execute ant tasks from within Grade.) You will need to add these to your compilation and execution CLASSPATHs.
Near the end of this phase, however, you may be able to use the configuration management support of Ant+Ivy or Gradle to fetch and integrate these libraries into your build.
You are required to follow the principles of test-driven development and to document your practices in doing so.
In the previous phase, your team created stories in the Redmine issue tracker. You will use those to indicate what you are working on and how much progress you have made.
Go to the issue tracker, log in to your project, and select “Agile”. This will take you to the backlog board.
When you are ready to work on a story, assign it to yourself. (Drag your name from the list of project members on the right to the card for that story.)
The columns of the backlog board indicate how far you have progressed through the typical stages of TDD. Drag the story card from one column to the next as you begin each new activity.
So when you first start work on a story, you would drag it from “New” to “Interface Design”. When you have made any changes to ADT interfaces that you believe will be required, drag the card to “Test Case Development”. After you have developed your new unit test cases, move the card to implementation. When you are passing your tests, move the card to Integration. When your new code is successfully integrated into the rest of the project, move it to “Closed”.
You can also carry out these changes by editing the card and changing the “Status” field.
If necessary, you can move cards backwards. You can also move a card to the Rejected status at any time if the story has become unworkable or unneeded.
Add Notes to the cards as necessary to indicate why you have taken unusual steps.
As you move your cards from column to column, add Notes to the issue to explain what you have done. Specifically,
When you move from Interface Design to Test Design, your note should indicate which classes you have added or modified and which function interfaces you changed within those classes.
When you move from Test Design to Implementation, your note should indicate which unit test classes you added or modified and which functions within those classes are testing the behavior of this particular story..
When you move from Implementation to Integration, your note should indicate which functions in which classes implement the core behavior of this story.
When you move from Integration to Closed, you should indicate what integration and/or system test classes and functions test this story’s behavior.
If you don’t update your agile board, your group may not get credit for work accomplished. If you move the cards forward without adding the explanatory notes, I might not believe your claim to have finished something.
Each team member must individually take the peer evaluation survey. The purpose of this survey is to assess the contribution made by individual team members.
Evaluations will be a combination of how much the group has accomplished and how much each individual contributed to that group’s effort.
The login name / account used to create or edit stories or to commit code changes to the project will be also used as evidence of the individual’s efforts. This means that you should not appoint some students as scribes/librarians to record others’ work. Doing so will guarantee that the librarian gets credit for everyone else’s work.
Your team’s progress will be measured both in terms of what has been submitted and in a project review meeting. Refer to the more detailed description of the project review meetings below.
Phases 3 and 4 will be graded as
score = (_progress_ + process) * team * indiv
where:
progress is an assessment of the completeness, correctness, and quality of the work completed on the project.
process is an assessment of how well your team has set up its process, including use of required/recommended tools
team is a scaling factor for the overall team effort. A normal effort level is 1.0. Teams that attempt larger or smaller portions of the project than the norm will have this scaling factor applied.
indiv is a scaling factor for an individual’s effort. A normal effort level is 1.0. This factor is evaluated by a combination of
Near the beginning of phase 3, we will conduct a design “brainstorming” session during your recitation period. The purpose of this session is to arrive at a group consensus of the major components of the system design. As with all scheduled recitations, attendance is mandatory.
Prior to the meeting, review our earlier discussion of Object-Oriented Analysis, particularly the object-oriented philosophy and the idea of modeling in terms of interacting objects. CS330 students may want to review the process of “classification”, which lies at the heart of the analysis that we will be doing.
At the start of your hangout, one person should create a Google Doc editable by all team members and by @instructorEmail@ and share the URL to that. Make sure that your group name is part of the document file name.
Based upon the requirements and design notes, propose classes that you think will be essential to this project. Propose the major operations on these. Sketch these out in your shared document as C++ class interfaces.
Don’t worry about syntax and don’t waste time trying for perfection here. But do try to record things clearly enough so that someone can identify the classes, operations, and the major inputs/outputs of those functions.
Your first concern should be identifying classes that simulate the critical real-world objects.
When in doubt, “keep it real”!
A secondary (but still legitimate) concern is identifying classes that will be used as the implementing data structure for classes you have already devised. Don’t lock yourself into too much detail here. It’s too early, for example, to worry about whether something will be an array, vector, or list. But you may want to note that “class A will store a sequence of B”.
In assigning operations to classes, remember this rule:
If A does B to C in the real world then, in most cases, our model of the world as interacting objects should say that
B(...)is a function method of classC(notA).- Somewhere inside the body of some other method of class
A, we expect to find thatAcallsC.B(...).
After teams have had a little while to get the process going, the instructor will start moving from one team meeting to another to see how you are doing and offer suggestions where appropriate. The timing will depend on how much time is spent with other teams. Yours may be visited once, or multiple times.
After the meeting has concluded, put your shared document into your project Wiki either by copying it to a new Wiki page (linked from your front page) or by linking directly to the Google Doc URL.
These meetings will be held during the recitation periods, as announced on the course outline.
Meetings will be held by network conferencing (Hangouts). More details on network conferencing meetings is below.
This course is about tools and techniques to support software construction, not about programming specifically. Getting the project to work will count as part of the grade, but is not the only part and may not be the most important part, except in as much as it demonstrates mastery of the relevant tools and techniques.
Attendance at the scheduled review meeting is mandatory and counts toward the individual component of your score.
Please be on time. I will have only limited time with each team before I need to move on to my next meeting with another team. Making everyone wait while you struggle to enter the conference, play with your settings, etc., is unacceptable.
You should be in the conference area and ready to go at the announced starting time for the meeting. You can (and probably should) arrive early to get yourself set up.
At the start of the meeting, you must already have Eclipse open and ready with your own copy of your team’s project.
The version you have open should be the one submitted at the end of the phase. E.g., for phase 3 of the project, this would be the version that was tagged by your team as “phase3”.
If you have done additional work since the submission and are worried about losing it, make a fresh clone of your team’s project in a separate directory, check out the “phase?”-tagged version, and use that for the meeting.
You must be prepared to show your session via screen sharing. That includes having re-sized the window to a conservative size (e.g., 800x600) so that the shared image will be readable on other peoples’ screens.
During the meeting, I may ask the team to show that they have completed part of the assignment or to explain part of what they have done. I may call upon specific individual team members to explain or to demonstrate techniques relevant to the phase.
At the end of the meeting, your team may be given a short task to perform on an individual basis. You will have a limited time (less than a day, possibly as little as one hour) to do this and to submit the results.
An individual who is unable to complete a required task or answer a directed question to my satisfaction will lose individual score points. If a second individual in likewise unable to complete that task or to answer the question, then the overall team score will be reduced.
Meetings will be conducted via Hangouts. You will receive an email prior to the meeting containing a link that will take you to the meeting.
You must have a functioning microphone & audio setup for the meeting. A web camera is optional but recommended.
You must be in a place where you can both hear and be heard. Avoid trying to participate from locations with high levels of background noise (e.g., public areas in Webb center).
You should be able to enter the meeting area early.
This will allow you to be sure that your audio/video setup is working and that you have up-to-date versions of the browser plugins required.
If there are multiple teams being reviewed in a given recitation/class period and yours is not the first, the instructor will be in a separate hangouts area with the earlier team. Please be patient if the instructor is a bit late getting to you.
By the same token, the time to meet with your team is limited. You may be penalized if you are not ready to meet at the appointed time.
|
|