CSC444
Software Engineering
Prof. David A. Penny
Lectures Will start at 7:10 pm
Break at 8:00 pm, Resume at 8:10 pm
End at 9:00 pm (or thereabouts!)
Please purchase a book for $40 next week.
Course Website:
http://ccnet.utoronto.ca/20069/csc444h1f
CSC444F'06
Lecture 1
1
Professional Practices
• This course teaches you professional software development
practices not consistently taught anywhere else.
– Deals mostly with process, very little with specs/designs/coding.
– If you have the aptitude and inclination of becoming a professional
software engineer you will find the course fascinating.
• Otherwise I guarantee you will be bored!
• Applying these practices will help you avoid
–
–
–
–
–
–
Missed dates
Poor quality software
Badly-designed features
Poor user documentation
Poor architecture and architectural documentation
Dysfunctional professional relationships between “The Business Side”
and Software Development
• When software is built in a professional fashion in industry, this is
how it is consistently done.
CSC444F'06
Lecture 1
2
About Prof. Penny
•
Graduated B.Sc. in CS UofT 8T5, Ph.D 9T3
– OOT IDE, Polyx, MiniTunis, CE, ...
•
IBM Labs 1992 – 1994
– C++ IDE for AIX
•
Algorithmics 1994 – 1999
– VP Software Development
– RiskWatch > $500M in revenues to-date
•
Consultant 1999 – 2003
– Software management consulting (~10 engagements)
•
UofT CS 2000 – 2003
– Associate Professor
•
Electronics Workbench 2003 – 2005
– VP R&D – Acquired by National Instruments
– MultiSim/UltiBoard/UltiRoute (8MLOC)
•
Ceryx 2005 – present
– CIO
– Provisioning system
CSC444F'06
Lecture 1
3
Lectures
• I wrote a manuscript for you guys:
– Professional Software Development, 2005.
– I will be following it closely
– Tentative Schedule
Lecture
Date
Topics
Chapters
1
Sep 11
Top-10 Practices, Introduction to Planning
1,2
2
Sep 18
Release Planning Overview, Capacity Constraint
3,4
3
Sep 25
Quantitative Capacity Constraint, Sample RP
5,A,C
4
Oct 2
Stochastic Capacity Constraint, Sample SRP
6,B,C
Oct 9
Thanksgiving – no lecture
5
Oct 16
Releases, Versions
7,8
6
Oct 23
MIDTERM
9
7
Oct 30
Build, Testing
10
8
Nov 6
Defect & Feature Tracking
11,12
9
Nov 13
Process Control
13
10
Nov 20
Architectural Clarity
14
11
Nov 27
Business Aspects / Exam Review
15,16
CSC444F'06
Source Control
Lecture 1
4
Grades
• 2 Assignments – 15% each
– A1: Self-Aware Programming (out Sep.25 due Oct.16)
– A2: Release Planning (out Oct.30 due Nov.20)
– Late Policy:
• 15% absolute penalty if handed in <= 1 week late
• Not accepted after that
• Midterm – 30%
– Oct.31, 6-7pm
– Closed book (I want you to study!)
– all lectures and assigned reading up to and including Oct.16th
• Exam – 40%
– Closed book (ditto)
– Covers all lectures, assignments, and assigned reading
CSC444F'06
Lecture 1
5
Course Conduct
• Come to ALL the lectures and come prepared
– You should have read the assigned textbook reading
– You should have thought about it
• Take notes during lectures. Ask questions to clarify material you are
not 100% clear on.
• Review the posted slides afterwards.
• Prepare for the midterm and the examinations by re-reading the text
and the lecture notes. Practice writing the tests
– I will post last year’s midterm and exam for your review purposes
• MAINLY: attend lectures or you will be toast!
• If you do all this it will be an easy course to get a high grade in.
CSC444F'06
Lecture 1
6
Experience
• Need
– Formal education in the computing sciences
– Professional experience
• Build software that lots of people pay money to buy
– Not just “are you paid”
• Make certain decisions for v1 of a product
• Live with your mistakes through v2, v3, v4, ...
• Make fewer mistakes next time around
• We try to fill the gap a bit
– Lessons coming out of extensive professional experience
• Not all professionals agree on what constitute “basic professional
practices”
– Characteristic of an immature industry
– But can agree on the problems we are trying to solve
– One (informed) opinion will be presented here
CSC444F'06
Lecture 1
7
Intended Audience
• Commercial software vendor environment
– Not open source, internal IT, ASP, NASA, ...
• Who
– Individual contributors, Technical leaders, First-line managers, Directors,
VP’s, CTO’s
• Next release
–
–
–
–
Not initial release
“Green fields” is 80% inspiration, 20% process
“Next Release” is 80% process
Next release development is more important to businesses
• Initial release development
– Innovation is clearly also important
– Innovation is less amenable to help from process
– Should set things up to be sustainable
CSC444F'06
Lecture 1
8
New Product Versus Established One
• New product
– 1 yr. to develop
– 3 coders, 1 tester, 1 documenter
– Cost = 1 x 5 x $100,000 = $500,000
• Established Product
–
–
–
–
5 years later
20 coders, 10 testers/build, 5 documenters
Cost to date = $10,000,000
Ongoing cost = $3,500,000 / year
• Improve productivity by 10%
– New product: save $50,000
– Established Product: save $1,000,000 to date, $350,000/year
• Next release development is more economically important.
CSC444F'06
Lecture 1
9
Top-10 Essential Practices
•
•
•
•
Crystallized for me whenever I enter into a new engagement.
If any of these are missing, I know I have something to fix.
These are all important
It will take more than this course to cover them all
• You will agree that all suggestions are sensible and will probably
vow to carry them out
– On your first job, you’ll focus on code and test and forget most of them
– You’ll be bitten in the ass
– You’ll re-commit to the ideas (if you’re good)
• Simple but hard
– Trust me: make sure these things are done and everything will go ok
– Very hard to change behaviour
– Need to be dogged and determined and tricky
CSC444F'06
Lecture 1
10
source code
control
infrastructure
reproducible
builds
defect/feature
tracking
automated
regression
testing
release
control
planning
feature
specifications
refinement
architectural
control
effort
tracking
process
control
business
planning
CSC444F'06
Lecture 1
11
1. Source Code Control
• Central repository
– Everybody knows where to find what they are looking for
– Secure, backed-up storage
• Defines module architectural structure
– hierarchy
• Complete change history
– Can back up and find where problems are first introduced
• Multiple maintenance streams
– Work on next release while maintaining previous releases
• Patches
– Can go back and patch any release in the field
• Enables Team development
• “Interface” to coordinate Dev and QA/Build
• “Guard” against bad changes
CSC444F'06
Lecture 1
12
2. Defect / Feature Tracking
• Keeps track of all defects found or new features desired
– Won’t forget any
• Coordinates a workflow for writing / fixing them
– Won’t skip steps
• Provides management visibility into progress
• Enables effective prioritization
• Enables metrics gathering
CSC444F'06
Lecture 1
13
3. Reproducible Builds
• Check out of source control and one command to build the product
• Required for a consistent experience across all developers,
QA/Build, customers
• Dev builds
– For coding and testing
• Production builds
– Includes creation of install image
– And creation of ISO-Image
– Should also be fully automated
CSC444F'06
Lecture 1
14
4. Automated Regression Testing
• Scripts that run after every QA/Build dev build to test as much
functionality as possible
• Critical to improving software quality
• Prevents errors with previously seen symptoms from recurring
– A very common thing to happen
• Enables coders to change tricky bits with confidence
• Enables finding problems closer to their injection
– Earlier you can find an issue the less costly it is to fix.
• Enables fixing last problems prior to shipping with confidence
– Can release with fewer known defects
– Can release on time
CSC444F'06
Lecture 1
15
5. Release Planning
•
After the previous basics are in place this is the most important practice
– Will spend 1/3 of the course on this
•
Determining
– What goes into the next release
– By when will it will be done
– Using what resources
•
•
Tracking that throughout the release
Adjusting as necessary
•
Enables business side to do their jobs
– Good relationships
•
Enables quality
– By maintaining the test/debug period
•
Provides elbow room
– To improve productivity
CSC444F'06
Lecture 1
16
6. Feature Specifications
• Complicated features require them
– Need to make this determination
• Needed to keep release plan on track
– Better estimates if know what we are doing in more detail
• Enables a better end-user feature
• Eliminates unanticipated integration problems
• Best place to introduce reviews
CSC444F'06
Lecture 1
17
7. Architectural Control
• Must maintain a clean architecture even in the face of
– Many coders working on the code
– Frequent feature additions
• That the software was not designed for initially
– Frequent defect corrections
• By inexperienced coders who do not understand the architecture
• Architectural documentation
• Review of designs and code for conformance
• Chief Architect
• Automated architectural checking tools
CSC444F'06
Lecture 1
18
8. Effort Tracking
• Need to know how much staff time is spent on
– Each new feature
– Correcting defects
– Other
• Can improve estimation accuracy
• Can improve estimates of staff time available for next release
• Can monitor effectiveness of initiatives to free up coder time for
more coding
CSC444F'06
Lecture 1
19
9. Process Control
• Written process for the release cycle
• Gets everybody on the same page
– Can train new staff
• Enables systematic definition / collection of metrics
• Can monitor process for compliance
• Can consider changes to the process from a stable baseline
CSC444F'06
Lecture 1
20
10. Business Planning
• Development occurs within a business context
• If not understood and managed, will sink the project more surely
than technical shortcomings
• Writing effective proposals
• Integrating into the budget cycle.
CSC444F'06
Lecture 1
21
Summary – Top 10 practices
source code
control
infrastructure
reproducible
builds
defect/feature
tracking
automated
regression
testing
release
control
planning
feature
specifications
refinement
architectural
control
effort
tracking
process
control
business
planning
Do all these things, and you’re doing well.
CSC444F'06
Lecture 1
22