Download PSP2.1 Process Script, Codes and Instructions-Software Quality-Handout and more Exercises Software Development Methodologies in PDF only on Docsity!
PSP2.1 Process Script
Purpose To guide the development of module-level programs Entry Criteria - Problem description
- PSP2.1 Project Plan Summary form
- Size Estimating template
- Historical size and time data (estimated and actual)
- Time and Defect Recording logs
- Defect Type, Coding, and Size Measurement standards
- Stopwatch (optional)
Step Activities Description 1 Planning - Produce or obtain a requirements statement.
- Use the PROBE method to estimate the added and modified size and the size prediction interval of this program.
- Complete the Size Estimating template.
- Use the PROBE method to estimate the required development time and the time prediction interval.
- Complete a Task Planning template.
- Complete a Schedule Planning template.
- Enter the plan data in the Project Plan Summary form.
- Complete the Time Recording log. 2 Development - Design the program.
- Document the design in the design templates.
- Review the design, and fix and log all defects found.
- Implement the design.
- Review the code, and fix and log all defects found.
- 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. 3 Postmortem Complete 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 Size Estimating and Task and Schedule Planning templates
- Completed Design templates
- Completed Design Review and Code Review checklists
- Completed Test Report template
- Completed PIP forms
- Completed Time and Defect Recording logs
PSP2.1 Planning Script
Purpose To guide the PSP planning process Entry Criteria - Problem description
- PSP2.1 Project Plan Summary form
- Size Estimating, Task Planning, and Schedule Planning templates
- Historical size and time data (estimated and actual)
- Time Recording log
Step Activities Description 1 Program Requirements
- Produce or obtain a requirements statement for the program.
- Ensure that the requirements statement is clear and unambiguous.
- Resolve any questions. 2 Size Estimate
- Produce a program conceptual design.
- Use the PROBE method to estimate the added and modified size of this program.
- Complete the Size Estimating template and Project Plan Summary form.
- Calculate the 70% size prediction interval. (You may use a spreadsheet.) 3 Resource Estimate
- Use the PROBE method to estimate the time required to develop this program.
- Calculate the 70% size prediction interval. (You may use a spreadsheet.)
- Using the To Date % from the most recently developed program as a guide, distribute the development time over the planned project phases. 4 Task and Schedule Planning
For projects lasting several days or more, complete the Task Planning and Schedule Planning templates. 5 Defect Estimate
- Based on your to-date data on defects per added and modified size unit, estimate the total defects to be found in this program.
- Based on your To Date % data, estimate the number of defects to be injected and removed by phase.
Exit Criteria -^ Documented requirements statement
- Program conceptual design
- Completed Size Estimating template
- For projects lasting several days or more, completed Task and Schedule Planning templates
- Completed Project Plan Summary form with estimated program size, development time, and defect data, and the time and size prediction intervals
- Completed Time Recording log
PSP2.1 Design Review Script
Purpose To guide you in reviewing detailed designs Entry Criteria - Completed program design documented with the PSP Design templates
- Design Review checklist
- Design standard
- Defect Type standard
- Time and Defect Recording logs General Where the design was previously verified, check that the analyses
- covered all of the design
- were updated for all design changes
- are correct
- are clear and complete
Step Activities Description 1 Preparation - Examine the program and checklist and decide on a review strategy.
- Examine the program to identify its state machines, internal loops, and variable and system limits.
- Use a trace table or other analytical method to verify the correctness of the design. 2 Review - Follow the Design Review checklist.
- Review the entire program for each checklist category; do not try to review for more than one category at a time!
- Check off each item as you complete it.
- Complete a separate checklist for each product or product segment reviewed. 3 Fix Check - Check each defect fix for correctness.
- Re-review all changes.
- Record any fix defects as new defects and, where you know the defective defect number, enter it in the fix defect space.
Exit Criteria - A fully reviewed detailed design
- One or more Design Review checklists for every design reviewed
- Documented design analysis results
- All identified defects fixed and all fixes checked
- Completed Time and Defect Recording logs
PSP2.1 Postmortem Script
Purpose To guide the PSP postmortem process Entry Criteria - Problem description and requirements statement
- Project Plan Summary form with program size, development time, and defect data
- For projects lasting several days or more, completed Task Planning and Schedule Planning templates
- Completed Test Report template
- Completed Design templates
- Completed Design Review and Code Review checklists
- Completed Time and Defect Recording logs
- A tested and running program that conforms to the coding and size measurement standards
Step Activities Description 1 Defect Recording - Review the Project Plan Summary to verify that all of the defects found in each phase were recorded.
- Using your best recollection, record any omitted defects. 2 Defect Data Consistency
- Check that the data on every defect in the Defect Recording log are accurate and complete.
- Verify that the numbers of defects injected and removed per phase are reasonable and correct.
- Determine the process yield and verify that the value is reasonable and correct.
- Using your best recollection, correct any missing or incorrect defect data. 3 Size - Count the size of the completed program.
- Determine the size of the base, reused, deleted, modified, added, total, added and modified, and new reusable code.
- Enter these data in the Project Plan Summary form. 4 Time - Review the completed Time Recording log for errors or omissions.
- Using your best recollection, correct any missing or incomplete time data.
Exit Criteria -^ A thoroughly tested program that conforms to the coding and size measurement standards
- Completed Design templates
- Completed Design Review and Code Review checklists
- Completed Test Report template
- Completed Project Plan Summary form
- Completed PIP forms describing process problems, improvement suggestions, and lessons learned
- Completed Time and Defect Recording logs
PSP2.1 Project Plan Summary (continued)
Student Program #
Time in Phase (min.) Plan Actual To Date To Date % Planning Design Design Review Code Code Review Compile Test Postmortem Total Total Time UPI (70%) Total Time LPI (70%)
Defects Injected Plan Actual To Date To Date % Planning Design Design Review Code Code Review Compile Test Total Development
Defects Removed Plan Actual To Date To Date % Planning Design Design Review Code Code Review Compile Test Total Development After Development
Defect Removal Efficiency Plan Actual To Date Defects/Hour − Design Review Defects/Hour − Code Review Defects/Hour − Compile Defects/Hour − Test DRL (DLDR/UT) DRL (Code Review/UT) DRL (Compile/UT)
PSP2.1 Plan Summary Instructions
Purpose To hold the plan and actual data for programs or program parts General - Use the most appropriate size measure, either LOC or element count.
- “To Date” is the total actual to-date values for all products developed.
- A part could be a module, component, product, or system.
Header -^ Enter your name and the date.
- Enter the program name and number.
- Enter the instructor’s name and the programming language you are using. Summary -^ Enter the added and modified size per hour planned, actual, and to-date.
- Enter the planned and actual times for this program and prior programs.
- For planned time to date, use the sum of the current planned time and the to-date planned time for the most recent prior program.
- CPI = (To Date Planned Time)/(To Date Actual Time).
- Reuse % is reused size as a percentage of total program size.
- New Reusable % is new reusable size as a percentage of added and modified size.
- Enter the test and total defects/KLOC or other appropriate measure.
- Enter the planned, actual, and to-date yield before compile. Quality Indicators - Appraisal COQ: the percentage of development time in reviews.
- Failure COQ: the percentage of development time in compile and test.
- A/FR: the ratio of appraisal to failure COQ.
- Enter the planned, actual, and to-date PQI (the process quality index) Program Size -^ Enter plan base, deleted, modified, reused, new reusable, and total size from the Size Estimating template.
- Enter the plan added and modified size value (A+M) from projected added and modified size (P) on the Size Estimating template.
- Calculate plan added size as A+M – M.
- Enter estimated proxy size (E) from the Size Estimating template.
- Enter actual base, deleted, modified, reused, total, and new reusable size from the Size Estimating template.
- Calculate actual added size as T-B+D-R and actual added and modified size as A+M.
- Enter to-date reused, added and modified, total, and new reusable size. Time in Phase - Enter plan total time in phase from the estimated total development time on the Size Estimating template.
- Distribute the estimated total time across the development phases according to the To Date % for the most recently developed program.
- Enter the actual time by phase and the total time.
- To Date: Enter the sum of the actual times for this program plus the to- date times from the most recently developed program.
- To Date %: Enter the percentage of to-date time in each phase. Prediction Interval - Enter the 70% UPI and LPI total size and time ranges. (continued)
Design Review Checklist
Student Date Program Program # Instructor Language
Purpose To guide you in conducting an effective design review General - Review the entire program for each checklist category; do not attempt to review for more than one category at a time!
- As you complete each review step, check off that item in the box at the right.
- Complete the checklist for one program or program unit before reviewing the next.
Complete Verify that the design covers all of the applicable requirements.
- All specified outputs are produced.
- All needed inputs are furnished.
- All required includes are stated. External Limits Where the design assumes or relies upon external limits, determine if behavior is correct at nominal values, at limits, and beyond limits. Logic (^) Use a trace table, mathematical proof, or similar method to verify the logic.
- Verify that program sequencing is proper. Stacks, lists, and so on are in the proper order. Recursion unwinds properly.
- Verify that all loops are properly initiated, incremented, and terminated.
- Examine each conditional statement and verify all cases. State Analysis For each state machine, verify that the state transitions are all complete and orthogonal. Internal Limits Where the design assumes or relies upon internal limits, determine if behavior is correct at nominal values, at limits, and beyond limits. Special Cases - Check all special cases.
- Ensure proper operation with empty, full, minimum, maximum, negative, and zero values for all variables.
- Protect against out-of-limits, overflow, and underflow conditions.
- Ensure “impossible” conditions are absolutely impossible.
- Handle all possible incorrect or error conditions. Functional Use - Verify that all functions, procedures, or methods are fully understood and properly used.
- Verify that all externally referenced abstractions are precisely defined. System Considerations
- Verify that the program does not cause system limits to be exceeded.
- Verify that all security-sensitive data are from trusted sources.
- Verify that all safety conditions conform to the safety specifications. Names Verify that
- all special names are clear, defined, and authenticated
- the scopes of all variables and parameters are self-evident or defined
- all named items are used within their declared scopes Standards Ensure that the design conforms to all applicable design standards.
Operational Specification Template
Student Date Program Program # Instructor Language
Scenario Number User Objective Scenario Objective Source Step Action Comments
Functional Specification Template
Student Date Program Program # Instructor Language
Class Name Parent Class
Attributes Declaration Description
Items Declaration Description
Functional Specification Template Instructions
Purpose -^ To hold a part’s functional specifications
- To describe classes, program modules, or entire programs General - Use this template for complete programs, subsystems, or systems.
- Use this template to document the functional specifications during planning, design, test development, implementation, and test.
- After implementation and testing, update the template to reflect the actual implemented product.
Header - Enter your name and the date.
- Enter the program name and number.
- Enter the instructor’s name and the programming language you are using. Class Name - Enter the part or class name and the classes from which it directly inherits.
- List the class names starting with the most immediate.
- Where practical, list the full inheritance hierarchy. Attributes - Provide the declaration and description for each global or externally visible variable or parameter with any constraints.
- List pertinent relationships of this part with other parts together with the multiplicity and constraints. Items - Provide the declaration and description for each item.
- Precisely describe the conditions that govern each item’s return values.
- Describe any initialization or other key item responsibilities. Example Items An item could be a class method, procedure, function, or database query, for example.
State Specification Template Instructions
Purpose - To hold the state and state transition specifications for a system, class, or program
- To support state-machine analysis during design, design reviews, and design inspections General - This form shows each system, program, or routine state, the attributes of that state, and the transition conditions among the states.
- Use this template to document the state specifications during planning, design, test development, implementation, and test.
- After implementation and testing, update the template to reflect the actual implemented product.
Header - Enter your name and the date.
- Enter the program name and number.
- Enter the instructor’s name and the programming language you are using. State Name - Name all of the program’s states.
- Also enter each state name in the header space at the top of each “States/Next States” section of the template. State Name Description
- Describe each state and any parameter values that characterize it.
- For example, if a state is described by SetSize=10 and SetPosition=3, list SetSize=10 and SetPosition=3. Function/Parameter - List the principal functions and parameters.
- Include all key variables or methods used to define state transitions or actions. Function/Parameter Description
- For each function, provide its declaration, parameters, and returns.
- For each parameter, define its type and significant values. Next State - For each state, list the names of all possible next states.
- Include the state itself. Transition Condition List the conditions for transition to each next state.
- Use a mathematical or otherwise precise notation.
- If the transition is impossible, list "impossible," with a note saying why. Action List the actions taken with each state transition.
Logic Specification Template
Student Date Program Program # Instructor Language
Design References
Parameters
Expanded Defect Type Standard
Purpose To facilitate causal analysis and defect prevention Note The types are grouped in ten general categories.
If the detailed category does not apply, use the general category.
The % column lists an example type distribution.
10 Documentation Comments, messages, manuals 1. No. Name Description %
20 Syntax General syntax problems 0.
- 21 Typos Spelling, punctuation 32.
- 22 Instruction formats General format problems 5.
- 23 Begin-end Did not properly delimit operation
30 Packaging Change management, version control, system build 1.
40 Assignment General assignment problem
- 41 Naming Declaration, duplicates 12.
- 42 Scope 1.
- 43 Initialize and close Variables, objects, classes, and so on 4.
- 44 Range Variable limits, array range 0.
50 Interface General interface problems 1.
- 51 Internal Procedure calls and references 9.
- 52 I/O File, display, printer, communication 2.
- 53 User Formats, content 8.
60 Checking Error messages, inadequate checks
70 Data Structure, content 0.
80 Function General logic 1.
- 81 Pointers Pointers, strings 8.
- 82 Loops Off-by-one, incrementing, recursion 5.
- 83 Application Computation, algorithmic 2.
90 System Timing, memory, and so on 0.
100 Environment Design, compile, test, other support system problems
Class Specification (CS) Template
Student Date Project Program Instructor Language
Class Name: Description
Relationships with Other Classes (Super Class, Aggregates, Compositions,
Associations)
Class Name Type of Relationship
Attribute Name Access Description
Object Constraints
Method Name: Description
Access
Pre-Condition
Post-Condition
Input Parameters
Output/Return
Parameters
Exceptions
Algorithm
Method Name: Description
Access
Pre-Condition
Post-Condition
Input Parameters
Output/Return
Parameters
Exceptions
Algorithm
