1. 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”

2. 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.

3. 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

4. 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?

5. How hard can it be to do it right?
Standish Group “Chaos” Report

6. Project Success Rate Improvement

7. Problems with Overruns

8. Smaller is Better System Feature Used Frequently 20%
System Features Used Sometimes
30%
System Features Hardly Every Used
50%

9. Factors Identified wit Failure in 1995 Report
Source: Standish Group 1995 Report

10. The Waterfall Model

11. 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

12. Implementation (Coding)
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!

13. 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

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

15. 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.

16. 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.

17. Waterfall is falling out of favor

18. - Discussion of Chapter 1 in Martin and Martin
Extreme Programming

19. Roles Managers Technical Team Leaders Programmers Customers
Database Administrators
Instructors

20. Resumes – please email before 5pm Monday, January 27th
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

21. 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

22. 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

23. Programmers Represent Development in the Planning Game Design
Write Program Code
Write Tests
Refactor
Write performance evaluations

24. 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

25. Project Requirements
Prefer technologies in which you are already competent
Something non-trivial
Something appropriate for one semester
Projects from previous years:
Voting software
Student Schedule Program
Wi-Fi Locator

26. Wifi-Locator
Use the signal strengths of available wi-fi access points to determine location
Inside or outside buildings
Provide the abilities to
Annotate locations
Filter annotations
Location resolution will vary, but some locations might add access points to improve resolution
Museums?
College Buildings?

27. Wi-fi Locator Components
Android Phones
Gather wi-fi signal data
Communicate with a server (cs335)
Java development with Eclipse
Android development
User-interface design
Windows Servers
Analyze and Store Data
Communicate with mobile devices (cs335)
C++ development with Visual Studio

28. 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

29. Manifesto (continued)
That is, while there is value in the items on the right, we value the items on the left more.

30. 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.

31. 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.

32. 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.

33. 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.

34. 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

35. 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

36. 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.

37. 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”

38. 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

39. Critical Components of Extreme Programming
Pair Programming
Test-driven Development (TDD)
Refactoring
Open Workspaces
Customers as team members

40. Pair Programming Two programmers work together Benefits
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

41. Pair Programming (continued)
Change pairs frequently (once per day)
Everyone works on everything

42. 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.

43. 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.

44. 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

45. 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

46. 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.

47. Collective Ownership
Any pair has the right to check out any module and improve it
Configuration Management supports this.

48. The Planning Game
Business and Development play the planning game to determine what to do next.

49. 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.

50. Continuous Integration
Check in code after one or two hour’s work
Don’t integrate large modules all at once

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

52. 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

53. Stories are dynamic. rewritten
broken up into smaller stories if they are too large
combined with other stories if they are too small.
discarded

54. 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

55. Exploration Determine what new things the system might do. Moves
Write a story (Business)
Estimate a story (Development)
Split a story

56. 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
Cost estimates can be precise
Cost estimates can be reasonably precise
Cost estimates cannot be precise

57. 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

58. 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.

59. 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.

60. 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.

61. Iteration Planning

62. The Iteration Planning Game
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

63. Iteration Planning Phases
Exploration Phase
Write a task
Split/combine a task

64. 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

65. 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

66. 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.”

67. 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.”

68. 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.

69. 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)

70. 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

71. 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

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

73. 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.

74. 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.

75. 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

76. Git Software and Tutorial
(tortoise git front-end for Windows)

77. Test-Driven Development

78. 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.

79. 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.

80. 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

81. 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.