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
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 Android conventions.
All code for this project should reside in the package edu.odu.cs.cs350
. Sub-packages of that are permitted.
Each team member should follow the procedure outlined in the GitLab assignment to identify yourself so that all commits you make are listed under your CS login name.
If you work on multiple clones of the repository (e.g., on different machines), you need to do this on each clone.
Work on implementing the stories for at least the first increment.
Follow the process described below in Demonstrating Test-Driven Development to track your progress on this increment.
Using 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.
Use the gradle wrapper so that all team members are using a consistent builder.
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).
Do include the gradle wrapper gradlew*
files and the associated gradle/
directory.
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 your code, and your grade will be based 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/
directory. (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 Gradle to fetch and integrate these libraries into your build.
“Submit” your project for this phase by tagging the version as “phase3”. Note: this should be a simple tag, not a new branch.
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. (Notes are added in RedMine by using the Edit button on an existing issue and then typing anything in the Notes box near the bottom of the page.)
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 at the end of the phase. The purpose of this survey is to help assess the contribution made by individual team members.
For this and all subsequent phases, please remember that you are working as a team. That doesn’t mean that you are yoked together like a team of horses that arrive at a job together, pull together in lockstep, and then are sent off at the end of the task all at the same time. You’re going to be working independently, but have to make sure that you don’t abuse that independence to the detriment of the team.
It is expected in a team project that other people will be using or building upon the code or other software artifacts that you are working on. Your teammates are depending upon you.
If you wait until the last day or two of each phase to do your tasks, you’ve let your team down because they will not have time to build upon your work or to make sure that your work integrates properly with theirs.
Even if you have done the work early, if you do not check it in to the team’s repository and make it available to them, you’ve still let your team down.
Set aside regular periods of time to work on this project.
Your team will be much better served by your working 30 minutes every other day for 14 days of a phase than by your working 7 hours on the 14th day.
That sort of procrastinatory brinkmanship might work for you on an individual assignment, but is deadly to team projects.
Try to set up each work period with a specific goal in mind. For example, you might devote one work period to writing one or two unit tests. If that’s all you get done, fine. You still have made observable progress.
Most people work much better if they have a specific goal in mind, and this also helps limit the scope of the changes so that you can easily commit them. Which brings us to the next point…
At the end of your work period, commit your changes. If your work is seriously incomplete and might break things for your teammates, check it in to your local copy of the repository but don’t push it to the team shared repository.
But don’t go too long before pushing your work to the team repository. That risks version conflicts that will be time-consuming to resolve.
Get into the habit of beginning each work session by pulling all changes from the team repository, so that, if your work is in conflict, you resolve that as early as possible.
Your team should try to get any shared “infrastructure” for the phase completed within the first first days of the phase. Examples would be setting up the repository, setting up the project directory structure, and setting up the build manager files.
That way the support structure is already in place when you get down to the “real” development work.
If you make changes to any public ADT interface, commit and push those changes as soon as possible. By definition, such changes have the potential to strongly affect the work of your teammates.
For example, if you are following the principles of TDD, you will start by asking whether the ADTs involved in your current story present the appropriate public functions to allow you to test the story’s behavior. If you add add public functions or modify the names/parameters of existing ones, you should commit and push those changes ASAP.
Don’t wait until you have completed the unit tests or, worse, until you have actually finished implementing the behavior. You might not get all that done until days later. Changes to public interfaces are things that your teammates need to know about as soon as possible.
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..5 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 szeil@odu.edu 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 thatA
callsC.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.
This needs to be opened as an Eclipse java and/or Gradle project in the Java project view, not simply as an unused clone in the Git repository view.
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.