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

_Overview_

* Preliminaries.
    * Admin.
    * Upcoming Work.
    * Extra Credit.
    * Questions.
* The Semi-Flipped Classroom.
* Software Engineering: An Overview.
* Thoughts from the Readings.
* User Stories.
* User Stories Applied.

Preliminaries
-------------

### Admin

* 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)

### Upcoming Work

* NO READING JOURNAL FOR FRIDAY.
* No need to do quizzes etc. on EdX site.
* For Friday: SaaSbook chapter 3 (or corresponding videos on EdX site).
* For Friday: Hartl chapter 4 (which has almost no programming)
* In class Friday: Finish the chapter 3 project.

### Good Things to Do

#### Academic

* CS Extras Thursday in 3813.  (LaTeX)
* ACM Chapter Meeting after CS extras.
* CS Table Tuesday.  (Bowie, Mickey, and ...)
* Various internship workshops

#### Peer

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

### Questions

The Semi-Flipped Classroom
--------------------------

What was the experience of watching a video?

* Speeding up and reading along was nice.

* Using a xMOOC as one of our resources
* Using online tutorials as primary resources
* Mostly without too much front-of-the-room chatter

* We are doing this in part to help you think about different ways of
  learning.

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.

Software Engineering: An Overview
---------------------------------

* 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

Outcomes

* Improvisation - Ability to respond to problems as they come up
* Easy to fix problems

Thoughts from the Readings
--------------------------

User Stories
------------

User Stories Applied
--------------------

