1. CS 5150 Software Engineering Lecture 2 Software Processes 1

2. CS 5150 2 Project Teams It’s okay if you don’t have a team yet Piazza activated Send email to Ben & Yue when you have (most of) a team Team name Names of team members Client info Project topic

3. CS 5150 3 Projects Project suggestions continuing to come in If you have your own project idea send email to Ben & Yue

4. CS 5150 4 What is a Software Process? More or less formal rules for organizing work on software Trivial example: Meeting with client Meeting with team Code code code Test Email finished program to client

5. CS 5150 5 Software Processes Matter Cost Risks People

6. CS 5150 6 Software is Different Best practices are still changing (relatively) rapidly Non-specialists (e.g. most clients) have relatively poor insight into how software works

7. CS 5150 7 Risks Most software projects have major problems Does not work as expected (functionality) Over budget (cost) Late delivery (time) Lots of code is wasted (perhaps 50% never used) Does the wrong thing Poor interface No one cares

8. CS 5150 8 The Three-way Trade-off The terrible triangle Functionality (scope of project) Cost (developer time & other resources) Time (delivery date) Force clients to make choices (without being a jerk)

9. CS 5150 9 Client’s Risks Understand risks from the client’s perspective Late (cancelation of some related project?) Over budget (middle manager gets fired?) Insufficient functionality (competitor dominates market?) Full of bugs (plane crashes?)

10. CS 5150 10 First Major Hurdle: Communication Most failed software projects fail because the leaders didn’t plan the right software Listen to the client! The client is not always right The client must be satisfied at the end of the day Tight communication feedback loops Expertise and a nose for exceptions

11. CS 5150 11 Minimizing Risks Feasibility study Stakeholder requirements and priorities versus design decisions Milestones and releases Acceptance and testing Handover

12. CS 5150 12 A Popular Strategy: Short Cycles Minimize risk with short development cycles New pieces of working software every week or two (not months) Many opportunities to change course This is one of the fundamental pieces of the Agile development method

13. CS 5150 13 Visibility and Accountability Managers and clients want to know the status of in-progress software Must rely on reporting by developers Developers Often have trouble reporting progress Are usually optimistic Dislike reporting Frequent releases and accepted processes

14. CS 5150 14 Teams Most software is built by teams Overall team efficiency is the critical metric Effectively all software is built on other software Indirect collaboration with other programmers Practical limit on team size is fairly small Collaboration between teams requires more planning

15. CS 5150 15 Observations about Big Projects Big software represents thousands to millions of person-years of effort Every project that is sufficiently successful will have significant developer turnover... and changes in requirements and priorities No large project is every complete Our projects About 0.3 person-years (a single sprint)

16. CS 5150 16 Fundamental Assumptions Good processes reduce risk Good processes enhance visibility Good processes increase probability of project success Systematic testing is the key to all processes

17. CS 5150 17 Different Strokes for Different Folks Safety critical systems => more reliability testing Shrink-wrap software => more usability testing Systems/frameworks => more robustness testing Contract software => more emphasis on core requirements No standard process BUT there are common principles

18. CS 5150 18 Basic Components of All Processes Feasibility and planning Requirements and priorities System and program design Construction Acceptance and release Operation and maintenance

19. CS 5150 19 Testing is Part of Every Phase Stakeholder review of plans Usability prototyping Design review Automated testing Code review Manual testing Acceptance testing

20. CS 5150 20 Heavy vs Light: the Main Process Axis Heavy: Methodically (and slowly) work through the complete development cycle Might have 100s of pages of design documents before the first line of code is written Example: Modified Waterfall Model Light: Incrementally work through (parts of) the development cycle quickly Many web applications are run this way Example: Agile Software Development

21. CS 5150 21 Heavy or Light? Team size Risk tolerance Application space maturity