CS 5150 Software Engineering Lecture 2 Software Processes 1

advertisement
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
•
•
•
•
CS 5150
Team name
Names of team members
Client info
Project topic
2
Projects
•
•
CS 5150
Project suggestions continuing to come in
If you have your own project idea send email to Ben &
Yue
3
What is a Software Process?
•
•
CS 5150
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
4
Software Processes Matter
•
•
•
CS 5150
Cost
Risks
People
5
Software is Different
•
•
CS 5150
Best practices are still changing (relatively)
rapidly
Non-specialists (e.g. most clients) have
relatively poor insight into how software works
6
Risks
•
•
Most software projects have major problems
•
•
•
Over budget (cost)
Late delivery (time)
Lots of code is wasted (perhaps 50% never
used)
•
•
•
CS 5150
Does not work as expected (functionality)
Does the wrong thing
Poor interface
No one cares
7
The Three-way Trade-off
•
•
CS 5150
The terrible triangle
•
•
•
Functionality (scope of project)
Cost (developer time & other resources)
Time (delivery date)
Force clients to make choices
•
(without being a jerk)
8
Client’s Risks
•
Understand risks from the client’s perspective
•
•
•
•
CS 5150
Late (cancelation of some related project?)
Over budget (middle manager gets fired?)
Insufficient functionality (competitor
dominates market?)
Full of bugs (plane crashes?)
9
First Major Hurdle: Communication
•
•
Most failed software projects fail because the
leaders didn’t plan the right software
Listen to the client!
•
•
•
•
CS 5150
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
10
Minimizing Risks
•
•
•
•
•
CS 5150
Feasibility study
Stakeholder requirements and priorities versus
design decisions
Milestones and releases
Acceptance and testing
Handover
11
A Popular Strategy: Short Cycles
•
•
CS 5150
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
12
Visibility and Accountability
•
•
•
CS 5150
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
13
Teams
•
•
Most software is built by teams
•
Effectively all software is built on other
software
•
•
•
CS 5150
Overall team efficiency is the critical metric
Indirect collaboration with other
programmers
Practical limit on team size is fairly small
Collaboration between teams requires more
planning
14
Observations about Big Projects
•
Big software represents thousands to millions
of person-years of effort
•
•
•
CS 5150
•
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)
15
Fundamental Assumptions
•
•
•
•
CS 5150
Good processes reduce risk
Good processes enhance visibility
Good processes increase probability of project
success
Systematic testing is the key to all processes
16
Different Strokes for Different Folks
•
•
•
•
•
•
CS 5150
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
17
Basic Components of All Processes
•
•
•
•
•
•
CS 5150
Feasibility and planning
Requirements and priorities
System and program design
Construction
Acceptance and release
Operation and maintenance
18
Testing is Part of Every Phase
•
•
•
•
•
•
•
CS 5150
Stakeholder review of plans
Usability prototyping
Design review
Automated testing
Code review
Manual testing
Acceptance testing
19
Heavy vs Light: the Main Process Axis
•
Heavy: Methodically (and slowly) work through
the complete development cycle
•
•
•
Example: Modified Waterfall Model
Light: Incrementally work through (parts of) the
development cycle quickly
•
•
CS 5150
Might have 100s of pages of design
documents before the first line of code is
written
Many web applications are run this way
Example: Agile Software Development
20
Heavy or Light?
•
•
•
CS 5150
Team size
Risk tolerance
Application space maturity
21
Download