![Page 1: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/1.jpg)
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”
![Page 2: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/2.jpg)
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.
![Page 3: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/3.jpg)
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
![Page 4: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/4.jpg)
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?
![Page 5: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/5.jpg)
How hard can it be to do it right?
Standish Group “Chaos” Report http://
versionone.com/assets/img/files/ChaosManifesto2013.pdf
![Page 6: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/6.jpg)
Project Success Rate Improvement
![Page 7: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/7.jpg)
Problems with Overruns
![Page 8: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/8.jpg)
Smaller is Better
System Feature Used Frequently
20%
System Features Used Sometimes 30%
System Features Hardly Every Used
50%
![Page 9: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/9.jpg)
Factors Identified wit Failure in 1995 Report
Source: Standish Group 1995 Report
![Page 10: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/10.jpg)
The Waterfall Model
![Page 11: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/11.jpg)
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
![Page 12: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/12.jpg)
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!
![Page 13: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/13.jpg)
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
![Page 14: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/14.jpg)
Expensive backtracking when errors are found – the further back we go, the more expensive the fix
![Page 15: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/15.jpg)
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.
![Page 16: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/16.jpg)
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.
![Page 17: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/17.jpg)
Waterfall is falling out of favor
![Page 18: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/18.jpg)
Extreme Programming- Discussion of Chapter 1 in Martin and Martin
![Page 19: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/19.jpg)
Roles
Managers Technical Team Leaders Programmers Customers Database Administrators Instructors
![Page 20: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/20.jpg)
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
![Page 21: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/21.jpg)
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
![Page 22: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/22.jpg)
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
![Page 23: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/23.jpg)
Programmers
Represent Development in the Planning Game
Design Write Program Code Write Tests Refactor Write performance evaluations
![Page 24: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/24.jpg)
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
![Page 25: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/25.jpg)
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
![Page 26: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/26.jpg)
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?
![Page 27: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/27.jpg)
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
![Page 28: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/28.jpg)
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
![Page 29: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/29.jpg)
Manifesto (continued)
That is, while there is value in the items on the right, we value the items on the left more.
![Page 30: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/30.jpg)
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.
![Page 31: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/31.jpg)
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.
![Page 32: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/32.jpg)
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.
![Page 33: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/33.jpg)
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.
![Page 34: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/34.jpg)
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
![Page 35: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/35.jpg)
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
![Page 36: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/36.jpg)
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.
![Page 37: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/37.jpg)
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”
![Page 38: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/38.jpg)
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
![Page 39: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/39.jpg)
Critical Components of Extreme Programming
Pair Programming Test-driven Development (TDD) Refactoring Open Workspaces Customers as team members
![Page 40: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/40.jpg)
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
![Page 41: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/41.jpg)
Pair Programming (continued)
Change pairs frequently (once per day)
Everyone works on everything
![Page 42: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/42.jpg)
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.
![Page 43: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/43.jpg)
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.
![Page 44: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/44.jpg)
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
![Page 45: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/45.jpg)
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
![Page 46: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/46.jpg)
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.
![Page 47: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/47.jpg)
Collective Ownership
Any pair has the right to check out any module and improve it Configuration Management supports
this.
![Page 48: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/48.jpg)
The Planning Game
Business and Development play the planning game to determine what to do next.
![Page 49: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/49.jpg)
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.
![Page 50: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/50.jpg)
Continuous Integration
Check in code after one or two hour’s work
Don’t integrate large modules all at once
![Page 51: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/51.jpg)
Stories on Index Cards
Stories are written on index cards▪ just enough to remember what they are. ▪ We don’t want lots of details.
![Page 52: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/52.jpg)
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
![Page 53: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/53.jpg)
Stories are dynamic.
rewritten broken up into smaller stories if they are
too large combined with other stories if they are
too small. discarded
![Page 54: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/54.jpg)
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
![Page 55: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/55.jpg)
Exploration
Determine what new things the system
might do. Moves▪ Write a story (Business)▪ Estimate a story (Development)▪ Split a story
![Page 56: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/56.jpg)
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
![Page 57: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/57.jpg)
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
![Page 58: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/58.jpg)
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.
![Page 59: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/59.jpg)
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.
![Page 60: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/60.jpg)
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.
![Page 61: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/61.jpg)
Iteration Planning
![Page 62: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/62.jpg)
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
![Page 63: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/63.jpg)
Exploration Phase Write a task Split/combine a task
Iteration Planning Phases
![Page 64: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/64.jpg)
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
![Page 65: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/65.jpg)
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
![Page 66: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/66.jpg)
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.”
![Page 67: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/67.jpg)
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.”
![Page 68: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/68.jpg)
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.
![Page 69: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/69.jpg)
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)
![Page 70: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/70.jpg)
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
![Page 71: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/71.jpg)
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
![Page 72: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/72.jpg)
Update
Update the files in your local directory to reflect changes committed since you last checked out (or updated).
![Page 73: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/73.jpg)
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.
![Page 74: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/74.jpg)
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.
![Page 75: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/75.jpg)
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
![Page 76: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/76.jpg)
Git Software and Tutorial
"http://gitimmersion.com (tutorial) https://code.google.com/p/tortoisegit
/ (tortoise git front-end for Windows)
![Page 77: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/77.jpg)
Test-Driven Development
![Page 78: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/78.jpg)
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.
![Page 79: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/79.jpg)
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.
![Page 80: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/80.jpg)
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
![Page 81: How do we build big systems? How do people work together best? How can we prevent project failure? Failure rates are debatable, but undeniably](https://reader035.vdocument.in/reader035/viewer/2022062516/56649e035503460f94aef270/html5/thumbnails/81.jpg)
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.