Intro to Software Engineering

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 • https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

6. Project Success Rate Improvement

7. Problems with Overruns

8. Smaller is Better

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

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 http://en.wikipedia.org/wiki/Voting_system • Student Schedule Program • Wi-Fi Locator

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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