The Capstone Requirement

• All students must complete 3 credits of a capstone course: either CS 4971 (the second half of this sequence) or CS 4980 (for independent projects)
• CS 4970 (this course) counts as a CS elective

Capstone Practicum I & II description

"This course is one option in the CS Senior Thesis track. Under the Practicum track, students will take two 3-credit courses, CS 4970 and CS 4971. These courses would form a year-long group-based and project-based practicum class. There would be an actual customer, which could be either internal (the course instructor, other CS professors, etc.) or external (local companies, local non-profits, etc.)."

Implementation

• The wording is vague so as to allow each instructor to choose how they want to run the capstone
• This implementation is the Service Learning Practicum (SLP) where the students develop software projects for local nonprofits
• We will use "Service Learning Practicum", "SLP", "Capstone Practicum", and "CS 4970/4971" interchangably

This slide set is dense...

• There is a LOT of course structure described in these slides
• We will remind you of the necessary parts as they come to pass
  • So you don't have to have all the due dates memorized
  • But you should be sure to understand everything
• It is all available online as well
  • http://aaronbloomfield.github.io/slp

A rule for this course

• Please turn off all social media and chats during lecture
• We are going to try not to waste your time
  • Don't waste ours by not paying attention
• You can only have your computer open if it is directly course-related
• That being said, you will need to have some means of connecting to the Internet during lecture
  • This can be a laptop, smart phone, or anything else that can log into a website

git Repository

• All the course materials are kept in a (public) github repository: http://github.com/aaronbloomfield/slp
  • You can view that material online directly at http://aaronbloomfield.github.io/slp/
  • The tentative lecture schedule is there as well (the list of slide sets)
• You will all need to use git for the course, and we will be using github extensively

A github note

• The first HW is an introduction to git and github, for which you will need two private repositories
  • We will only need them for a month or two in the fall
• If you don't already have one, you should create a github account -- you'll need it
• Then, request the student discount at https://education.github.com/; this may take a few days to be processed
• You should do this today, due to the delay in github processing it

I need your github userids

• Please fill out the brief form at https://goo.gl/9YpXTL
• You just list your uva userid, github userid, and github registered email address
• This must be done by the this Monday, but the sooner the better
  • Why don't you do it now? We can wait!
• You will also be sent that link via email

Course syllabus

• It is availabe in the github repo; you can click here to view it
• It contains all the information covered in this slide set, plus some more stuff

Student support

• The events of 11 days ago will have affected each of us in one way or the other
• In addition, this year will likely be stressful
• Remember that there are many student resources when you need support:
  • Lisa Lampe and Julie Carrucio in the Engineering office
  • Counseling and Psychological Services (CAPS)
  • UVa student support (from CLAS): http://college.as.virginia.edu/student-services
  • And feel free to chat with us at any time

Instructors

• Both Bloomfield and Ibrahim will be co-teaching it in the fall
• Ibrahim will be teaching it solo in the spring
  • Bloomfield is on sabbatical

Registration information

• There are a bunch of people who want into the course
• The maximum group size is 7 per group, so we can only allow in 7 times the number of projects that we have
• We are expecting to have 14-16 projects; thus we can accept 98-112 students
• But we don't have those projects locked down just yet; we expect to know more next week
• So if you aren't registered, please hang tight, and still come to lecture!

Teams

• Students will be in groups of size of 6 or 7, and assigned to a given project
  • That will be the project (and the group) for the entire academic year!
• Group and project assignment will be based on your survey responses
  • That survey will attempt to ensure that you do not end up in a group -- or on a project -- that you do not want to be in
• You will be able to specify any "mortal enemies" that you have in the class

Project lead

• This is one of the team members who does some of the coordination for the team
  • It's an administrative position, not an authoritative one!
• Lead responsibilities:
  • Handle meeting scheduling
  • Move the meetings along
  • Submit reports (more on this later)
  • Be the single point of contact for the team
• The lead will rotate through all the group members throughout the academic year

Secretary

• The other leadership position in each group; it also rotates through all the group members
• S/he takes notes at each meeting and enters them into the course management system
  • More on the course management system later...

Consensus

• The goal of these projects is for all decisions to be made through a consensus of the group members
• This may not always be possible, but it makes for a far more enjoyable experience
• If there is a major disagreement, then it is our job to help resolve it

Customers

• A representative from each of the nonprofits will be part of each group
• Sometimes the executive director, but often the staff member who most has to deal with the issues that the system is resolving

Graduate TA

• In Kee Kim (ik2sb)
• He will be meeting with each group for a 30-minute period every other week
  • These meetings will start in October

Projects

• We expect to have about 15 projects
  • 6-7 students per project, so the number projects will depend on the final enrollment numbers
  • There are 8-10 currently specified projects, and a half dozen possible ones on deck
• So we will have a full docket of projects
• They won't be assigned until September 17th
• Each project will have a requirements document which will contain a project description and minimum, desired, and optional requirements

Typical weekly class schedule

• Once the semester gets going, our schedule will be:
  • Mondays: a group meetings in the lecture classroom
  • Wednesdays: a lecture on a relevant topic
  • Fridays: no class! w00t!
• However, we will be having lectures M/W/F for the first few weeks of class
  • Including this Friday!

Meetings

• There are three types of meetings
• Customer meetings: where the customer is present
  • Every two weeks, about 1 hour each
    • We'll go over how to handle these meetings before your first one
  • Will typically be in the first week of an iteration
• Instructor meeting: every two weeks, with the graduate TA, and for about 30 minutes each
• Group meetings: any other meeting of the group (likely 1-2 per week)
  • This includes the in-class meetings on Mondays

"Sprints" or "Iterations"

• Work in this class will be in 2-week "sprints" or "iterations"
  • More on this in an upcoming lecture
• Tasks are chosen to be completed by the end of a given sprint
• The sprint will end on a Monday immediately prior to a customer meeting
• The customer will have a few days to look it over prior to your meeting with him/her
• The current system can then be discussed in the customer meeting

"Phases"

• A "phase" is a period that contains 2 or 3 iterations
• Each person will be the project lead for one phase this year
  • And the secretary for a different phase
• At the end of each phase, everybody has to fill out an end-of-phase survey
  • How things went, etc.
  • These are required, and massive points will be deducted if you don't fill them out!
  • Don't worry, I'll be sure you remind you about them repeatedly

Attendance

• We are all adults, playing the part of professional software engineers
• Don't miss class or meetings
  • Attendance factors into the course grade
• I'm going to get cranky if people are always coming in late to class...

Project deployment schedule

• Projects will not be assigned until the middle of September
• A functional prototype consisting of the "minimum" requirements is to be deployed in December
• The final system is to be deployed by March 26th, 2018
  • Missing this deadline will result in failure for the course for the entire group!
  • This gives us a 6 weeks to tweak it, bug fix it, etc.

Project deployment schedule

• Not delivering a working system in December (for CS 4970) or May (for CS 4971) will also result in an incomplete or failure for the course!

High-level fall schedule

• September: learn the software framework to be used, select projects, get to know the group
• October: meet with the customer to learn the details of the project, continue to learn the software framework
• November: development of the initial system
• December: refinement of the initial system, deployment to a UVa server for the customer to use over break

Spring 2018 semester

• All of you will need to take the Spring 2018 version of this class (CS 4971)
  • All of those who are using this course as their senior thesis project will need to take it to complete their senior thesis and fulfill the capstone requirement
  • All those who are not 4th year BS CS majors have agreed to take the spring version of the course
• The spring semester is just a continuation of this course

High-level spring schedule

• January: fixing the bugs the customer found over the holiday break, continue software development
• February: initial deployment, continue software development
• March: continue software development
• April: deployment, beta testing by the customer, writing of the documentation
• May: finalization of the deployment and delivery of the software to the customer

2017-2018 Iteration schedule

• All iterations start on a Tuesday and end on a Monday two weeks later; they start on Sep 19th
• There are 6 iterations in the fall:
  • Sep 19 -> Oct 2, Oct 3 -> 16, Oct 17 -> 30, Oct 31 -> Nov 13, Nov 14 -> 27, Nov 28 -> Dec 11
  • The last half of iteration 6 is during finals week
• There are 8 iterations in the spring:
  • Jan 16 -> 29, Jan 30 -> Feb 12, Feb 13 -> 26, Feb 27 -> Mar 12, Mar 13 -> 26, Mar 27 -> Apr 9, Apr 10 -> 23, Apr 24 -> May 7
  • Iteration 10 has spring break
  • The last half of iteration 14 is during finals week

Phases

• Fall semester: 6 iterations
  • Each phase will be two iterations long
  • Phase 1 is iterations 1-2, phase 2 is iterations 3-4, and phase 3 is iterations 5-6
• Spring semester: 8 iterations
  • Phase sizes will differ depending on the group size
  • For 6 person groups, there will be 3 phases: iterations 7-9, 10-11, and 12-14
  • For 7 person groups, there will be 4 phases: iterations 7-8, 9-10, 11-12, and 13-14

Tracking time

• You MUST keep track of your time for this course (once projects start)
  • It will be entered via the course admin website; link is available via Collab
• Not keeping track of time will incur a grade penalty!
• However, to prevent time inflation, I make this guarantee to you:
  • I will NEVER use the amount of time you enter to determine any part of your grade for this course (or the spring course)
• You are on your honor to enter time accurately

Reports

• One of the lead responsibilities: submit reports
• The lead will need to submit three (or so) reports in each iteration
• There are three types: weekly report (one to be submitted), TPS reports (one to be submitted), and meeting reports (variable number to be submitted, but often just one)
• Recall that iterations are 2 weeks long
• Reports are submitted via the course admin website
  • Please don't email them to either of us

The Weekly Report

• This report is submitted one week into the two-week iteration, and briefly describes the progress made so far during that week
  • The customer meeting should have occurred during this time; you will have gotten feedback from that meeting
  • You will have chosen your tasks for the iteration
  • You will have (hopefully) made some progress
• This report need not be long -- a 5-line paragraph is sufficient (say, 100 words) -- we don't like fluff!
  • They are judged on their quality, not quantity

The TPS Report

• TPS stands for "Termination and Post-reflection of Sprint" (see Office Space for the reference)
• This report is a bit longer than the weekly reports (say, 200 words)
• It should stand by itself (i.e., not require somebody to read another report to understand the context)
• Contents:
  • What was achieved this iteration? It will likely have to reference github issues
  • Did you achieve all your expectations set out in the first weekly report?
  • Etc.

The Meeting Report

• This to be submitted whenever there is a meeting with an external individual (customer)
• The purpose is to notify me of such a meeting, so we can contact them to see how things are going from their end
• It is due by the end of the meeting
  • Anybody can submit it, but it is the project lead's responsibility to ensure that it is submitted
• Meetings without an external individual (i.e., the customer) should not submit this type of report
  • Don't submit with the grad TA

Meeting report contents

• This report should only be ONE LINE
  • "Today we met with Jane Doe from 1:00-2:00 in Rice 404"
    • (assuming Jane Doe is your customer's name)
  • That's really all we want; this report is not meant to take any significant amount of time
• It should NOT go into details about what happened in that meeting
  • Those details are already in the meeting minutes
  • And summaries would presumably go into the weekly or TPS reports

Report due dates

• An iteration:
  • ...starts on a Tuesday (that is iteration day 1)
  • ...ends at the end of the day on Monday two weeks later (that is iteration day 14)
• Weekly report: due by noon on Tuesday one week into the iteration (day 8)
• TPS report: due by noon on the Tuesday immediately after the iteration ends (day "15")
• Meeting report: due by the end of said meeting

Rules on reports

• Don't add fluff! We hate fluff.
• We are interested in quality, not quantity; the word counts were just guidelines
• Reports are viewable by the entire group
  • If you have issues that require a different visibility, speak to either of us in person or by email

Report submission...

• ... is YOUR responsibility
• We will always remind you in lecture, but we are not going to e-mail you to remind you
• There are grade penalties for reports not submitted or that are submitted late!
• Reports are entered into a custom system that we will show you in a week or so
• Remember that the entire group gets a grade penalty if a report is not submitted, and the non-lead members can check to make sure it's submitted

My grading philosophy...

• Everybody starts out with an A, and then it can only go downhill from there
• No bell curve! So everybody can get an A or a D.
• Delivery of a non-working system (in both December and May) will result in an incomplete or a failure for the ENTIRE group
  • I held up the graduation of an entire group in May 2013 because of this
  • And there were some students who did not graduate because of this

Things that contribute to your grades

• Homework assignments
• Attendance and pop quizzes
• Customer satisfaction (based on our interactions with them as well as a survey they complete)
• Journaling entries (more on this shortly)
• Final project (in lieu of a final exam)
• Progress in achieving goals (more on this shortly)
• Our evaluations of your effort and your group's effort

Things that decrement your grades

• Missing class or meetings
• Not submitting your reports (or submitting them really late)
• Not completing your journaling entries
• Not completing the surveys when requested
• Not submitting hours each iteration
• Not properly keeping track of your group progress through github issues

Things that increment your grades

• Helping the class in some way
• Higher-than-average contributions to your group
• Winning the Nobel Peace Prize
  • Or any Nobel prize, really...

Things that do NOT affect your grade

• The number of hours you submit
  • Only whether you are regularly submitting them
• Your honest evaluations of your effort or your group members effort
• Customer evaluations
  • Customer satisfaction does affect your grade, but I take this into account with a grain of salt; the customer does not evaluate you directly

Things that just make us really cranky and thus really negatively affect your grades

• Not submitting the surveys by their due date
  • This just holds up my work, and I have to go track those people down
• Not submitting the reports
  • The ENTIRE group gets a penatly for this, so anybody can check that it was submitted
• Not submitting your hours
  • It makes it really hard to generate any statistics when people forget this

More on the grading metric

• The grading metric is specifically calibrated so that if you receive an average of "good" on your iteration evaluations and do an average amount of work for your project, then you are on track to receive an A
• Here, "on track" means that there are other factors as well:
  • Homeworks
  • Project evaluation
  • Final exam, project, or presentation

Sample Grading Metric

• Base metric
  • 45%: iteration evaluations
  • 25%: final project evaluation
  • 10%: homeworks
  • 10%: final exam, project, or presentation
  • 10%: journal entries
• Modifications
  • Group work is multiplied by a factor, which is an estimate of how much work you did for the group
  • Penalties for things (next slide)
• This is all subject to change, with appropriate notice

Penalties

• Penalties are assessed for various things
• These are a percentage of of your final course grade
• They are:
  • -3% for each class missed without a valid reason
  • -3% for each iteration with no reported hours
    • We're fine if they are submitted late every now and then
  • -10% for each survey not completed
    • We send you reminders, so no need to worry...

Homeworks, pop quizzes, etc.

• There will be occasional things to be done:
  • Fill out this survey, etc.
• There will be occasional homeworks:
  • Create a website using this framework, etc.
• There may be occasional pop quizzes
• The goal of all this is to make sure everybody is doing the work necessary
  • I really hate grading

Journal entries

• Each iteration, you will be given a prompt
  • Something to read, ponder, a question to answer, etc.
• You will then have to write a short response to said prompt
  • We are not looking for long-winded responses, but some thought is necessary
  • A couple hundred words is reasonable
• These will start once the projects start
• They are to be done individually, and will be graded

Iteration evaluations

• Each iteration will have an evaluation completed approximately 1 week after the iteration completes
  • In addition to comments, there will be one overall evaluation as to the progress: none, poor, fair, good, excellent
• This will directly affect the grade for each group member!
• You can request that we re-evaluate within 2 weeks of when they are released
  • But only if we missed something!
  • You can't make up the work after the iteration!

"Progress in achieving goals"

• This does not mean that you have to complete everything you initially set out to do
  • If you set out to do too much, then you will be in trouble
• It means that:
  • Your goals have to be reasonable
  • You have to make consistent progress
  • You have to keep your goals (and expectations) updated

Exams

• None planned!
• But we will have a final project in lieu of a final exam
• And the project presentations may take place during the final exam period (Thu, Dec 14 from 2 p.m. -- 5 p.m.)
  • That's toward the end of finals week...
• That being said, we reserve the right to add a final exam if we feel like we want to spend some time grading...

Surveys

• There are 8 or 9 surveys that you will have to complete this entire year (4 or 5 a semester)
  • The beginning of fall semester survey in September, which includes your project preferences
  • One after each phase, which is a chance for you to say how the phase went (there are 3 or 4 of these a semester)
  • The end of year survey in May
• All are through a system called LimeSurvey; we'll provide you with a link

Senior Theses

• Most of you are using this as the technical project for your senior thesis
• You must still register for STS 4500!
  • In the initial survey you will let us know who your STS instructor is
• You will list both of us as your technical advisors, and you will be in a group (or project-based) senior thesis
  • Prospectus signatures are due around December 1st

Senior Theses

• The project groups won't be known until mid to late September; if this causes an issue, let us know
  • If they want your technical topic, you can let them know that you are in the CS capstone course, and that the topics will be known late September
  • If that doesn't work, we can chat with them
• For the STS topic, you can pick something related to the nonprofit you are working with
  • Or make up your own topic

More senior theses stuff

• Your technical deliverables will be written by the group
  • As far as STS 4500/4600 goes, you just have a technical report that you will write for us
  • You will have other documentation to write in the spring for this course
• The technical report will have to be in ACM SIG format
  • We'll provide details as we reach that point in the spring

What software you can use

• You are NOT to reinvent the wheel!
  • If there exists software components that achieve what you want to achieve, you should use that directly!
  • You must properly cite the software that you use!
• However, we have to be cognizant of the licensing issues
  • As this is a real-world development project
• In particular, you probably can NOT use any GPL software
  • I have an entire lecture on this...

Legal agreements, part 1

• There will be a legal agreement that you will have to sign
• It gives the nonprofit the right to:
  • Use your software forever
  • Improve upon your software
• It prevents the nonprofit from:
  • Selling or distributing your software
  • Using it for commercial purposes
• It retains for you:
  • All other rights, including the right to distribute or sell the software

Legal agreements, part 2

• There are two
• Both can be found here
• "Student Participation and Release Form" is what gives the nonprofit rights to use the system you develop
  • It is what was mentioned on the previous slide
• "Capstone NDA" is a UVa-approved non-disclosure agreement that the nonprofit will likely ask you to sign

Must you sign the agreement?

• No, but if you don't, then you can not develop software for a nonprofit
  • And that means you will likely have to take the independent project track, and drop this course
• Nobody has yet objected to the agreement yet
  • Development of the agreements were with Provost's office and UVa's general counsel
  • In particular, it does not restrict your rights, it only gives some (limited) rights to the nonprofit
• In the survey, I will ask if you are willing to sign the agreement and the NDA

Open Source Projects

• There will be some projects that are to be open source
• Students on that project will have to sign an additional form indicating that they agree to release their code base under an appropriate license
  • Default is the GPL, unless the group -- along with us -- chooses a different license
• If you would rather not do this, then choose a different project

Open Source Projects

• Keep in mind that any group is allowed to open source their project if they so choose -- they just have to all agree to it
  • But some projects will be required to be open source

Collab

• Unfortunately...
• I'll only use it for: mailing list, account information dissemination, large file downloads
• And not much else...

VirtualBox

• It mostly works properly
• This is one of multiple options one can use to develop their system
• We will provide a VirtualBox image all configured for development for the three platforms used in this course
  • The image details can be found here
• Don't use previous images (including your CS 2150 image), as that software will be out of date

Docker

• Another option to use to develop your system
• There are pros and cons to the various ways to develop (VirtualBox vs Docker, etc.)
  • See here for details
• You are welcome to install any and all software on your own machine (and to use any OS), but you are on your own with that...

github.com

• The main course repo will be there, including all the slide notes: https://github.com/aaronbloomfield/slp
  • And online at http://aaronbloomfield.github.io/slp
• A number of repos that you will use will be in the "uva-slp" github organization
• You will need to provide two private repositories for the git/github homework
• Your (private) individual project repositories will be hosted there
• We'll be using issues and the wiki extensively

Continuous Integration (CI) site

• We will use TravisCI

Basecamp

• We will be using this for tracking project progress and communication
• More details on this once the projects start

Course administration system

• A custom system accessed through Collab or netbadge
• When the projects start, we'll go over this
• This will be used for (among other things):
  • Time tracking
  • Taking of notes for meetings
  • Submitting reports
  • Keeping track of attendance
• URL: https://slp.cs.virginia.edu:444/admin
  • Note the oddball port number!
• You won't be able to log in until the projects start

Ruby on Rails

• Ruby is the language, Rails is the framework
• Pros:
  • Ruby and Rails interoperate much better than most other frameworks
  • It's a "cleaner" OO experience than many others
  • There are a LOT of libraries ("gems") available
• Cons:
  • Installation is a real pain in the @#($&#.
  • Most hosting sites have very old (and likely very insecure) versions installed
    • And you can't run multiple versions on a single web server instance

Django

• A Python-based development platform
• Pros:
  • Python is a really nice language to develop in
  • There are a lot of libraries available
  • This platform is becoming much more popular these days
• Cons:
  • It is harder (but not impossible) to find hosting providers

Wireframing

• Everybody will have to create wireframes for their project
  • This is in the October timeframe
• Examples
  • balsamiq
  • MockFlow
  • And others...
• By far, the most popular one last year was jetstrap
  • A drag-and-drop wireframe tool that outputs Bootstrap code