Software Engineering

Lab Session
Session 1 – Introduction to the
practicum

© Jorge Aranda, 2005

Overview
 What is it about?

 Why are we doing this?

 How to get a good grade

 The Personal Software Process

 Assignment 1
What is it about?
 Based on Watts Humphrey’s Personal
Software Process
 Outlined in A Discipline for Software
Engineering
 You should have finished reading Chapters 1-4
already!

 Six relatively easy programming assignments

 On C
 Focus on learning and understanding the process
 Assignments map to Humphrey’s 1A-6A exercises
What is it about?
 You’ll be submitting one assignment per
week
 Except on Thanksgiving and the midterm week
 There’ll also be weekly reading assignments

 The process will be increasingly elaborated

as we go along…
Why are we doing this?
 Hardly surprising facts:
 1 – Most software projects go wrong
 2 – Most software projects do not follow *any*
development process
 3 – Software projects that do follow some
process have a much better chance of survival
 It really can be almost any process
 Extreme Programming and other Agile styles
 Cleanroom
 Capability Maturity Model (CMM)
Why are we doing this?
 But software engineers are frequently too busy to
learn software processes

 The best time for you to learn them is now

 We chose the Personal Software Process (PSP)

 Will help you think about software development in a
disciplined way
 Will help you to know your own strengths and
weaknesses, and to improve them
 It’s a personal activity, but it can be extended to teams
and organizations
 It’ll look good on your resume
Why are we doing this?
 Think about the term ‘Software Engineer’

 What defines an engineer?

 What do engineers measure/control/plan?

 Do software developers really do engineering?

Why are we doing this?
 Software engineering:
 Management of resources
 Main resource is the engineer’s own time and what
she does with it!
 Estimation
 Progress tracking
 Quality Assurance
 Defects injected into product
 Conformance of product to requirements
Why are we doing this?
 Would you be able to respond accurately to these
questions?
 On average, how many defects do you inject in the code you
write (per 1,000 lines of code)?

 How many of those defects are coding errors, and how many
are design or requirements errors?

 What percentage of your time goes into coding? What

percentage goes into fixing defects?

 How many lines of code have you written in the past year?
How many classes, methods or routines? Of what kind?

 By what percentage are your estimates normally off?

 Developers are all different –what are your weaknesses and

strengths as a developer? (Fast coder, high quality, good
architecture…?)
Why are we doing this?
 This practicum will help you find answers to those
questions

 It’s harder than it sounds!

 You need to be disciplined about your own work
 Use a structured process
 Keep track of a lot of little details
 Little by little you’ll get used to it
 If you like it, great! You’ll have an important skill for
your professional career.
 And if you don’t like it, remember you only have to do it
this term…
How to get a good grade
 Short story:
 It’s very easy, really. Just follow the process thoroughly
and you’ll do great.

 Longer story:
 Read ‘A Discipline for Software Engineering’
conscientiously.
 Warning: Humphrey is not especially fun or concise
 Stick to the process while doing the exercises
 Use the forms appropriately
 Extract insights from your own work, and report them
 Reflections on your performance and on the process
 Work on two levels
 Quality of your code, quality of your process
 Submit your assignments on time
The Personal Software Process
 Basic idea #1: Measure yourself
 Know how much time you spend in
programming tasks
 Know how many defects your code has
 Know how well you estimate your effort

 You can’t control what you can’t measure

 Basic idea #2: Control yourself

 Improve your estimates
 Improve the quality of your software
The Personal Software Process
 PSP is incremental:
 PSP0
 Whatever you’re currently doing, plus some
measurements
 PSP0.1 -> PSP1 -> PSP1.1
 Increasingly detailed estimates, controls
 You start to apply regression to your estimates
 You start getting efficiency and other quality metrics
 This is as far as we’ll go
 PSP2 -> PSP3
 We won’t have the time to go there…
 I admit it does get hairy at this point…
The Personal Software Process
 PSP0
 You’ll be using three forms:
 Project Plan Summary
 Time Recording Log
 Defect Recording Log

 Refer to Humphrey’s book for correct usage of these

forms

 Project Plan Summary

 After understanding the requirements, estimate how many
minutes will the assignment take
 After finishing the assignment, write down how much time
it actually took, and how many defects you found
 It is OK to be absolutely wrong in your initial
estimates…
The Personal Software Process
 PSP0
 Time Recording Log
 Have it handy when you work on your assignments
 Record everything
 If you get up from your desk, get a call, read email…
make sure your log has the corresponding ‘Interruption
Time’ entries
 Some details will feel embarrassing (two hours fixing a
bug, for example…). Record them anyway
 Use minutes, not hours
 Low-tech works better than hi-tech at this point
 Use Humphrey’s classification of activities:
 Planning, Design, Code, Compile, Test, Postmortem
The Personal Software Process
 PSP0
 Defect Recording Log
 Again, record every defect
 If you designed your routines incorrectly, write the
defect in the log
 If you made an off-by-one error, write it in the log
 If your automated tests were wrong, write it in the log
 …you get the idea…
 If unsure as to what ‘defect type’ each defect belongs
to, write your assumptions in the defect description
The Personal Software Process
 The three forms of PSP0 will become the
foundation of later assignments
 It will feel weird at the beginning
 Give it some time

 With time, you will be recording your time and

defects naturally
 Appreciating the advantages of this process will take
a while

 It shouldn’t interfere with your creative

processes!
Assignment 1
 Write a program to calculate the mean and standard
deviation of a sample of n real numbers.

 Hints
 Remember we’re interested in that you learn a process, not in
that you know how to program a standard deviation routine!
 Your report on insights and impressions is important – it will
show us if your brain is engaged in the exercise or not
 Make sure you understand the requirements before you start
coding
 Document all assumptions
 Automated tests are (almost) always better than manual tests
 Be nice to the TA that will mark your work and that of 150
other persons
 Although it shouldn’t take too long, start soon. We can tell if
you’re rushing to finish your assignment
Am I missing something?
 Questions?