1. Personal Software Process 2004.7.26 KAIST SE Lab.

2. 2004-07-26 2/98 Contents  Introduction of Personal Software Process  Exercise 1 : PSP0 –Assignment #1  Exercise 2 : PSP0.1 –Assignment #2, #3

3. 2004-07-26 3/98 Introduction of PSP

4. 2004-07-26 4/98 Problems(1/2) You have to manage your work, assess your talent, and build your skills!

5. 2004-07-26 5/98 Problems(2/2)  You need to understand your own abilities using your process –To apply to your assigned tasks –To manage your weaknesses –To build on your strengths  You have to improve your own process to be had high quality goal More aggressive goal World-class runners know their best time for a mile, and they know the world record

6. 2004-07-26 6/98 What is the PSP?  Self-improvement process –To help you control, manage, and improve your working way  Personal process for developing software –Defined steps –Forms –Standards  Measurement and analysis framework –To help you to characterize your process  Defined procedure to help you to improve your performance

7. 2004-07-26 7/98 PSP Principles(1/2)  Quality of a software system is governed by the quality of the process used to develop and evolve it  Quality of a software system is determined by the quality of its worst components  Quality of a software component is governed by the individual who developed it  Individual performance is governed by the individual’s knowledge, discipline, and commitment

8. 2004-07-26 8/98 PSP Principles(2/2)  As software professionals, you should know your own performance  You should measure, track, and analyze your work  You should learn from your performance variations  You should incorporate lessons learned into your personal practices

9. 2004-07-26 9/98 Logic for the PSP  Software professionals will better understand what they do if they define, measure, and track their work  They will then have a defined process structure and measurable criteria for evaluating and learning from their own and others’ experiences  With this knowledge and experience, they can select those methods and practices that best suit their particular tasks and abilities  By using a customized set of orderly, consistently practiced, and high-quality personal practices, they will be more effective members of their development teams and projects

10. 2004-07-26 10/98 What Does the PSP Provide?  Stable, mature PSP allows you to –Estimate and plan your work –Understand your current ability to develop software –Meet your commitments –Resist unreasonable commitment pressures –Gives the data and analysis techniques that you can use to determine Which technologies to adopt Which methods work best for you  PSP provides –Proven basis for developing and practicing industrial-strength personal disciplines –Discipline that shows you how to improve your personal process –Data to continually improve the productivity, quality, and predictability of your work

11. 2004-07-26 11/98 PSP maturity framework(1/2) PSP0 Current process Time recording Defect recording Defect type standard PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Cording standard Size measurement Process improvement proposal PSP0.1 Cording standard Size measurement Process improvement proposal PSP1 Size estimating Testing report PSP1 Size estimating Testing report PSP1.1 Task planning Schedule planning PSP1.1 Task planning Schedule planning PSP2 Code reviews Design reviews PSP2 Code reviews Design reviews PSP2.1 Design templates PSP2.1 Design templates PSP3 Cycle development PSP3 Cycle development Baseline Personal Process Personal Planning Process Personal Quality Management Cyclic Personal Process

12. 2004-07-26 12/98 PSP maturity framework(2/2)  PSP0: –You establish a measured performance baseline  PSP1: –You make size, resource, and schedule plans  PSP2: –You practice defect and yield management  PSP3: –You scale up PSP methods to larger projects

13. 2004-07-26 13/98 PSP strategy(1/4)  PSP0 : Baseline process –Provides a consistent basis for measuring progress and a defined foundation on which to improve Time recording Defect recording Defect type standard –Should be your current process –PSP0.1 Coding standard Size measurement Process improvement proposal(PIP) –Structured form to record process problems, experiences and improvement suggestions

14. 2004-07-26 14/98 PSP strategy(2/4)  PSP1 : Personal planning process –Adds planning steps to PSP0 Test report Size and resource estimating –Reasons of making explicit and documented plans To help you understand the relation between the size of the programs and the time To help you to make commitments you can meet To give you an orderly plan for doing the work To give you a framework for determining the status of your work –PSP1.1 Task and schedule planning

15. 2004-07-26 15/98 PSP strategy(3/4)  PSP2 : Personal quality management process –Adds review techniques to PSP1 to help you find defects early Code reviews Design reviews –Defect management with review techniques Gathering and analyzing the defects found in compile and test for your earlier programs Establishing review checklists Making your own process quality assessments –PSP2.1 Design templates Establishes design completeness criteria and examines various design verification and consistency techniques

16. 2004-07-26 16/98 PSP strategy(4/4)  PSP3 : Cyclic personal process –Apply PSP works to large projects Strategy is to subdivide a larger program into PSP2-sized pieces

17. 2004-07-26 17/98 Team Software Process(TSP)  Framework and a process structure for building and guiding engineering teams that develop software  TSP contains –Team-building process Team goals, commitment, cohesion, and structure issues –Team-working process Engineering processes and practices used by the team  Prerequisite for a team to use the TSP –Understanding of the software engineering and process skills taught in the PSP

18. 2004-07-26 18/98 CMM(Capability Maturity Model)(1/2)  Developed by the SEI with the help of leading software groups  Characterizes the most effective large-scale software practices –Key process areas(KPAs) provide goals and example practices  Upgraded to CMMI(Capability Maturity Model Integration) from 2000 –SEI no longer maintains CMM –Many industrial organizations have to change their SPI policy from CMM-based to CMMI-based

19. 2004-07-26 19/98 CMM(2/2)  CMM KPAs Level 1- initial Level 2- Repeatable Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Level 2- Repeatable Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Level 3 – Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Software process definition Software process focus Level 3 – Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Software process definition Software process focus Level 4 – Managed Quality management Quantitative process management Level 4 – Managed Quality management Quantitative process management Level 5 – Optimizing Process change management Technology change management Defect prevention Level 5 – Optimizing Process change management Technology change management Defect prevention

20. 2004-07-26 20/98 CMM and PSP Level 1- initial Level 2- Repeatable Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Level 2- Repeatable Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Level 3 – Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Software process definition Software process focus Level 3 – Defined Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Software process definition Software process focus Level 4 – Managed Quality management Quantitative process management Level 4 – Managed Quality management Quantitative process management Level 5 – Optimizing Process change management Technology change management Defect prevention Level 5 – Optimizing Process change management Technology change management Defect prevention Not individual level Its implications are better demonstrated in a small-team environment Broader organizational issues

21. 2004-07-26 21/98 PSP, TSP, and CMM CMM SM - Builds organizational capability TSP - Builds quality products on cost and schedule PSP - Builds individual skill and discipline

22. 2004-07-26 22/98 PSP process flow Requirements Finished product Project summary Project summary Project and process data summary report Planning Design Code Compile Test PM Scripts guide Logs

23. 2004-07-26 23/98 Productivity and PSP : example(1/6)  Student 1 –System engineer –Experience : over 13 years, 20 KLOC of programs –Uses C  Student 2 –Software engineer –Experience : over 11 years, 100 KLOC of programs –Uses Ada

24. 2004-07-26 24/98 Productivity and PSP : example(2/6)  Development Time Stu1 Stu2

25. 2004-07-26 25/98 Productivity and PSP : example(3/6)  Program sizes –Programs are in different languages –LOC give some indication of the amount of development work involved Stu2 Stu1

26. 2004-07-26 26/98 Productivity and PSP : example(4/6)  Different points between 2 students –From program 1A to 10A Student1Student2 Called for the user to enter file namesHard-coded the file name Return the input back to the user to ensure it was correct Did not Constructed a linked list and then did the calculations Did the calculations on the input data as they were entered Produced extensive commentsNo comments Added a design description for each program Included only for 9A and 10A

27. 2004-07-26 27/98 Productivity and PSP : example(5/6)  Development productivity Stu2 Stu1 stable fluctuate

28. 2004-07-26 28/98 Productivity and PSP : example(6/6)  Test defects per KLOC Stu2 Stu1

29. 2004-07-26 29/98 Summary  PSP is a defined process to help you do better work  PSP is not a magic answer to all your software engineering problems –You must make the improvements yourself!

30. 2004-07-26 30/98 Exercise 1 : PSP0 PSP0 Current process Time recording Defect recording Defect type standard PSP0 Current process Time recording Defect recording Defect type standard

31. 2004-07-26 31/98 Contents  PSP0 process  PSP0 measure –Time record log –Defect recording log –Defect type standard –PSP0 plan summary  Assignment#1 : JD scenario

32. 2004-07-26 32/98 PSP0 Process  Purpose –Provides the framework for gathering your initial process data Build a quantitative understanding of each step  Provides –Convenient structure for doing small-scale tasks –Framework for measuring these tasks –Foundation for process improvement

33. 2004-07-26 33/98 PSP0 Process Requirements Finished product Project and Process Data Summary Report Planning DesignCodeCompileTest Postmortem Development

34. 2004-07-26 34/98 PSP0 Process script Phase Number PurposeTo guide you in developing module-level programs Entry Criteria Problem description PSP0 Project Plan Summary form Time and Defect Recording Logs Defect Type Standard Stop watch (optional) 1Planning Produce or obtain a requirements statement. Estimate the required development time. Enter the plan data in the Project Plan Summary form. Complete the Time Recording Log. 2Development Design the program. Implement the design. Compile the program and fix and log all defects found. Test the program and fix and log all defects found. Complete the Time Recording Log. 3PostmortemComplete the Project Plan Summary form with actual time, defect, and size data. Exit Criteria A thoroughly tested program Completed Project Plan Summary form with estimated and actual data Completed Defect and Time Recording Logs

35. 2004-07-26 35/98 PSP0 Planning script Phase Number PurposeTo guide the PSP planning process Entry Criteria Problem description Project Plan Summary form Time Recording Log 1Program Requirements Produce or obtain a requirements statement for the program. Ensure that the requirements statement is clear and unambiguous. Resolve any questions. 2Estimate ResourcesMake your best estimate of the time required to develop this program. Exit Criteria Documented requirements statement Completed Project Plan Summary form with estimated development time data Completed Time Recording Log

36. 2004-07-26 36/98 PSP0 Development script Phase Number PurposeTo guide the development of small programs Entry Criteria Requirements statement Project Plan Summary form with planned development time Time and Defect Recording Logs Defect Type Standard 1Design Review the requirements and produce a design to meet them. Record time in Time Recording Log. 2Code Implement the design. Record in the Defect Recording Log any requirements or design defects found. Record time in Time Recording Log. 3Compile Compile the program until error-free. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log. 4Test Test until all tests run without error. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log. Exit Criteria A thoroughly tested program Completed Defect and Time Recording Logs

37. 2004-07-26 37/98 PSP0 Postmortem script Phase Number PurposeTo guide the PSP postmortem process Entry Criteria Problem description and requirements statement Project Plan Summary form with planned development time Completed Time Recording Log Completed Defect Recording Log A tested and running program 1Defects Injected Determine from the Defect Recording Log the number of defects injected in each PSP0 phase. Enter this number under Defects Injected–Actual on the Project Plan Summary form. 2Defects Removed Determine from the Defect Recording Log the number of defects removed in each PSP0 phase. Enter this number under Defects Removed–Actual on the Project Plan Summary form. 3Time Review the completed Time Recording Log. Enter the total time spent in each PSP0 phase in the Actual column of the Project Plan Summary form. Exit Criteria A fully tested program Completed Project Plan Summary form Completed Defect and Time Recording Logs

38. 2004-07-26 38/98 PSP0 measure  Time spent per phase –Time recording log –Simple record of the clock time you spend in each part of the PSP process  Defects found per phase –Defect recording log –Record data on every defect you find during compile and test –Defect is counted every time you make a program change  Multiple-defect problem

39. 2004-07-26 39/98 Time record log(1/2)  Header –Enter name, date, instructor, and program number  Date –Enter the current date  Start –Enter the time in minutes when you start a project phase  Stop –Enter the time in minutes when you stop work on a project phase, even if you are not done with that phase

40. 2004-07-26 40/98 Time record log(2/2)  Interruption time –Enter any time that you lost due to interruptions in the start to stop period  Delta time –Enter the elapsed time less the interruption time (start to stop)  Phase –Note the phase on which you were working –Use the phase name  Comments describe –Interruption, task you were doing, and anything else that significantly affects your work

41. 2004-07-26 41/98 Defect recording log(1/2)  Header –Enter the name, date, instructor, and program number  Date –Enter the date when you found and fixed the defect  Number –Enter a unique number for this defect –Start each project with 1  Type –Enter the defect type from the defect type standard

42. 2004-07-26 42/98 Defect recording log(2/2)  Inject –Enter the phase during which you judge the defect was injected  Remove –Enter the phase in which you found and fixed the defect  Fix time –Enter the time that you took to both find and fix the defect  Fix defect –If this defect was injected while fixing another defect, enter the number of that defect (or an X if you do not know)  Description –Enter explanation of what the defect was (not the symptom, but the defect!)  Note –Defect is anything in the program that must be changed for it to be properly developed, enhanced, or used

43. 2004-07-26 43/98 Defect type standard Type NumberType NameDescription 10Documentationcomments, messages 20Syntaxspelling, punctuation, typos, instruction formats 30Build, Packagechange management, library, version control 40Assignmentdeclaration, duplicate names, scope, limits 50Interfaceprocedure calls and references, I/O, user formats 60Checkingerror messages, inadequate checks 70Datastructure, content 80Functionlogic, pointers, loops, recursion, computation, function defects 90Systemconfiguration, timing, memory 100Environmentdesign, compile, test, or other support system problems  General set of defect categories

44. 2004-07-26 44/98 PSP0 Plan Summary(1/2)  Header –Enter name, date, program, instructor, and language  Enter your best estimate of the total time that the development will take  Enter the actual time in minutes that you spent in each phase

45. 2004-07-26 45/98 PSP0 Plan Summary(2/2)  Time to date –Enter the total time spent in each phase to date  Time to date % –Enter the percent of the total To date time that was spent in each phase  Defects injected and removed –Enter the actual numbers of defects injected and removed in each phase  Defects to date –Enter the total defects injected and removed in each phase to date  Defects to date % –Enter the percent of the total To date defects injected and removed in each phase

46. 2004-07-26 46/98 Assignment #1 : JD scenario  30 minutes

47. 2004-07-26 47/98 Summary  PSP0 measures –Time that you spend in each development phase –Defects that you inject and find per phase  PSP0 uses –Standard formats for defect and time recording  PSP0 is –Framework for gathering your initial process data

48. 2004-07-26 48/98 Exercise 2 : PSP0.1 PSP0 Current process Time recording Defect recording Defect type standard PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Cording standard Size measurement Process improvement proposal PSP0.1 Cording standard Size measurement Process improvement proposal

49. 2004-07-26 49/98 Contents  PSP0.1 Process  Planning  Size measurement  LOC counting standard template  Coding standard  Assignment#2 : Counting LOC  PSP0.1 project plan summary  Process improvement proposal  Assignment#3 : PPS for JD’s program

50. 2004-07-26 50/98 PSP0.1 Process

51. 2004-07-26 51/98 PSP0.1 Process script additions  Additions to the PSP0.1 process scripts include new steps for –Estimating and reporting software size –Distributing development time over planned project phases –Using a counting and coding standard –Recording process problems and improvement ideas

52. 2004-07-26 52/98 PSP0.1 Process script Phase Number PurposeTo guide you in developing module-level programs Entry Criteria Problem description PSP0.1 Project Plan Summary form Time and Defect Recording Logs Defect Type Standard Stop watch (optional) 1Planning Produce or obtain a requirements statement. Estimate the total new and changed LOC required. Estimate the required development time. Enter the plan data on the Project Plan Summary form. Complete the Time Recording Log. 2Development Design the program. Implement the design. Compile the program and fix and log all defects found. Test the program and fix and log all defects found. Complete the Time Recording Log. 3PostmortemComplete the Project Plan Summary form with actual time, defect, and size data. Exit Criteria A thoroughly tested program Completed Project Plan Summary form with estimated and actual data Completed PIP forms Completed Defect and Time Recording Logs

53. 2004-07-26 53/98 PSP0.1 Planning script Phase Number PurposeTo guide the PSP planning process Entry Criteria Problem description PSP0.1 Project Plan Summary form Time Recording Log 1Program Requirements Produce or obtain a requirements statement for the program. Ensure the requirements statement is clear and unambiguous. Resolve any questions. 2Size EstimateMake your best estimate of the total new and changed LOC required to develop this program. 3Resource Estimate Make your best estimate of the time required to develop this program. Using the To Date % from the most recently developed program as a guide, distribute the development time over the planned project phases. Exit Criteria Documented requirements statement Project Plan Summary form with estimated program size and development time data Completed Time Log

54. 2004-07-26 54/98 PSP0.1 Development script Phase Number PurposeTo guide the development of small programs Entry Criteria Requirements statement Project Plan Summary form with estimated program size and development time Time and Defect Recording Logs Defect Type Standard and Coding Standard 1Design Review the requirements and produce a design to meet them. Record time in Time Recording Log. 2Code Implement the design following the Coding Standard. Record in the Defect Recording Log any requirements or design defects found. Record time in Time Recording Log. 3Compile Compile the program until error-free. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log. 4Test Test until all tests run without error. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log. Exit Criteria A thoroughly tested program that conforms to the Coding Standard Completed Defect and Time Recording Logs

55. 2004-07-26 55/98 PSP0.1 Postmortem script Phase Number PurposeTo guide the PSP postmortem process Entry Criteria Problem description and requirements statement Project Plan Summary form with planned program size and development time Completed Time Recording Log Completed Defect Recording Log A tested and running program that conforms to the Coding Standard 1Defects Injected Determine from the Defect Recording Log the number of defects injected in each PSP0.1 phase. Enter this number under Defects Injected–Actual on the Project Plan Summary form. 2Defects Removed Determine from the Defect Recording Log the number of defects removed in each PSP0.1 phase. Enter this number under Defects Removed–Actual on the Project Plan Summary form. 3Size Count the LOC in the completed program. Determine the base, reused, deleted, modified, added, total, total new and changed, and new reused LOC. Enter these data on the Project Plan Summary form. 4Time Review the completed Time Recording Log. Enter the total time spent in each PSP0.1 phase in the Actual column of the Project Plan Summary form. Exit Criteria A fully tested program that conforms to the Coding Standard Completed Project Plan Summary form Completed PIP forms describing process problems, improvement suggestions, and lessons learned Completed Defect and Time Recording Logs

56. 2004-07-26 56/98 Planning

57. 2004-07-26 57/98 Why make plans?  Plans –Allow you to make commitments that you can meet –Provide a basis for agreeing on the job –Guide your work –Help to track your progress –Ensure project completion  In mature software organizations, plans are used as –Basis for agreeing on the cost and schedule for a job –Organizing structure for doing the work –Framework for obtaining the required resources –Record of what was initially committed

58. 2004-07-26 58/98 Project planning framework Define requirements Produce conceptual design Estimate size Estimate resources Produce schedule Develop product Process analysis Resources available Size database Productivity database Customer needs Delivered Product Tracking Reports Management Customer Tasks Item Size, resource, schedule data

59. 2004-07-26 59/98 Size measurement

60. 2004-07-26 60/98 Why measure size?  Size measures –Help you to make better plans –Assist you in tracking development –Normalize other measures Development resources Defect rates

61. 2004-07-26 61/98 Size measurement criteria  Size measurements must be –Related to development effort –Precise –Machine countable –Suitable for early planning

62. 2004-07-26 62/98 Size vs. development effort  Principal requirement –If the size measure is not directly related to development cost, it is not worth using  There are many possible measures –Lines of code (LOC) –Function points –Pages, screens, scripts, reports etc.  Size measure should be sensitive to language, design, and development practice

63. 2004-07-26 63/98 C++ LOC vs. development time 0 1000 2000 3000 4000 5000 6000 0100200300400500600700800 C++ LOC Time (min.)

64. 2004-07-26 64/98 Pascal LOC vs. development time 0 2000 4000 6000 8000 10000 12000 14000 0200400600800100012001400160018002000 Pascal LOC Time (min.)

65. 2004-07-26 65/98 Text Pages vs. time Text Pages 0 20 40 60 80 100 120 051015202530354045 Time (hours)

66. 2004-07-26 66/98 Screen LOC vs. time 0 10 20 30 40 50 60 70 80 90 100 05001000150020002500300035004000 Screen LOC Time (hours)

67. 2004-07-26 67/98 Precision and accuracy Imprecise and inaccurate Precise and inaccurate Imprecise and accurate Precise and accurate x x x x x x x xx x x x x x x x x x x x x  Precision –Deals with the granularity or level of detail in measure  Accuracy –Concerns the relation between an assertion and the actual fact

68. 2004-07-26 68/98 Size measurement framework  Developed by SEI for describing software size measurements  Has two principal criteria –Communication –Repeatability  Uses logical LOC metric –Statement specification Executable Nonexecutable

69. 2004-07-26 69/98 Counting program size  Counting lines –Logical lines Invariant to editing changes Correlate with development effort Uniquely definable Complex to count –Physical lines Easy to count Not invariant Not uniquely definable  PSP uses –Defined coding standard –Physical LOC counter Physical line for each logical line

70. 2004-07-26 70/98 Example of LOC accounting(1/2) Version 0 350 LOC Enhance to version 1 + 125 new and changed LOC Expected size 350+125=475 LOC What happened? Measured size 450 LOC

71. 2004-07-26 71/98 Example of LOC accounting(2/2) AddedSubtractedBase Base V00 Deleted 0 Modified 00 Added 350 Total V0 LOC350-0350 Deleted 0 Modified 25 Added 100 Final Product125-25450 Total New and Changed LOC475

72. 2004-07-26 72/98 LOC counting standard

73. 2004-07-26 73/98 LOC counting standard template  You can tailor it to fit your needs or language

74. 2004-07-26 74/98 Completing the header The name you give this standard The language you are using Your nameThe date you produced this standard (or revision)  Complete the header as follows

75. 2004-07-26 75/98 Count type  Choices are logical and physical LOC –Logical LOC counts language elements –Physical LOC counts text lines  For this counting standard, you are counting logical LOC

76. 2004-07-26 76/98 Statement type  Use this section to define how you will count various types of statements. Consider the following. –How are you going to count procedure declarations and function prototypes? –How will you count compiler directives? –Will you count comments? Why or why not?

77. 2004-07-26 77/98 Clarifications  A fully operational standard generally requires many notes and comments  Use the clarification section for this purpose.

78. 2004-07-26 78/98 Coding standard

79. 2004-07-26 79/98 Coding standard : example (1/4) Purpose:To guide the development of C++ programs Program HeadersBegin all programs with a descriptive header. Header Format/*************************************************************/ /* Program Assignment: the program number */ /* Name: your name */ /* Date: the date program development started */ /* Description: a short description of the program */ /* function */ /*************************************************************/ Listing ContentsProvide a summary of the listing contents. Contents Example/*************************************************************/ /* Listing Contents: */ /* Reuse instructions */ /* Modification instructions */ /* Compilation instructions */ /* Includes */ /* Class declarations: */ /* CData */ /* ASet */ /* Source code in c:\classes\CData.cpp: */ /* CData */ /* CData() */ /* Empty() */ /*************************************************************/

80. 2004-07-26 80/98 Coding standard : example (2/4) Reuse Instructions Describe how the program is used. Provide the declaration format, parameter values and types, and parameter limits. Provide warnings of illegal values, overflow conditions, or other conditions that could potentially result in improper operation. Reuse Example/*************************************************************/ /* Reuse Instructions */ /* int PrintLine(char *line_of_character) */ /* Purpose: to print string, 'line_of_character', on one print line */ /* Limitations: the maximum line length is LINE_LENGTH */ /* Return: 0 if printer not ready to print, else 1 */ /*************************************************************/ IdentifiersUse descriptive names for all variables, function names, constants, and other identifiers. Avoid abbreviations or single letter variables. Identifier Exampleint number_of_students; /* This is GOOD */ float x4, j, ftave; /* These are BAD */

81. 2004-07-26 81/98 Coding standard : example (3/4) Comments Document the code so that the reader can understand its operation. Comments should explain both the purpose and behavior of the code. Comment variable declarations to indicate their purpose. Good CommentIf (record_count > limit) /* have all the records been processed? */ Bad Commentif(record_count > limit) /* check if record_count is greater than limit */ Major SectionsPrecede major program sections by a block comment that describes the processing that is done in the next section. Example/************************************************************/ /* This program section will examine the contents of the array “grades” */ /* and will calculate the average grade for the class. */ /************************************************************/ Blank Spaces Write programs with sufficient spacing so that they do not appear crowded. Separate every program construct with at least one space.

82. 2004-07-26 82/98 Coding standard : example (4/4) Indenting Indent every level of brace from the previous one. Open and close braces should be on lines by themselves and aligned with each other. Indenting Example while (miss_distance > threshold) { success_code = move_robot (target_location); if (success_code == MOVE_FAILED) { printf(“The robot move has failed.\n”); } Capitalization Capitalized all defines. Lowercase all other identifiers and reserved words. Messages being output to the user can be mixed-case so as to make a clean user presentation. Capitalization Example #define DEFAULT-NUMBER-OF-STUDENTS 15 int class-size = DEFAULT-NUMBER-OF-STUDENTS;

83. 2004-07-26 83/98 Assignment #2 : Counting LOC  15 minutes

84. 2004-07-26 84/98 Project plan summary

85. 2004-07-26 85/98 PSP0.1 Project plan summary(1/6)  PSP0.1 adds estimated and actual LOC in summary form  Types of LOC include –Base [B] –Deleted base [D] –Modified base [M] –Added–new and base [A] –Reused [R] –Total new and changed [N] –Total new reuse 2004-07-26

86. 86/98 Types of program LOC New & Changed Base programNew program Deleted Added Untouched Modified New Reused Reused

87. 2004-07-26 87/98  Before development –If this is an enhancement, measure the size of the base program and enter these LOC in the Base (B) space under Actual –Estimate the new and changed LOC and enter these LOC in the Total New & Changed (N) space under Plan. PSP0.1 Project plan summary(2/6) 2004-07-26

88. 88/98 PSP0.1 Project plan summary(3/6)  Before development, –Distribute development time over project phases Using To Date % Time in Phase from previous programs. 2004-07-26

89. 89/98 PSP0.1 Project plan summary(4/6)  After development – Measure total program size and enter these LOC in the Total LOC (T) space under Actual. – Count the deleted LOC and enter in the Deleted (D) space under Actual. – Count the modified LOC and enter in the Modified (M) space under Actual. 2004-07-26

90. 90/98  After development (continued) PSP0.1 Project plan summary(5/6) Calculate the added LOC as A = T - B + D - R. Calculate the Total New and Changed LOC as N = A + M. Count the reused LOC and enter in the Reused (R) space under Actual. Count or estimate the number of new and changed LOC that will be added to the reuse library. 2004-07-26

91. 91/98 PSP0.1 Project plan summary(6/6)  After development, –Adds the actual reused, new and changed, total, and total new reuse LOC from this and all previous programs –Enter these data in the To Date column. The To Date data are used to calculate various process parameters in later PSP versions. 2004-07-26

92. 92/98 Project improvement proposal

93. 2004-07-26 93/98 Process improvement proposal(1/2)  To improve your process, you will need to –Capture process problems –Propose improvements for future reference.  You will need to know –Any problems you have encountered in using the process –Any suggestions you have for process improvements –Your observations and findings from doing the exercise 2004-07-26

94. 94/98 Process improvement proposal(2/2)  PIP holds process improvement information –PIP number –Problem description –Proposed solution –Notes and comments 2004-07-26

95. 95/98 Assignment #3 : PPS for JD’s program  15 minutes

96. 2004-07-26 96/98 Summary  To effectively plan and manage your work, you must measure product size  PSP uses LOC as the size measure  For other measures, size must correlate with development time  Every size measure should be precisely defined and automatically countable

97. 2004-07-26 97/98 Reference  [1] Watts S. Humphrey,” A discipline for Software Engineering,” Addison Wesley, 1995  [2] Watts S. Humphrey,”Introduction to the Personal Software Process,” Addison Wesley, 1997  [2] SEI, PSP lecture materials, 2004

98. 2004-07-26 98/98 Thank you