CSC444 Software Engineering

1
CSC444Software Engineering

• Prof. David A. Penny
• Lectures Will start at 710 pm
• Break at 800 pm, Resume at 810 pm
• End at 900 pm (or thereabouts!)
• Please purchase a book for 40 next week.
• Course Website
• http//ccnet.utoronto.ca/20069/csc444h1f

2
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.

3
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 gt 500M in revenues to-date
• Consultant 1999 2003
• Software management consulting (10 engagements)
• UofT CS 2000 2003
• Associate Professor
• Electronics Workbench 2003 2005
• VP RD Acquired by National Instruments
• MultiSim/UltiBoard/UltiRoute (8MLOC)
• Ceryx 2005 present
• CIO
• Provisioning system

4
Lectures

• I wrote a manuscript for you guys
• Professional Software Development, 2005.
• I will be following it closely
• Tentative Schedule

5
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 lt 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

6
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 years 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.

7
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

8
Intended Audience

• Commercial software vendor environment
• Not open source, internal IT, ASP, NASA, ...
• Who
• Individual contributors, Technical leaders,
  First-line managers, Directors, VPs, CTOs
• 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

9
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.

10
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, youll focus on code and test
  and forget most of them
• Youll be bitten in the ass
• Youll re-commit to the ideas (if youre 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

11
source code control
reproducible builds
infrastructure
defect/feature tracking
automated regression testing
control
release planning
feature specifications
architectural control
effort tracking
process control
refinement
business planning
12
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

13
2. Defect / Feature Tracking

• Keeps track of all defects found or new features
  desired
• Wont forget any
• Coordinates a workflow for writing / fixing them
• Wont skip steps
• Provides management visibility into progress
• Enables effective prioritization
• Enables metrics gathering

14
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

15
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

16
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

17
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

18
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

19
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

20
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

21
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.

22
Summary Top 10 practices
source code control
reproducible builds
infrastructure
defect/feature tracking
automated regression testing
control
release planning
feature specifications
architectural control
effort tracking
process control
refinement
business planning

• Do all these things, and youre doing well.