A Visiting Professor

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

2. Lynchburg College • Hobbs Hall

3. Central Virginia

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

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

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

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

8. The Waterfall Model

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

10. 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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35. Collective Ownership • Any pair as the right to check out any module and improve it • Configuration Management supports this.

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

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

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

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

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

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

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

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

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

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

46. Steering • Update the plan based on what Business and Development learn • Steering Moves: • Iteration • Business picks one iteration worth of the mostvaluable 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.

47. Steering Moves (continued) • New Story • If Business realizes it needs a new story,Business removes stories with equivalent estimates and inserts the newstory. • 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.

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

49. Iteration Planning

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