INFO 636 Software Engineering Process I Prof. Glenn Booker

www.ischool.drexel.edu

INFO 636 Software Engineering Process I

Prof. Glenn Booker

Weeks 1-2 – Introduction

1INFO636 Weeks 1-2

www.ischool.drexel.eduINFO636 Weeks 1-2 2

Overview

• This course introduces most of the Personal Software Process (PSP)

• The PSP defines a method for individual planning, measurement, and improvement which is compatible with the principles of the Capability Maturity Model for Software (SW-CMM)


Syllabus

• See Blackboard (Bb) or my web site for the course syllabus and other materials– Bb is the authoritative reference for online

courses; the web site is a backup location

• While designed for software development, the process has been adapted to allow for a non-programming track (N) as an alternative to the programming track (P)


P versus N track

• The programming track (P) will do a series of small text-based programming exercises, and measure the time and volume of work produced– Software engineering students must follow the

P track– You pick the language and development

environment you’ll use– Don’t go beyond the stated requirements for

each assignment!


P versus N track

• The non-programming track (N) will monitor their work to perform this course, and do additional readings– The N track was created for those who are

extremely rusty at programming, but still want to benefit from the course (since many of the concepts we’ll use could be applied to any process, not just software development)


Syllabus

• After getting settled into the course, we quickly settle into a series of weekly assignments which get progressively more and more advanced

• By the end of the course, you will be able to develop a statistical model of your own activities, and use it to predict your future performance


PSP Strategy

• The PSP is a very structured approach to help you control, manage, and improve the way you work

• While created for software development, it can be applied to any kind of repeated process– It is designed to be tailored, not taken

to be “The One True Correct Process”


PSP Strategy

• Software development has been in crisis since at least 1968, when it was first identified by a NATO conference

• We tend to develop software as an art form, rather than a science

• Part of the PSP’s purpose is to instill more predictability into development


PSP Strategy

• Software is becoming omnipresent, so we need to make quality software– We have been trained to accept lousy

software quality, even though it isn’t necessary!

• The PSP defines a structured process for developing software


Software Process

• A software process– Improves communication between the

development team and the customer– Enhances management understanding

of project status– Facilitates reuse of software– Supports process evolution and improvement


Process Maturity

• The SW-CMM defines levels of maturity for software processes– They don’t guarantee quality software,

but at least they can assure you that the level of quality is known and is predictable

• There are five levels of maturity– Level 1 means you have no software process,

or it’s completely chaotic


Process Maturity

– Level 2 means one project has defined processes which are repeatable

– Level 3 means an organization has processes tailored to each project

– Level 4 means an organization has statistical understanding of key activities

– Level 5 means an organization is making continuous improvements to processes


Process Maturity

• Caveat on the age of the text:– The SW-CMM has been replaced by the

Capability Maturity Model Integration (CMMI)– The basic concept still applies– CMMI goes beyond development to include

processes for software acquisition, systems engineering, and integrated teaming


Personal Responsibilities

• The CMM is designed so that a project or organization can earn maturity ratings as a whole (the ‘staged’ approach)

• The PSP applies those concepts to the level of the individual programmer– It assumes you are highly motivated to do

excellent work

• The PSP doesn’t work well for everyone


PSP Assumptions

• The PSP also assumes that– Using a defined process can improve

efficiency– Processes should be adjusted for each

person– People should participate in definition of their

processes– Continuous improvement is improved by quick

feedback


PSP Structure

• The PSP is presented as a series of increasingly mature processes, kind of like the CMM maturity levels– PSP0 is the Baseline Personal Process– PSP1 is the Personal Planning Process– PSP2 is Personal Quality Management– PSP3 is the Cyclic Personal Process


Baseline Personal Process

• PSP0 establishes basic measurements of activities and how to report them– How to record time for activities– How to record defects– How to categorize the type of defects



• It is refined in PSP0.1 to add – A coding standard to help make code

look homogeneous across developers– Size measurement convention, since size

of work product is critical for estimation– A process improvement proposal, to capture

new ideas


Personal Planning Process

• PSP1 prepares to add planning to PSP0.1– Size estimating– Test reporting

• PSP 1.1 adds the plans themselves– Task planning– Schedule planning


Personal Quality Management

• PSP2 adds reviews to the development process, and measures productivity– Code review– Design review

• PSP2.1 adds guidance for software design– Design templates


Cyclic Personal Process

• PSP3 recognizes that a single person can’t plan and develop a large program in one swell foop*, so it adds cyclic or iterative development to the process– Break a large project into pieces small

enough to handle with PSP2-sized tasks

* As opposed to a ‘fell swoop’


Team Software Process

• Beyond the PSP, the Team Software Process (TSP) takes the principles of the PSP and adapts them to a small development team (6-20 people)– Roles are assigned for planning,

management, etc. in addition to contributing to development

– Covered in INFO 637


Individuality

• Productivity varies from one person to the next; that’s why we measure what it is for each person – We aren’t here to judge your productivity– Some can finish an assignment in two hours;

others might take 12 or 15 hours– Similarly I don’t care if you have two defects

or fifty


A word about forms

• The PSP is full of forms, which each have a number (e.g. C16) and name

• Often I’ll refer to forms only by their number, particularly in giving assignment feedback, so make sure the form number is on each form, not just its name



• Now we’ll look at the PSP0 Baseline Personal Process in more detail

• We define a process in order to help plan and evaluate the tasks we need to accomplish

• This will later feed into process improvement activities



• PSP0 gives us– A basic structure for doing small tasks– A method for measuring those tasks

• The “life cycle” tasks for PSP0 are basic:– Plan the work in the summary report– Do the work– Fill out the logs– Fill out the summary report



• Forms are a necessary evil in the PSP– Need to have a consistent format for

recording data and doing analyses– You may transfer them to Excel if you want –

may be easier to manage as sheets in a workbook

• You may generally turn in one Word file and one Excel file per assignment – do NOT put each form in a separate file!



• The summary process script is in Table 2.1 (p. 36)– The planning and postmortem activities are

described in more detail in scripts in Tables 2.2 and 2.3 (pp. 36-37)

• This is a common pattern in the PSP – one table describes the overall process, and later tables may describe major steps within that process


The Mother of All Forms

• The most fundamental form in the PSP is the Time Recording Log (p. 40) also known as Table C16 (p. 657)– Use it to record ALL time spent doing stuff for

this course. Literally.– Fill in all the fields – use Comments to be

more specific than the Activity or Phase – Called N16 for N track people


The Mother of All Forms

– Be sure to label what phase or kind of activity it was (reading, coding, etc.)

• For P track students: use the Phases given in the project plan summary – planning, design, coding, compile, test, postmortem

• For N track students: use the Activity types defined in the Definitions sheet of N16

– Do not combine different types of activities in one time log entry

• Split them into two or more separate entries, e.g. one for code and one for test


Project Plan Summary

• Start PSP0 with the Project Plan Summary– Table 2.13 (p. 52), a.k.a. Table C14

(p. 655)– Be sure to fill in the header information– The one line under the Plan column is for

guessing the total time needed for that week’s assignments

• As this point it’s just a guess, we’ll refine it later!



• That’s all the planning at this point• Now do the assignments given in your

track’s syllabus, recording time in the time log as you go

• Add up the Delta Time for each phase or activity in your time log– Delta Time = Stop – Start - Interruption– Record time intervals in minutes


Project Plan Summary

• Now go back to the Project Plan Summary, and enter the actual times for each phase of activity

• Calculate the ‘To Date’ and ‘To Date %’ column– See other lecture handout for examples


Defect Recording Log

• If you find mistakes while doing your coursework, fill out the defect log for each defect– Defects could be design errors, programming

mistakes, filling forms out wrong, etc.

• The Defect Recording Log (p. 45) is Form C18 (p. 659)


Defect Recording Log

• The defect recording log is used throughout the PSP, but may be somewhat confusing– Number is just a unique sequential number

for each defect– Type is from the defect standard (p. 48)– Inject and Remove are the activities or life

cycle phases when the defect was made (inject) and found (remove)



– Fix Defect only applies if this defect was created as a result of trying to fix an earlier defect

• Hence if you are fixing defect Number 12, and later discover that caused defect Number 15, then under defect 15, the Fix Defect field would say ’12’

• Otherwise this field is usually left blank

• Then fill out the defect portions of the Project Plan Summary


Note for N Track Students

• You are using forms N14 and N16– They correspond pretty closely to C14 and

C16, but don’t have the defect sections– The same caveats and instructions apply– For N14, have to add the Activity types, such

as Discussion, Prep., etc.

Documents

INFO 636 Software Engineering Process I Prof. Glenn Booker