CS 5150 Software Engineering Lecture 2 Software Processes 1

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

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

CS 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 finished program to client

CS Software Processes Matter Cost Risks People

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

CS 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

CS 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)

CS 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?)

CS 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

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

CS 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

CS 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

CS 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

CS 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)

CS 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

CS 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

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

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

CS 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

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