1 / 21

CS 5150 Software Engineering Lecture 2

CS 5150 Software Engineering Lecture 2. Software Processes 1. 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. Projects.

layne
Download Presentation

CS 5150 Software Engineering Lecture 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 5150Software EngineeringLecture 2 • Software Processes 1

  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. Projects • Project suggestions continuing to come in • If you have your own project idea send email to Ben & Yue

  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. Software Processes Matter • Cost • Risks • People

  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. 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. 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. 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. 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. Minimizing Risks • Feasibility study • Stakeholder requirements and priorities versus design decisions • Milestones and releases • Acceptance and testing • Handover

  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. 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. 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. 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. 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. 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. Basic Components of All Processes • Feasibility and planning • Requirements and priorities • System and program design • Construction • Acceptance and release • Operation and maintenance

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

  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. Heavy or Light? • Team size • Risk tolerance • Application space maturity

More Related