personal software process

What is a personal software process?
Why does engineers uses PSP?

Personal software process is a process framework and a set of methods that
help engineers be more disciplined in their work. It shows them how to estimate and plan their projects, measure and track their work, and improve the quality of the products they produce.
It shows engineers how to manage quality from the beginning, how to analyze the results of each job and how to use the results to improve the process for the next project. Engineers also gain personal experience with process improvement. They become process owners in the measurement, management, and improvement of the software process. PSP helps engineers to find and remove defects where they are injected, before compile, inspection, unit test, integration
test, or system test. With fewer defects to find and remove in integration and system test, test
costs are reduced sharply, schedules are more predictable, fewer defects are released to the
field, maintenance and repair costs are reduced, and customer satisfaction is increased. Cost and schedule problems begin when projects make commitments that are based on inadequate estimates of size and development resources. PSP addresses this problem by showing engineers how to make better size and resource estimates using statistical techniques and historical data.

Team Software Process was developed to address the commitment, control, quality and teamwork problems faced by the software development teams. By working together in a team software, they are able to giving management and the customer a good idea of how
much effort would be involved in producing the desired software product. This can eliminate wasted time and effort because potential problems can be identified up front instead
of later when time and resources have already been wasted. Personal Software Process is very important because they learn to become more efficient engineers producing quality software products on schedule.

CMM (capability maturity model) and PSP are supportive with each other. With PSP, engineers practice twelve of eighteen key process areas. PSP training can also help accelerate an organization’s process improvement program. PSP consists of a series of scripts that define tasks of forms for recording data and of standards such as coding practices, size counting, and the assignment of defect types. When engineers follow PSP, they first plan their work and document the plan. As they do their work, they record their times and track and report every defect they find. At the end of the project, the engineers do a postmortem analysis and complete a project plan summary report. Three aspects of PSP’s quality improvements are: First, by tracking all defects, engineers are sensitized to the mistakes they make and become more careful in their work. Second, when they analyze their defect data, they gain a clearer understanding of the cost of removing defects and apply the most effective ways of finding and fixing them. And third, PSP introduces a number of quality practices that have proven effective in preventing defects and in efficiently finding and fixing them.

In the first level of PSP 0, engineers follow their current practices, learning some basic
PSP techniques. This level covers how to record development time and how to log each compile and- test defect. These measurements are used in process analysis and planning and as a benchmark for assessing improvement.

PSP 0.1 level adds size measurement and the process improvement proposal, a form that
the engineers use to record the process problems they encounter as well as their ideas for addressing them. In the planning step, programmers produce a plan to perform work. The four development steps are design, code, compile and test. The last step, postmortem, allows programmers to compute his actual performance and compare those values with his plan and produce a summary report. In the first level, engineers essentially follow their current practices, learning some basic PSP techniques. This level covers how to record development time and how to log each compile and- test defect. These measurements are used in process analysis and planning and as a benchmark for assessing improvement.

In PSP 1 level, engineers are introduced to the PROBE method. This method uses

historical data to estimate size and determine the accuracy of the estimate. PSP1 changes the planning phase to include conceptual design, size estimation, and time estimation. The user now records planned values for all LOC measures and uses the size estimate to derive planned time for the project. PSP1 also changes the test phase by the introduction of a Test Report Template which allows the user to record data about tests run, data used, and results.

The PSP 1.1 level adds resource and schedule estimating and earned-value tracking. Earned-value tracking allows them to weight the importance of each task and to judge their progress as they finish some tasks early and others late. For projects requiring several days or more, PSP1.1 provides support for breaking the project down into tasks and then scheduling the tasks across available days. This is done using two new forms: the Task Planning Template and the Schedule Planning Template. The user must also calculate new process statistics on the Project Plan Summary.

The PSP 2 level introduces design and code reviews, quality measurement and evaluation. Using defect data from their earlier exercises, engineers also develop personal design and code review checklists. The emphasis of PSP 2 moves from improving estimation to improving the actual quality of the finished product.

In PSP 2.1 level, engineers learn design specification, techniques and ways to prevent defects.
For large projects, PSP 3 is designed for cyclic development. In PSP 3 highest process level, it covers design verification techniques and methods for adapting PSP to engineers’ working environments.

There are other major approaches for comparing PSP such as waterfall development, agile development, ratified unified process (RUP). We have developed a framework to utilize Six Sigma techniques in the PSP and TSP practices to support process improvement activities at the individual and team levels. Six Sigma techniques in general provide statistical analysis and decision-making supports that can be employed for data analysis, continuous improvement, and process control. Agile development is effective only for project below 2,500 function points; they lose their effectiveness faster above 10,000 function point range and harmful at that size. Waterfall development takes too long and lacks the flexibility required for today's fast-paced software market and development environment. Waterfall projects take months or years, and by the time they're finished, it's sometimes found that the requirements have changed or that the original requirements were off the mark to begin with. The result can be expensive, budget-busting fixes. In agile software projects, project management takes a slightly different form, relying far more on the project manager’s skills in communication and emphasizing far less on planning and control. RUP is an accurate, four-phase software development process which is iterative and incremental rather than the large amounts of documentation required for each stage of Waterfall. An automatic PSP tool would add efficiency. Time and defect data collection is simplified. The calculations required by the PSP become automatic. Any form can be accessed immediately. Data is transferred automatically to all applicable forms, eliminating the need to copy data by hand. Timing can be easily being made more precise than minutes. An automated task guide can be implemented. Proper editing facilities can make errors easy to correct. The user could customize the PSP to his or her own practice, creating a profile that can easily be saved to disk. Historical data is automatically saved and ready for analysis.

Personal Software Process is the best practice and the greatest success with fewer than 1,000 function points compared to above major approaches.

There is an alternative to personal software process. For example, Collaborative Software Process (CSP) is one alternative. The two programmers can work side-by-side at one computer, collaborating on the same design, algorithm, code or test is very effective. One of the programmers, the driver, has control of the keyboard/mouse and implements the program. The other programmer, the observer, continuously observes the work of the driver to identify defects, and also thinks about the direction of their work. On demand, the two programmers can brainstorm any challenging problem. The two programmers periodically switch role, they work together as equals to develop software.

There are still many issues that remained unsolved. PSP needs to be integrated with architecture design and evaluation methods. This process integration will result in better management of cost, schedule, and project risks be scaled in terms of functionality.
Automated data collection is not good enough to support the data collection. An enhanced and intelligent tool support is needed where it can automatically know what a user is doing and able to capture the time while the user is working. This feature can be provided by making the user’s development environment responsive or use intelligent agents to collect the data automatically for the user. This feature can also identify what files are associated with which projects, have the ability to parse the source code and can detect some defects and know whether the user is busy or idle. Another feature that may be provided is implementing an intelligent agent. The intelligent agent can look and analyze the user’s current and historical project data and report on interesting patterns that it notices. It could track the progress against user’s estimation and alert the user if he or she is running over or under budget. A timer function can be extended into the Defect Recording Log. In this context, the timer function is capable of capturing the time spent on fixing a defect, and then automatically inserts the value in the Defect
Recording Log. This function will offer better and more accurate value for the new system.
More advanced line of code (LOC) counter can be used to improve the system in the future. The capability of the new automatic LOC counter is not limited to counting the lines of code only but to keep track of the added, deleted and changed lines of code in multi-version programs. This can be very helpful in large software projects. The LOC counter will automatically store all these values in the project Plan summary. LOC counter should support multi-programming language type since there are many different programming languages employed by engineers in their software development work.

PSP has adoption issues. PSP is a manual process because PSP forms must be filled out by hand, either by editing a copy of the form on-line, or by filling out a printed copy with pen or pencil. Even if tools such as spreadsheets are used to collect historical data and to provide various computations, if they do not automatically insert and maintain the correct calculated values in the appropriate places in the forms, then the technique is still considered as manual.
The future research may focus on some interesting issues. PSP contains basic personal skills of software engineers while the real world software projects are done by teams. Therefore, we need to deliver the follow-up courses to help students apply PSP in team settings. An automatic PSP tool would add efficiency in many ways. Time and defect data collection can be simplified. The calculations required by the PSP can be automatic. Any form can be accessed immediately. Data is transferred automatically to all applicable forms, eliminating the need to copy data by hand. Timing can easily be made more precise than minutes. An automated task guide can be implemented. Proper editing facilities can make errors easy to correct. The user could customize the PSP to his or her own practice, creating a profile that can easily be saved to disk. Historical data is automatically saved and ready for analysis. Future empirical research needs to investigate how to fully play the advantages of cooperative learning.

.

Computer (IT) Technician Services © 2018