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?

How hard can it be to do it right? Standish Group “Chaos” Report https://

www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

Project Success Rate Improvement

Problems with Overruns

Smaller is Better

System Feature Used Frequently

20%

System Features Used Sometimes 30%System Features Hardly Every Used

50%

Factors Identified wit Failure in 1995 Report

Source: Standish Group 1995 Report

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.

Waterfall is falling out of favor

Extreme Programming- Discussion of Chapter 1 in Martin and Martin

Roles

Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Resumes – please email ASAP

Everyone needs to submit an informal resume List of CS courses taken Expected graduation date Interested in leadership position (yes/no) Interested in being a manager (yes/no) Programming skills:▪ Languages▪ Windows Programming▪ Networks▪ Databases

Managers

Provide direction What are we going to do? Based on customer/market needs Manage personnel Keep the team productive Work with customers to determine

needs Write performance evaluations

Team Leaders

Provide technical leadership Principal Advisor to management Provides technical assistance to

team members Makes important design decisions Represent Development in the

Planning Game along with the rest of the development team

Write performance evaluations

Programmers

Represent Development in the Planning Game

Design Write Program Code Write Tests Refactor Write performance evaluations

Customers

Determine which features get built and and decide when the get built

Evaluate releases and provide feedback

Approve acceptance tests Provide domain expertise Write performance evaluations

Project Requirements

Prefer technologies in which you are already competent

Something non-trivial Something appropriate for one

semester Projects from previous years:

Voting software http://en.wikipedia.org/wiki/Voting_system

Student Schedule Program Wi-Fi Locator

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 that 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 has 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., “As a student, I want to drop a course,” “as a user, I want to log in,” “as a student of faculty member, I want to find a specific course that fits in a given schedule so that I can add it.” A useful template for user stories is:▪ As a <role> I want to <do something> [so that

…], where [so that …] is optional.▪ Other templates and forms are fine too.

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

Software Development Catastrophes

“We accidentally delete all the software” Disks crashed – no backups

“We changed something and the system doesn’t work any more, but we don’t remember what we changed.”

“Our users are reporting a problem with version 2.5, but we can’t repeat it because we only have version 5.6.”

Problems working with others “Somebody overwrote the changes I

made to a function when they made their changes to the same function.”

“My functions worked fine last Tuesday, but today the don’t work at all. What changed since Tuesday?”

“We made a mistake when we decided to change the algorithm. We need to go back to what we had before we made the change.”

Configuration Managment Configuration Management Provides

A repository for all code and software development artifacts

Configuration Management Systems record all changes that are made to the system.

Configuration Management Systems allow “snapshots” of the system to be given names (labels) that make it easy for them to be recalled.

Configuration Management Concepts

A “repository” holds all the code and system artifacts. The repository is usually hosted on a

server that is easily accessible to the whole team.

The repository is maintained by a Configuration Management System▪ CVS (Concurrent Versions System)▪ SVN (Subversion)▪ Git (Linus Torvalds)

Local copies of the code

Individual programmers “check out” code from the repository, making copies of the repository files on the local machine.

Programmers modify and test changes to the code on the local machine

Staging Changes (Git)

When programmers are happy with the changes they have made, they “stage” the changed files to flag them as ready to be written back to the repository

Update

Update the files in your local directory to reflect changes committed since you last checked out (or updated).

Committing Changes

When programmers “commit” their changes, their staged files are written to the repository. Typically the programmers will provide a

comment or two to the configuration management system describing the changes.

Other programmers might have committed other changes to the same files. In that case a “merge” must be performed before the commit. Most merges can be performed automatically.

Typical checkout, commit cycles should typically be a few hours.

Checkout at start of work session Make a small improvement Test that nothing is broken Commit your changes

The longer the code is checked-out, the more likely commits will require merging.

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

Git Software and Tutorial "http://gitimmersion.com (tutorial) https://code.google.com/p/tortoisegit

/ (tortoise git front-end for Windows)

Test-Driven Development

Three Rules

Don’t write any production code until you have written a failing unit test.

Don’t write more of a unit test than is sufficient to fail or fail to compile

Don’t write any more production code than is sufficient to pass the failing test.

Advantages All program functions are testable and have

tests that verify their operation. We can tell when we break something. We see the function from the caller’s point of

view. The function will be “conveniently callable.”

Because the function is callable, we have decoupled it from other system software – e.g., the user interface.

Test provides documentation in the form of a working example.

Using NUnit

Download NUnit http://www.nunit.org/index.php?p=download

Use NuGet to get the NUnit and NUnit test adapters

Add a reference to Nunit to your project Add “using NUnit.Framework;” to your

test files. Under Test | Windows, select Test

Explorer

TDD in Visual Studio 2012 Using Nunit Create a TestClass with the attribute

[TestFixture]

[TestFixture]class chessClassTests{} Use [SetUp] for code that should be

executed before each test.