Team Software Development for Community Organizations

CSC 322, spring 2015
Th 1:15 - 4:05, Science 3819
Janet Davis

Announcements

Contents

Catalog description

Application of software development principles and practices to a large-scale project. Teams of 3-6 students build software for a community organization, supported by a faculty adviser and an alumni technical mentor. Students will gain experience working with a client and building a substantial code base suitable for inclusion in a professional portfolio. Students are encouraged to repeat the course for credit to experience multiple roles within a team and multiple phases of the software lifecycle.

Course goals and structure

In this course, you will apply agile software development principles and practices to a large-scale, ongoing, team project. To motivate and provide context for the work, projects will serve a community organization. To provide technical expertise and professional perspective, alumni mentors will draw upon their practical software development experience.

You will gain experience with the complexities of real-world software development: communicating with clients; working as part of a team; self-directed technical learning; creating a substantial project from scratch, or learning an existing code base; making design decisions that may have long-term consequences; managing a large code base; addressing pragmatic and ethical dilemmas. You will be able to draw upon these experiences in pursuing academic or industry positions. By sharing your source code through GitHub, you will make a substantial beginning or addition to your professional portfolio. You will develop professional skills and perspectives.

The class will meet once weekly for a three-hour lab block over the 14-week semester. During most weeks you will be expected to meet and work for an additional 3 hours outside of class. There will be few readings and no examinations. Work will be student-directed; the instructor and alumni mentors will serve as consultants.

Over the semester, your project will develop as follows:

This course is a companion to CSC 321, Software Development Principles and Practices. In CSC 321, you will learn how to apply agile software methodology to developing software as a service (SaaS) using the Ruby on Rails framework. In this course, you will apply what you learned to a large-scale, real-world project. If you take CSC 322 concurrently with CSC 321, you will find that topics are introduced in CSC 321 just in time to apply them in CSC 322.

CSC 322 may be repeated for credit. However, due to changes in CS department staffing, it is not yet known whether CSC 322 will be offered in the 2015-6 academic year.

Time commitment

I expect this class to take about half as much time as a typically rigorous, 4-credit, Grinnell CS class. You can expect to spend about 6-7 hours each week, including time spent in class.

Textbooks

This course has one optional textbook:

To support additional topics you may want or need to learn on your own, I have stocked the CS Library with a shelf of books on related topics: Ruby and Ruby on Rails; regular expressions; Web design and usability; HTML, CSS, and XML; version control and other tools; Scrum and XP; and software engineering in general.

Of course, the Web is a great resource as well. We will maintain bookmarks for useful Web resources on Orgsync.

Roles

Agile software development is about people at least as much as it is about process or product. The success of this class relies on students and other stakeholders fulfilling their responsibilities in a number of roles:

The Team consists of 3-6 students (a "one-pizza team") who will develop and deliver the software. Our class will form 3-4 teams, with each student assigned to exactly one team.

The Community Partner (a.k.a. "Customer") has a software need which is to be fulfilled by the team's work. To ensure this is a learning experience, the community partners have identified real needs which are nonetheless not mission critical. The community partner will help the team articulate what the software should do, give feedback on how users should interact with it, and validate that requirements are met.

The Alumni Mentor is a Grinnell alumna/us who graduated 5-10 years ago and has significant experience with Ruby on Rails and agile software development. Teams will meet their mentors through a short teleconference during the first part of the semester. During an on-campus workshop, the mentor will coach the team through just enough intitial design. Thereafter, the mentor will join the team via teleconference for a retrospective at the end of each iteration. During each iteration, the alumni mentor will be available to provide advice and support in addressing technical and project management challenges.

The Product Owner is the team member who maintains the project vision, prioritizes user stories, and keeps an open line of communication with the customer. The product owner role will be held by one team member throughout the semester.

The ScrumMaster (a.k.a. "Project Manager") is a team member who keeps the team on task, facilitates team processes, and ensures the team has the resources it needs to succeed. In this class, the ScrumMaster will also coordinate team communications with the alumni mentor. This role may rotate among members of the team in accordance with their interest, but the ScrumMaster and Product Owner roles should never be held by the same person.

The Instructor is responsible for determining the structure of the course, identifying and assigning projects, facilitating team formation and interactions between teams, and assessing both team progress and individual learning. The Instructor may also assist with any interpersonal issues that cannot be settled within the team.

Policies

Academic honesty and respecting copyright

As students, you are members of the academic community. Both the College and I expect the highest standards of academic honesty. (See the Grinnell College Catalog). Among other things, this means clearly distinguishing between work that is your own, and work that should be attributed to others. This includes ideas and examples that you draw from labs and readings.

Moreover, in this course, you are joining a professional community of practice with its own customs concerning the open sharing of code and laws protecting individual and corporate copyrights.

It is expected that you will adhere to the following collaboration and copyright policies.

As an instructor, I will meet my obligation to bring any work suspected to be in violation of the College's Academic Honesty Policy to the attention of the Committee on Academic Standing, after which there is no recourse with me.

However, copyright violations in the context of the project are not merely academic: They may poison your team's codebase and thereby delay or prevent your project from being used by our community partners. Be mindful of how you use others' code!

Accommodations

I encourage students with documented disabilities, including invisible disabilities such as chronic illness, learning disabilities, and psychiatric disabilities, to discuss appropriate accommodations with me. You will also need to have a conversation about and provide documentation of your disability to the Coordinator for Disability Resources, Autumn Wilke, located on the 3rd floor of the Rosenfield Center (x3702).

Attendance

I will generally provide flexibility in how you use class time, as long as the time is used productively and educational objectives are met. Some class sessions will have a flexible location to permit you to meet with your project partner during regular work hours. I expect each team's project manager to briefly report to me by email how you used class time and who was present.

In the spirit of mutual professional responsibility, each student gets one "vacation day" and one "sick day." Your foremost responsibility is to your team.

Since our class meets only once per week, I will deduct 3% from your overall grade for each absence not accounted for by the above policies.

Two important exceptions when everyone's attendance is required:

  1. We will have an on-campus workshop with alumni mentors from noon until about 7 p.m. on Thursday, February 12. I expect you to prioritize this one-day workshop over other activities such as athletics.

  2. Barring illness, you must attend your team's final presentation.

I plan to be absent for the SIGCSE Annual Technical Symposium on March 5. I expect teams to make progress on Iteration 1 during this time, and I will make myself available via a Google Hangout for questions and troubleshooting. I promise to take a sick day if need be; you will be expected to make the most of class time in my absence.

Deadlines

Obviously, in order to demonstrate your work during class, it must be complete. A team self-assessment will be due on the Friday ending each iteration.

At times, you may find your team can work more efficiently if you get feedback on your work before class. I am happy to schedule a one-time or standing appointment to review work with your team outside of class. Use my online scheduling tool for a one-time appointment (15 minutes should be enough) or talk to me to schedule a standing appointment.

Getting help

For advice on technical, design, project management, and customer communication problems, you should take advantage of your alumni mentor's professional experience. Each team should negotiate with their mentor how best to communicate between meetings - by email, telephone, IRC, or another medium - and how quickly to expect a response. In deciding when to seek help, consider this advice: You Must Try, and Then You Must Ask.

You are welcome to meet with me about concerns regarding the class itself and interpersonal issues you cannot resolve within your team, as well as any other concerns you are not comfortable taking to your alumni mentor. You may drop in during my office hours, posted weekly on my Google calendar, and you may knock any time my door is open. If your need is known at least 12 hours in advance, I encourage you to schedule an appointment with me.

Grading

Because of the experiential nature of this class, I see my role as more of a facilitator than as an instructor. However, it is also part of my duty to assess your learning and assign you a final grade for the course.

I will maintain a gradebook for this course on PioneerWeb.

I will use the following scheme as an initial basis for assigning final grades:

Type of work
Team or individual
# of assignments
Weight
Iteration 0
Team
1
10%
Iterations 1 - 4
Team/individual *
4
60%
Final presentation
Team
1
10%
Final portfolio
Individual
1
20%

* Each student will rate the contributions of each of their team members for each iteration; I will anonymize and share team feedback with you.  For iteration 0, there will be no impact on your grade. For the remaining iterations, peer ratings will factor into your individual iteration score as follows:

I do not believe in grading on a curve; I would be thrilled to give you all As. However, I reserve the right to make adjustments if this weighting scheme produces grades which are lower than I believe are deserved. Any such adjustments will only raise your grade, never lower it.

Remember this is a 2-credit class and will carry half of the usual weight in your cumulative GPA.

Schedule

See events on OrgSync for more detail.

Date Iteration Class activities Class location
Due (at or before class time)
Jan 22
-2
Orientation
SCI 3819

Jan 39
-1
Forming teams
SCI 3819
StrengthsFinder; Résumé; Project preferences (Monday)
Feb 5
0.1
First meetings with partners
Various
Date, time, and location for first partner meeting;
Request transportation if needed
Feb 12
0.2
V2MOM and story workshop, with mentors
SCI 3819
Initial user stories on index cards;
Individual drafts of V2MOM
Feb 19
0.3
Code walkthrough
Various
TBD
Feb 26
0.4
Get partner feedback on V2MOM, mockups, and storyboards
Various
Initial stories in Trello;
Team V2MOM;
Initial lo-fi mockups and storyboards;
Iteration 0 done
Mar 5
1.1
Iteration 1 workshop
Various
Cucumber scenarios for iteration 1
Mar 12
1.2
Iteration 1 demos
SCI 3819
Read about iteration demo and retrospective;
Iteration 1 done
Spring Break


Apr 2
2.1
Iteration 2 workshop
Various
Cucumber scenarios for iteration 2
Apr 9
2.2
Iteration 2 demos
SCI 3819
Iteration 2 done
Apr 16
3.1
Iteration 3 workshop
Various
Cucumber scenarios for iteration 3
Apr 23
3.2
Iteration 3 demos
SCI 3819
Iteration 3 done
Apr 30
4.1
Iteration 4 workshop
Various
Cucumber scenarios for iteration 4
May 7
4.2
Final presentations; course retrospective
SCI 3821
Iteration 4 done
May 15
Portfolio due at 5 pm


Janet Davis (davisjan@cs.grinnell.edu)
Created August 24, 2014
Last revised April 30, 2015