cs 5150 software engineering lecture 2
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
CS 5150Software
EngineeringLecture 2
Software Processes 1
2CS 5150
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
3CS 5150
Projects
• Project suggestions continuing to come in
• If you have your own project idea send email to Ben & Yue
4CS 5150
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
5CS 5150
Software Processes Matter
• Cost
• Risks
• People
6CS 5150
Software is Different
• Best practices are still changing (relatively) rapidly
• Non-specialists (e.g. most clients) have relatively poor insight into how software works
7CS 5150
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
8CS 5150
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)
9CS 5150
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
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
Minimizing Risks
• Feasibility study
• Stakeholder requirements and priorities versus design decisions
• Milestones and releases
• Acceptance and testing
• Handover
12
CS 5150
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
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
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
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
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
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
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
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
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
Heavy or Light?
• Team size
• Risk tolerance
• Application space maturity