This is a class about making software in teams; you'll ship 2 versions of a web application while learning about the many underlying theories and methods in software engineering.

This syllabus is organized as follows:

project

The centerpiece of this class is your team's software development project. Your team project will take place over 10 weeks and involve two deployments. The first deployment is based on the requirements document on the right; the second deployment is based on requirements that your team specifies in week 8. The very first thing you do for this class is read this document.

who's on my team?

Your team will consist of 4 classmates. We will assign teams based on a survey you complete in the first day of class. You will not be able to choose your teammates, but you will have an opportunity to indicate (1) what skills you excel at and (2) what skills you'd like to learn. We will attempt to ensure that all teams have at least one person with client-side web development skills.

There are a number of reasons why you can't choose your teammates. First, you rarely get to choose who you work with in the professional world. Second, this is very much a class about learning to work with people effectively, regardless of their personalities. I won't explicitly design groups to cause interpersonal friction, but some friction is inevitable between teammates who don't know each other well. This is your chance to learn how to succeed as a team despite social loafers and micromanaging managers.

who does what?

Software teams are composed in a variety of ways, with a variety of roles. There are often managers, developers, testers, designers, technical writers, support staff, marketers, and a variety of other more specific roles. Since your teams will only have 3 or 4 people, it won't be possible for you to have such explicit roles. Instead, it's worth considering the various responsibilities you'll have and who might be best qualified to take them on. These responsibilities include:

All of these responsibilities will play a role in your success this quarter, and you may take on a variety of them across the quarter. In other words, I will not assign these responsibilities. Instead, you and your team will decide who does what, thinking carefully and deliberately about who should be doing what and when based on their skills, availability, and communication skills.

who are the users?

Since this is a user-centered design course, you might be wondering for whom who you're engineering this software. The answer is that your making this software for Informatics students. They are the ones whose needs you are satisfying and they are the ones who you should study and test with. If you decide to have a design role on your team, a central part of their responsibilities should be doing user research on your classmates needs and activities and testing the usability of your software with your classmates.

concerning code

This project will involve the creation of a substantial amount of HTML, CSS, and JavaScript code. However, unlike a computer science class, I do not expect that your code will be written entirely by your team. For example, if you find example code in the public domain online that helps you with your implementation, feel free to use it (but do include a URL in a comment, citing the source). You're also welcome to use APIs and other frameworks, as long as you follow their licensing requirements.

You're also welcome to share code with other teams in the class. However, remember that you are competing with other teams for 10 points at the end of the quarter, so it may be to your advantage to minimize how much you share with other teams. They are, after all, your direct competitors.

grading

Your grade will be based on a 100 point scale:

All points are worth the same amount, regardless of what category they come from. Your points will be converted into a grade point with approximately the following formula:

grade point = round((total points - 60) x 0.089 + 0.7)

There are likely some edge cases due to rounding differences on GradeBook.

This formula produces this mapping:

totalgrade point
≥ 97 points4.0
86 points3.0
75 points2.0
63 points1.0
60 points0.7
≤ 59 points0.0

Finally, there are a few important policies that I will strictly enforce:

My philosophy on grades is that if you show up and turn everything in, but do everything to the lowest level of quality, you should be able to get a 0.7 (D-). There are no A's for effort in this class. To really earn your A (or B or C), I expect quality. I will do my best throughout the quarter to convey what quality means, but if you're still confused, I expect you to ask me or the TA.

deliverables (50 points, 5 points each, team)

Deliverables are assigned on Fridays and due the following Friday. Details about the deliverables and their grading criteria can be found in the links in the schedule. All members on a team will receive the same score for each deliverable (even if you believe one member's contributions were minimal). You are encouraged to apply the teamwork skills discussed in class to maximize everyone's contribution to your team deliverables.

Most of your deliverables will be "submitted" by attaching them to your project wiki. We'll check their attachment times to ensure they're not late and download local copies for review. Details about where to attach your deliverables will be specified in each deliverable's description.

2.0 release quality (10 points, team)

A portion of your grade is explicitly based on the quality of your team's 2.0 deliverables. What counts as quality is not up to the software team, but the market to which the team's software is deployed. Your market is the all of your classmates.

You will individually rank all projects in class, including your own, twice: once after version 1.0s are deployed and another time after version 2.0s are deployed, during finals week. The first ranking your team receives should help your team get feedback about why you received the ranking and help you improve your ranking for the second time, when it actually counts toward your grade. To rank the applications, you'll individually try all of the deployed applications and rank order them based on which you would personally prefer to use to take notes.

To actually perform the ranking, you will be responsible for going through each other team's application, trying its major features as if you were considering adopting it for your own personal use. You should take detailed notes about your experience as you do this. Once you've gone through every project, decide an a ranking for all of the projects, from 1 to the number of teams in the class, and write a 500 word rationale for your ranking, explaining the qualities that you used to determined your ranking. You'll then submit these assessments to the ranking survey.

To convert the ranking into points, we will determine each team's median rank of all ranks chosen by your individual classmates. Your 2.0 release rank points will then be computed as follows:

quality points = ceiling(5 × (1 - median rank / # teams)) + 5

If your teams median rank was 1 and there were 10 projects, then your points would be 6. If your team's median rank was 8, then your points would be 9.

Think about the implications of this scoring process. These might be the only points standing between you and a 4.0. What will you do to ensure a high ranking by the end of the quarter? You certainly can't bribe everyone in the class. (Well, you can try, but someone will probably tattle). Instead, you'll need to test a lot. Test your application with as many of your classmates as you can! The more feedback you get about your users' experience with your application, and the more you do to address it, the higher your median rank will be. Apply everything you learned in INFO 360 to get quick, targeted, effective feedback, and compete for the high rankings.

The schedule for the 2.0 ranking is as follows:

If you do not submit your rankings by the deadline, you will not receive credit for this portion of your grade!

communication quality (10 points)

Every two weeks (a total of 5 times), your team members will anonymously evaluate your communication skills. This should provide you feedback about how well you're coordinating with your team and, if your score is low, it should prompt you to discuss with your team how your communication might improve.

Each of your teammates will respond to the following two questions:

In the past two weeks, I knew what this teammate was working on:

In the past two weeks, I knew when this teammate expected to finish her/his work:

We will keep track of your teammates' responses to these questions across the quarter (if you have two teammates, you should have 5 × 2 = 10 ratings by the end of the quarter; if you have three teammates, you should have 5 × 3 = 15 ratings). At the end of the quarter, we will determine the median response you received for each question on a 1 to 5 point scale, where "never" is worth 1 and "always" is worth 5. For example, if the median response to the first question was "usually" and the second question was "rarely", you would get 4 points for the first question and 2 points for the second question, for a total of 6 points out of 10.

The TA or I will send out the link to the survey soliciting your responses on a bi-weekly basis. Late or missing submissions will be docked 2 points (since late work is not accepted).

work diary (10 points, due before the final exam period)

The purpose of a work diary is to reflect on your work as you do it, individually, across the whole quarter. The content of a work diary is quite simple, consisting of a timestamped log of thoughts and notes during your work. These thoughts can include problems you're stuck on, issues you're having with your team, stream of consciousness thoughts about your project, reflection about the quality of your work and productivity, and content you've found throughout your process that you've found useful for your work (such as examples).

Work diaries are useful for several things:

What makes a good work diary can depend a lot on your role in your team and your personality. Some will focus more on implementation problems and others will focus more on management. There are no particular requirements about what you write in your diary, as long as it concerns your work in this class.

There are some things that good work diaries have in common. These are the things that your work diary grade will be based on:

how to format and submit

Your work diaries should be private, so you feel free to talk about your teammates or other difficulties you'd rather not share with your teammates (although for most difficulties, you should probably mention them so you can get help, rather than struggle alone). You can keep your diary wherever and in whatever document format you like, but the text itself should be formatted as follows:

	October 14th, 2010
	I Worked in the lab today and accomplished nothing. Partly it was because I was so tired; I didn't sleep at all last night and it's really hurting my productivity. I'm starting to think that it's actually caffeine. I have a latte every afternoon at 4 and just feel wired until 2 am...
	

(Note that this post is borderline reflective: it doesn't really explain the connection between sleep and accomplishing nothing, but it's getting there). At the end of the quarter, you'll submit your diary on Catalyst, where only I will have access to it.

activities (10 points)

In each lecture, we will often apply the concepts in the lectures by engaging in an in-class activity. We will gather your signatures at the end of class to give you credit for participating in these activities. At the end of the quarter, you activity score will be computed as follows

activities score = max(10, round(((# of activities participated in + 3) ÷ total activities) × 10))

This is the proportion of all activities that were run, allowing you to miss up to 3 activities.

readings (10 points, 1 point each, due Wednesdays)

All readings are done individually and will involve reading a section of the required book or another article and writing a response to a prompt. Each reading is worth 1 point, and will be assessed as follows:

These criteria were designed to encourage you not just to read the assigned text, but to get you to think about the relationship between it, your experiences, and other phenomena in the world.

Your reading responses should be posted on the class reading forum. Only reading responses posted by the beginning of class on the due date will be accepted for credit.

tools

Creating software requires a lot of tools. Below are the details about what you'll need.

revision control, issue tracking, wiki

Nearly all of your work this quarter will be submitted to BitBucket, a software project hosting site for storing your code, tracking issues, managing versions, and documenting your progress.

code editors

Another essential tool is a nice HTML/CSS/HTML editor for the implementation work you'll be doing. Whatever editor you choose, I expect you to learn how to use it yourself and lean your classmates if you run into trouble. The TA and I cannot be experts on every editor out there; we'll provide support for the tools we require you to use (namely Trac and Subversion).

Here are a number of editors that have been recommended to me for basic web development:

If you have others you'd like to recommend to your classmates, let me know and I'll broadcast them.

UW web hosting

You'll deploy your projects to one of your teammate's UW student space. LST provides some reasonably clear instructions about how to do this. If you haven't done this before, be sure you try it in advance. (There's nothing worse than rushing the configuration of web technologies, because there's always something you'll overlook when in a hurry!)

academic conduct

The following paragraphs discuss academic integrity, copyright and privacy concerns governing student conduct in the iSchool and the University of Washington. They apply to all assignments and communications in this course.

academic integrity

The essence of academic life revolves around respect not only for the ideas of others, but also their rights to those ideas and their promulgation. It is therefore essential that all of us engaged in the life of the mind take the utmost care that the ideas and expressions of ideas of other people always be appropriately handled, and, where necessary, cited. For writing assignments, when ideas or materials of others are used, they must be cited. The format is not that important as long as it is consistent, the source material can be located and the citation can be verified. In any situation, if you have a question, please feel free to ask the instructor or teaching assistant. Such attention to ideas and acknowledgment of their sources is central not only to academic life, but life in general.

Please acquaint yourself with the University of Washington's resources on academic honesty

copyright

All of the expressions of ideas in this class that are fixed in any tangible medium such as digital and physical documents are protected by copyright law as embodied in title 17 of the United States Code. These expressions include the work product of both: (1) your student colleagues (e.g., any assignments published here in the course environment or statements committed to text in a discussion forum); and, (2) your instructors (e.g., the syllabus, assignments, reading lists, and lectures). Within the constraints of "fair use," you may download or copy slides, recordings or notes for your personal intellectual use in support of your education here in the iSchool. All of these examples are copyrighted expressions, and fair use by you does not include further distribution by any means of copying, performance or presentation beyond the circle of your student colleagues in this class. If you have any questions regarding whether a use to which you wish to put one of these expressions violates the creator's copyright interests, please feel free to ask the instructor for guidance.

privacy

To support an academic environment of rigorous discussion and open expression of personal thoughts and feelings, we, as members of the academic community, must be committed to the inviolate right of privacy of our student and instructor colleagues. As a result, we must forego sharing personally identifiable information about any member of our community including information about the ideas they express, their families, life styles and their political and social affiliations. If you have any questions regarding whether a disclosure you wish to make regarding anyone in this course or in the iSchool community violates that person's privacy interests, please feel free to ask the instructor for guidance.

Knowing violations of these principles of academic conduct, privacy, or copyright may result in University disciplinary action under the Student Code of Conduct.

students with disabilities

To request academic accommodations due to a disability, please contact Disabled Student Services: 448 Schmitz, 206-543-8924 (V/TTY). If you have a letter from DSS indicating that you have a disability which requires academic accommodations, please present the letter to the instructor so you can discuss the accommodations you might need in the class.

Academic accommodations due to disability will not be made unless the student has a letter from DSS specifying the type and nature of accommodations needed.

student code of conduct

Good student conduct is important for maintaining a healthy course environment. Please familiarize yourself with the University of Washington's Student Code of Conduct.