CSC321.01 2016S, Class 05: An Introduction to Software Engineering

Overview

Preliminaries

Please sign up for the EdX class at https://edge.edx.org/courses/course-v1:GrinnellCollege+CS321-1-S16a+2016_Spring/about
I've probably planned too much for today.
Reminders
- Attendance is required
- Journals are required (except when they are not assigned)

Track meet on February 6 at 10 a.m. in the "Your name here for only $1M field house".

What was the experience of watching a video?

Confusions

How do we do this in pairs?
- Goal: You work together in class AND outside of class until the problem is completed. You send the completed problem to me.

We saw three methodologies in the reading:
- Plan and Document
  - Waterfall
  - Spiral
- Agile
What are the steps in one "round" of each?
- Waterfall
  - Gather requirements from client
  - Document everything (and get approval from client)
  - Schedule the implementation
  - Implement
  - Test
  - Deploy to client
  - Maintain
- Spiral
  - Determine objectives for this iteration (with client)
  - Evaluate alternatives and risks
  - Develop and verify prototype (with client)
  - Plan again
- Agile (a two week sprint)
  - Talk to client
  - Plan (key tasks; assign people)
  - Write tests
  - Develop stuff
  - Show to client
How are they similar?
- Both produce code
- Both spiral and agile assume that you will do multiple cycles so you don't have to do everything at once
- It's software design; everything takes too long
How do they differ?
- Very different iteration lengths (agile one or two weeks; spiral a few months; waterfall: a year or more)
- Involvement of client (more involvement in agile); more human interaction (also in terms of pair programming and such)
- Granularity of planning
- Agile seems to work better if you're a small f2f group; because it relies on interpersonal communication, things break down in situations in which such communication is harder

Why don't people like agile?

It's new. We've always done it one way. It must be the way.
Who wants to deal with people?
Doesn't meet some situations, such as programs whose requirements are unlikely to change. (E.g., NASA)
Can be hard for developers who like a stable situation.
Anyone who believes that software engineering is really engineering.
May be easier to join a project with lots of documentation.
Tests are not good specs. Math gives us more confidence that things are correct.

These days, most medium projects show great benefit from agile, and it keeps modern programmers happier.

What are the key agile practices?

User stories - Client requirements in a particular form
Small teams
Tests and stories as documentation
Small tasks
Short iterations
Pair programming
Stand up meetings - discuss what has been accomplished and obstacles (usually standing, so they are fast)
Focus on "working" software and then building on it
Standards
TDD
Emphasis on constant refactoring