1 / 36

Personal Design and Development Software Process PD 2 SP

Personal Design and Development Software Process PD 2 SP. “The unexamined life is not worth living.” Plato. Cynics’ Guide to Personnel Management. Those who work get to keep their jobs. Raises become effective when you do. It’s better for you to tell them than for them to find out.

vita
Download Presentation

Personal Design and Development Software Process PD 2 SP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Personal Design and Development Software ProcessPD2SP “The unexamined life is not worth living.” Plato

  2. Cynics’ Guide to Personnel Management • Those who work get to keep their jobs. • Raises become effective when you do. • It’s better for you to tell them than for them to find out.

  3. How do you meet expectations and still have a life?

  4. What It Means to be Effective • As software professionals you must know your own performance. • You should measure, track, and analyze your work. • You should learn from your performance variations. • You should incorporate these lessons in your personal practices.

  5. Introduction • Measure and analyze your personal design and development software process (PD2SP). • Use process data to improve your personal performance. • Understand variation in your work patterns. • Plan and estimate software development tasks.

  6. What Metrics Do You Need? • Time: • Class, Prep for class, Recording time, Design time, Planning Time, Programming, Debugging. • Provide both planned and actual times. • Code: Quality and Quantity. • Results: Demonstrated Correct, Complete Code.

  7. Cost of PD2DP • The time required to learn and use it. • The emotional cost of maintaining the needed discipline. • The potential risk to your ego.

  8. Benefits of PD2DP • The insight you gain into your talents and abilities. • The stimulation of an almost unlimited stream of ideas. • The framework provides for personal improvement. • The degree of control you gain over your time and work. • The feeling of pride and accomplishment. • An improved basis for effective teamwork. • The conviction to do the job the way you know you should.

  9. By the end of the semester: • You will understand some methods are effective for you. • You will do better work. • You will have long-term improvement goals.

  10. PD2SP Principles • The quality of a software system is governed by the quality of its worst components. • The quality of a software component is governed by the individual who developed it. • You are governed by your • knowledge • discipline • commitment

  11. What do you know about your software development skills? • Can you • Design, estimate, and plan your work? • Meet your commitments? • Resist unreasonable commitment pressures? • Do you • Understand your ability? • Have an improvement plan?

  12. A PD2SP Also Provides • A basis for developing and practicing industrial-strength personal disciplines. • A discipline that shows you how to improve your personal process. • The data to continually improve the productivity, quality, and predictability of your work.

  13. What is a PD2SP? • A personal process for developing software • defined steps • forms • standards • A measurement and analyses framework to help you characterize your process • A defined procedure to help you to improve your performance

  14. SEI Capability Maturity Matrix • Broadly agreed-upon definition of how a software organization matures and improves. • Based on manufacturing process improvement and “best practices” from software engineering • Some dramatic successes.

  15. Each key process area has five common features: • Goals to be achieved; • Ability to perform; • Activities performed; • Measurement and analysis; • Verification

  16. PD2SP Overview

  17. PD2SP Overview • Since this is so late in your education, can’t do it all in one course. • Focus on how to make your more efficient in time • We’ll just do the first step.

  18. PD2SP0 Identify your current software development process including: • Planning - Produce a plan to do the work. • Development - The actual software development. • Postmortem - Comparison of actual performance with your plan.

  19. The measurements will be • Based on your current process. • Measure where you spend the bulk of your time. We will use minutes as the base granularity for data to be meaningful. • Defect Recording. A defect recording log is used to hold data on each defect found and corrected.

  20. Don’t Panic You will NOT be graded on how long it takes or how many defects you find

  21. ThePD2SP0 Summary • Your original estimate of the LOC you expect to develop. • The actual LOC you developed. • Your original estimate of the time required for each phase. • The actual time required for each phase. • The total number and the percent of defects injected in each phase. • The total number and the percent of defects removed in each phase

  22. Task Planning • Task planning involves estimating the development time and completion data for each project task. • It also provides a basis for tracking schedule progress.

  23. Process • Time and Schedule Management • Requirements Management • Design and Work Breakdown Structure • Development • Reporting • Earned Value Estimation

  24. Time and Schedule Management • Enter initial project data in the project plan summary (PDSP0). • Complete Initial Time Schedule Template (SPT). • Begin Time Recording (TRT).

  25. Requirements Planning • Complete the Requirements Work Template (RWT) in the Excel workbook. • Constraints are logical statements • Criteria are performance statements

  26. Design and Work Breakdown • Use developed requirements document. • Complete a Work Breakdown Structure • Estimate the required development time. • Complete the task plan (WBS).

  27. Reporting • Complete the project plan summary with actual time, defect, and size data. • Complete the PIP (PD2SP0). • Coding Standard • Size measurement • Process improvement Proposal

  28. Rules of the Game • Please keep accurate track of time. • YOU WILL NOT BE GRADED ON YOUR TIME OR QUALITY from this report!! Quality measurement comes from testing • Keep your programs simple. You will learn as much from small programs as from large ones. • Keep your reports and standards simple and short. • Do not hesitate to copy or build on the PD2SP materials.

  29. Rules of the Game II • Do it right the first time. If you are not sure, find out. • Software is not a solo business so you do not have to work alone. • You must, however, produce your own estimates, designs, and code. • You may have others review your work and you may change it as a result. You should note this help in your process report, include the review time you and your associates spend, and log the defects found.

  30. Grading • Your process report must be: • complete • legible • in the specified order • Your process data must be: • accurate • precise • self-consistent

  31. The PD2SP0 Process • A simple defined personal process • Use your current design and development methods. • Gather data on your work: • time spent by phase • defects found in compile and test

  32. Prepare a summary report. • A project plan summary form • A process script • A time recording log • A defect reporting log • A defect type standard

  33. More Process • Planning - estimate development time • Development - develop the product using your current methods • Postmortem - complete the project plan summary, with the time spent and defects found and injected in each phase. • Design - design the program, using your current design methods

  34. The End of the Beginning

  35. Defect type standard • Date defect was found. • Defect number. • Defect type (documentation, syntax, assignment, interface, etc.). • Phase where defect was injected. • Phase where defect was removed. • Time it took to fix the defect. • If injected while fixing another defect, that defect’s number. • A succinct description of the defect. The project plan summary holds the estimated and actual project data.

  36. The defect types • Documentation • Syntax • Assignment • Interface • Checking • Data • Function • Environment

More Related