21
Software Engineering Lecture 2 Software Processes 1

CS 5150 Software Engineering Lecture 2 Software Processes 1

Embed Size (px)

Citation preview

Page 1: CS 5150 Software Engineering Lecture 2 Software Processes 1

CS 5150Software

EngineeringLecture 2

Software Processes 1

Page 2: CS 5150 Software Engineering Lecture 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

Page 3: CS 5150 Software Engineering Lecture 2 Software Processes 1

3CS 5150

Projects

• Project suggestions continuing to come in

• If you have your own project idea send email to Ben & Yue

Page 4: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 5: CS 5150 Software Engineering Lecture 2 Software Processes 1

5CS 5150

Software Processes Matter

• Cost

• Risks

• People

Page 6: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 7: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 8: CS 5150 Software Engineering Lecture 2 Software Processes 1

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)

Page 9: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 10: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 11: CS 5150 Software Engineering Lecture 2 Software Processes 1

11

CS 5150

Minimizing Risks

• Feasibility study

• Stakeholder requirements and priorities versus design decisions

• Milestones and releases

• Acceptance and testing

• Handover

Page 12: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 13: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 14: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 15: CS 5150 Software Engineering Lecture 2 Software Processes 1

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)

Page 16: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 17: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 18: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 19: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 20: CS 5150 Software Engineering Lecture 2 Software Processes 1

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

Page 21: CS 5150 Software Engineering Lecture 2 Software Processes 1

21

CS 5150

Heavy or Light?

• Team size

• Risk tolerance

• Application space maturity