CSE210 - Principles of Software Engineering: Project

Bill Griswold

All project deliverables are due on the Friday of the deliverable week. private Piazza post of PDF is preferred. Please put words "210" and "deliverable" in the subject, as well as the name of the deliverable and your team name.

Software engineering not only embodies a set of key concepts and principles, it also entails a set of skills. Without proficiency in at least some of these skills, you cannot call yourself a software engineer. This course includes a project in order to help you get a taste of these skills as well as experience the key lessons of software engineering first-hand.

Few interesting programs can be built by a single person, so the project for this course is team-oriented. In addition to all the other skills and lessons that are to be conveyed, you will also be learning how to cooperate and communicate effectively.

In this project, you and your teammates will be defining a software product and seeing it through every stage of development. Because of the short span of this class, you are not expected to deliver a marketable product, but the result should be at least a compelling prototype that could serve as the basis for defining a real product or attracting venture capital. :)

You and your teammates have the flexibility--within certain parameters--to choose the product to develop and the features it provides. To provide some "spiritual" guidance, your product should attract the attention of the "Small World Venture Capital" investment fund, which specializes in promoting unusual products that promote a better world through strong communities. They have special interests in software that are targeted to a large group's needs. I will personally function as the Technical Liason of SWVC, and each team will be coming to me to seek guidance about what they can do to have a better chance of attracting additional funding. Each team has considerable autonomy, however, in defining its product and managing its team. For example, you are responsible for choosing a product that is within your means to develop within the alloted time. From time to time I may sense opportunities in the marketplace and suggest small changes to improve your market position. I will consider the possibility of teams developing competing products.

Consistent with the rest of this class, your project is to be conducted in a risk-centric fashion. Everything you do is about minimizing downside risks and maximizing return on up-side risk. Everything you turn in should be justified in terms of addressing a risk.

Here are some places to get inspiration (I can provide further details):

It is not common for projects to be built on existing infrastructures or libraries, or to integrate existing components.

Team and Project Organization

It is highly recommended that each team develop some sort of organizational structure (division of responsibilities, mechanism for making decisions, means for communication) in order to achieve both coherence and effective parallel effort. You may want to go Agile (e.g., Scrum). You may want a team leader; you may want to have a managerial lead and a design lead (cf. the Surgical Team concept from Brooks's Mythical Man Month). You may want to have functional specialization (e.g., design versus testing); you may want to assign one or two people per component; you may want to do Agile software development. You might want to rotate the lead for each deliverable.

You really, really, really should have regular meetings; you should have a mailing list and chat set up, as well as a repository and issue tracker for all project information.

Communication is your biggest risk, since you probably have disparate schedules; this mutates into a coherence/consistency risk, amongst others. You've been warned! :)

Project Schedule and Documents

Your project is going to be managed based on Boehm's Spiral development model. (Scrum is a specific instantiation of the Spiral Model.) This model guides the team through a series of repeated cycles of increasing detail (hence the term spiral). Such a model is necessary in situations where there is significant uncertainty in the product development process. The spiral model allows the delaying of decisions until the cost of making the decision is lower than the cost of not making the decision. In the extended definition of the Spiral model--which is what we are using here--there are five primary steps to each cycle. Each step is focused primarily on the issues identified for the current cycle.

Although each cycle focuses on resolving a certain class of risks, any previously unresolved risks should be monitored for realization or (preferably) elimination. Realization of unresolved risks requires a reprioritization.

For most cycles, there are six primary work products that must be incrementally refined and maintained:

If there were any money involved, there would also be a budget document. You may also want to keep supporting documents such as meeting notes and e-mails.

These work products are repeatedly augmented, refined, and changed. At no time is any document complete, unless the whole project is complete. It is impossible to know the future with certainty--and costly to try--so knowledge is acquired as its cost to acquire it drops below the rising cost of not having it.

Below are the deliverables that denote the major cycles of product development, as somewhat arbitrarily predetermined by me. Do not be misled by the titles on the deliverables. These are not the stages of a waterfall model that transform an input document to an output document. They are spirals that are focused on the resolution of a particular class of risks. The goal, then, it not production of documents, but resolution of risks and the successful production of a final product. The ``product'' is repeatedly (and incrementally) defined and evaluated at increasing levels of detail. You should augment these major cycles with minor cycles as-needed to resolve individual risks, etc.

Also, these deliverables are dates for you to deliver documents to me. It is expected that your actual work precedes the deliverables by quite a bit. My grading of these documents will constitute the ``review and commitment'' parts of the cycle (although normally this would happen in a highly interactive and probing meeting); you are responsible for validation, which is a much more detailed activity than the review for commitment. You should maintain your six work products on the web (accessible to me), and hand in the necessary portions of the products (with change marks, if necessary) for each deliverable.

A deliverable document must have the following form, although in some instances one element or another might not make sense for a given deliverable:

  1. Project name, deliverable name, list of team members in alphabetical order.
  2. Project byline: phrase or sentence reminding what product or goal is
  3. Focus of the document: class of risks to be resolved.
  4. Particular risks identified in previous spirals or at the beginning of this spiral that should be resolved in this spiral.
  5. Resolution of the risks
  6. Critical assessment (analysis, discussion)
  7. Risks remaining and what the plan is for resolving them
  8. Team participation report and attestation
Commentary:

Although a deliverable is normally directed at addressing one class of risks, it potentially addresses all of your risks. What I mean is that, as a rule, a deliverable like the TTP is a "function" that takes in all your risks, and "returns" a new list of modified risks:

R' = M(R)

Or, more accurately, a deliverable takes the current-level product and risks, and refines them both:

(P',R') = M(P,R)

In other words, the Spiral Model is an technique that iteratively and incrementally eliminates (or at least lessens) risks, from big risks to small, from high-level to low level. In the early stages, P is just your deliverable documents and such, but soon it will be ethnographies, designs, code, etc. Conversely, your long list of risks will become progressively smaller, although it might never disappear (bad things can happen after release).

Sections 3, 4, 5, and 6 all concern the same risks. Section 3 is a high-level statement, something like I said about the TTP deliverable in the previous bullet (you can often lift this from my deliverable description). Section 4 lists your specific risks, not the categories (e.g., Failure to communicate quickly and precisely (because we have a large team with incompatible schedules)). Section 5 presents the resolution of each risk (e.g., we're going to use Slack, Google Docs, and meet twice a week). Section 6 discusses your resolution (e.g., together they provide instantaneous communication and a reliable project history and state; they're free and we already know how to use them, etc.)

Section 7 is an exhaustive list of risks that remain (R'). Note that the "plan for resolving them" is a plan on how you will solve them, not the plan that solved them. For example, schedule risk remains (despite adopting Agile development with frequent releases, etc.), and one thing that would help is a software design that enables parallel development. That's what you plan to do, but the software design is yet to come.

Some teams find this parallel structure constraining, because one technology choice will address many risks. For example, Agile addresses both communication risks with the customer (for a bunch of reasons) and delivery risks (specifically due to iterative/incremental development/releases). Having to discuss Agile twice is annoying. There are many ways to solve this problem. The easy way, in this section architecture, is to just mention Agile in section 5 under each relevant risk, and then in section 6 organize the discussion by the resolutions (Agile, Android, etc.) not the risks. So, in section 6, you would discuss Agile, noting along the way which resolutions it addresses (and creates, and how you do or plan to resolve them).

In other words, section 4 is a list of risks addressed, copied from the previous deliverable. Section 5 is, for each risk the list of resolutions for each risk. (Because of this highly parallel structure, you could combine 4 and 5.) Section 6 is organized into a list (or subections) of resolutions, discussing how each resolution resolves risks in section 5 (as well as what risks are added by the resolutions). Section 7 is what's left (and been added), and similar to 4, can be in a tabular form. The "plan" for Risks Remaining is not a risk resolution, but a process for resolving the risks. So your plan might simply be "we'll deal with this in the Testing Deliverable".

The purpose of the team participation report and attestation is to create transparency and accountability for every team member's contribution to a deliverable. It is not expected that every team member contribute the same amount to every deliverable, but rather, on average, over the entire project, that no team member is a free-rider. The document (a) reports each team member's fractional time spent on the deliverable, and (b) is signed by the entire project team. Your fractional effort is calculated as your hours spent on the deliverable, divided by the number of hours spent by the member of your team who spent the most hours on the deliverable. (I don't want to know how many hours were spent.) The fraction should be rounded to the nearest tenth. For example, if Bob, Sally, and Larry each spent 6, 7, and 8 hours on a deliverable, their fractional efforts would be 6/8=0.8, 7/8=0.9, and 8/8=1.0. I recommend that you use Adobe Acrobat's Sign & Certify feature to sign the report. In the event that the team cannot agree on the accounting of the participation, a minority dissenting report may be submitted. The majority report must contain a fraction for each team member, as decided by that majority. A minority report must contain the fractions of the dissenting members, plus any additional member fractions desired by the minority. The team effort report(s) must be submitted (together) as part of the PDF of the deliverable.

All deliverables are for the Friday of the named week. You do not have to wait until the last day to complete the work for a deliverable. I recommend being about a week ahead, when possible.

If you receive a substandard grade on a deliverable, you can turn in a revision the following week for a regrade. Grades will be raised at most one full grade. The last two deliverables, Testing and Final Presentation, cannot be submitted for regrade, because they occur so late in the course. Revisions must be submitted in "redline", showing what you've changed, deleted, and added.

Redline is not hard to do, at least not in Word (instructions are for Window, Word 16):

  1. Click on the "Review" tab
  2. Toggle "Track Changes" if it's not already on
  3. Click the little triangle next to "Show Markup"
  4. Deselect "Formatting" (you'll need to do this every time you open the document, sigh)
  5. If deletions are not shown with red strike-through and insertions in blue underline:
  6. open the Review Panel
  7. click "Advanced"
  8. set the insertion and deletions options at the top as needed

Deliverables

Back to CSE 210 Course Page