A Visiting Professor

Randy Ribler – Lynchburg College PhD from Virginia Tech Postdoc at University of Illinois (UIUC) Many years of industry experience

building systems ribler@lynchburg.edu

I was here before in 2006 I’m absolutely delighted to be back

in 2013

Lynchburg College

Hobbs Hall

Central Virginia

Intro to Software Engineering

How do we build big systems? How do people work together best? How can we prevent project failure?

Failure rates are debatable, but undeniably too high

How should individual programmers do their jobs?

What are “best practices”

SE is unlike other subfields of Computer Science

Fewer things are provable Hard/Impossible to repeat anything

Every situation is a different Projects are different Staff is different Tools are different Customers are different

SE has been wrong before Conventional wisdom has changed

radically in the last several years.

Software Engineering has Value Structured Programming Object-oriented Programming Design Patterns Configuration Management Pair Programming Test-driven Development Refactoring A number of software process models Coding Standards Tools

What if everyone just codes?

Chaos! No agreement on exactly what the

system must do No comprehensive high-level design Difficult coordination between team

members▪ How do we know what we should be working

on ? What happens if someone leaves? How do we bring all the pieces together?

The Waterfall Model

Phases of the waterfall – each phase must be completed before moving to the next

Requirements Determine exactly what the system must do.

Generally, say nothing about how it does it. A requirements specification document is produced.

System Design High-level design breaks the system in to pieces

(modules)▪ Describe how each of the pieces work and communicate.

Low-level design▪ Write pseudo-code for all the modules

Design documents are produced

Phases of the waterfall – each phase must be completed before moving to the next

Implementation (Coding) Typically cited as expected to take 10-

15% of project time. Testing

Unit testing Integration Testing

Deployment Deliver the system to the customer▪ Sometimes this is the first time the customer

has seen the system work!

Phases of the waterfall – each phase must be completed before moving to the next

Maintenance Debug problems Make Enhancements This phase is acknowledged to be the

most expensive

Expensive backtracking when errors are found – the further back we go, the more expensive the fix

Good Qualities of Waterfall Follows other engineering disciplines –

“Have a blueprint before you build anything”

The entire system is planned from the beginning, allowing design to be comprehensive.

The customer is told what they will get from the beginning Good for contracts, at least on the surface

Module breakdown provides parallelism of effort.

Problems with the Waterfall The less sure we are about what we want

the more expensive it will be What happens if the project is cancelled

before deployment? How do we keep all the documents

consistent? How do we know that the system will solve

the user’s problem? How do we know how long things will take? It is unclear how effective it is.

Extreme Programming- Discussion of Chapter 1 in Martin and Martin

Manifesto for Agile Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over

processes and tools Working software over comprehensive

documentation Customer collaboration over contract

negotiation Responding to change over following

a plan

Manifesto (continued)

That is, while there is value in the items on the right, we value the items on the left more.

XP Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

XP Principles (contined)

Businesspeople and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

XP Principles (continued) Working software is the primary measure of

progress. Agile processes promote sustainable

development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity – the art of maximizing the amount of work not done – is essential.

XP Principles (continued)

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Software Development Extreme Programming

Relatively new software development process Very clearly defined roles for the development team

(Development) and the management team (Business)

Extreme Programming Explained – Embrace Change▪ Kent Beck, 2000, 2005

An incremental software development process One of a family of “agile” development processes Less formal specification and design

Stories

In XP, user requirements are expressed as stories

Stories are determined in meetings between customers and developers

Sample Stories: A user logs into the system A user makes a deposit to their account

Stories are recorded on index cards Developers estimate the work required to

implement a story

Frequent Releases

A release is software that is delivered to the customer In extreme programming (XP), releases are made

frequently. (approximately every 3 months) Releases consist of working code, but they are

usually snapshots of works in progress. Releases allow the customer to see how the

system is developing and react to problems at early stages (provide feedback)

The customer determines which stories are included in the release, constrained by a budget determined by the previous release.

Iterations

Releases are implemented through a series of iterations.

Iterations produce working software demonstrated every 1-2 weeks to get user feedback

Iteration Plan Collection of stories meeting a budget

established by developers Budget is determined by progress made

during the previous iteration Stories are broken up into “tasks”

Acceptance Tests

Details of user stories specified by the customer

The virtual requirements document Everyone can read and understand

these tests Once a test passes, it should never

be allowed to break for more than a few hours

Critical Components of Extreme Programming

Pair Programming Test-driven Development (TDD) Refactoring Open Workspaces Customers as team members

Pair Programming

Two programmers work together One types One watches for errors, makes suggestions, helps Occasionally switch roles

Benefits Fewer bugs initially Two heads are better than one Information and Ownership Sharing▪ Both programmers understand this code well

Information Transfer▪ Learn techniques from each other▪ Learn about all parts of the system

Isn’t this more expensive? It doesn’t seem to be

Pair Programming (continued)

Change pairs frequently (once per day)

Everyone works on everything

Refactoring

Improve code without changing its function Contrary to “if it works don’t fix it”▪ “If it works, make it better”

Make a series of small transformations to make the code better.

Verify the you have not broken the code A unified design can emerge.

Test-Driven Development (TDD) All production code is written to make

a failing test pass. Loop▪ Write a failing test▪ Make the test pass▪ Refactor

Result▪ All production code has unit tests available

from the start.▪ Refactoring can be done with confidence as

tests exist to verify correctness.

Overtime

The team is not allowed to work overtime, other than during the last week of a release

Overtime is viewed as borrowing time from the future, with the interest being a dramatic reduction in quality

Open Workspace (War Room)

Programmers do not work in private offices

Everyone works together in one big room Better communication Less reliance of formal meetings

XP Philosophies

Consider the simplest thing that could possibly work

You aren’t going to need what you think you will need

Reject duplication of code.

Collective Ownership

Any pair as the right to check out any module and improve it Configuration Management supports

this.

The Planning Game

Business and Development play the planning game to determine what to do next.

Stories

Each system feature is broken down to 1 or more user "stories.”

e. g., “a student drops a course,” “a user logs in,” “the system is asked to find a specific course that fits in a given schedule.”

Continuous Integration

Check in code after one or two hour’s work

Don’t integrate large modules all at once

Stories on Index Cards

Stories are written on index cards▪ just enough to remember what they are. ▪ We don’t want lots of details.

Index card contents

name of the story date brief description of story number of "points" the story requires

(cost) ▪ estimates are not in hours, they are in points

that have a consistent value Notes Anything helpful

Stories are dynamic.

rewritten broken up into smaller stories if they are

too large combined with other stories if they are

too small. discarded

Three Phases of Planning Game

Phases are cyclical - you will move back and forth between the phases during the course of the game. Exploration▪ Determine what new things the system might do.

Commitment ▪ Decide what subset of all possible requirements

to purse next Steering▪ Update the plan based on what Business and

Development learn

Exploration

Determine what new things the system

might do. Moves▪ Write a story (Business)▪ Estimate a story (Development)▪ Split a story

Commitment

Decide what subset of all possible requirements to purse next. Moves ▪ Business Sorts by Value▪ Three piles

Essential Significant business value Nice to have

▪ Development Sorts by Risk▪ Three piles

Cost estimates can be precise Cost estimates can be reasonably precise Cost estimates cannot be precise

Commitment Moves (continued)

Set Velocity Development tells Business how fast the

team can work.

Choose Scope Business chooses the set of cards that

will be included in the release

Steering

Update the plan based on what Business and Development learn Steering Moves: ▪ Iteration▪ Business picks one iteration worth of the most

valuable stories to be implemented.

▪ Recovery ▪ If Development realizes that it has overestimated its

velocity, it can ask Business to specify a smaller subset of the current stories.

Steering Moves (continued)

New Story If Business realizes it needs a new story,

Business removes stories with equivalent estimates and inserts the new story.

Reestimate If Development feels that the plan no

longer provides an accurate map of development, it can re-estimate all of the remaining stories and set velocity again.

Steering Moves (continued)

Velocity The number of story points we complete each

iteration is our "velocity." Our next iteration will use our current velocity

for determining the number of points we can commit to for the next iteration.

Release Planning Given velocity, Business gets good estimates of

the cost of features Managers use both cost and priority to schedule

the development sequence of features.

Iteration Planning

Players are just the programmers No management

Stories are broken in tasks Tasks are recorded on index cards

Programmers accept responsibility for tasks

Programmers estimate the time required for each task (perfect programming days/hours)

Programmers test and implement tasks using pair programming

The Iteration Planning Game

Exploration Phase Write a task Split/combine a task

Iteration Planning Phases

Commitment Phase Accept a task▪ Programmer volunteers to accept responsibility for a

task▪ Estimate a task▪ The programmer who has accepted responsibility for a task

estimates the time required to complete it (usually in perfect days or perfect programming hours)

▪ Set load factors▪ What percentage of the available time will you work on your

tasks?

▪ Balancing▪ Determine how well the available time matches the estimated

task time for each individual – redistribute as necessary

Iteration Planning Phases

Steering Phase Implement a task▪ Use pair programming▪ Use test-driven development

Record Progress Keep track how much time has been spent on each

task Recovery

Reduce task scope of task/story Remove non-essential tasks Get more/better help Ask customer to defer some stories

Iteration Planning Phases

Test-Driven Development (TDD)

Loop▪ Write a failing test▪ Make the test pass▪ Refactor

Most development environments now have direct support for TDD▪ NUnit is one of the most popular tools for TDD▪ Microsoft Visual Studio supports a number of

TDD tools, as does Eclipse▪ Both environments support versions of Nunit

TDD in Visual Studio 2012

Using Nunit Create a TestClass with the attribute

[TestFixture]

[TestFixture]class chessClassTests{}

Using NUnit

Add a reference to NUnit References | Manage NuGet Packages Search for NUnit Install

Add “using NUnit.Framework;” to your test files.

Under Tests | Test Settings Select “Run Tests After Build”