Improvement of individual processes

zhaozj2021-02-16  54

Improvement of individual processes

Personal Process IMPROVEMENT

Karl E. Wiegers

Process effect

Www.processimpact.com

(Note: This article was originally published in "Software Development" magazine in May 2000. This "Software Development" magazine is allowed, and it will be published again.)

Currently, the process improvement is the hottest topic in the software field. However, many developers are not working in the management-driven process improvement organization. Maybe you work in a severe environment affecting the pressure of daily projects, you won't spend energy for future projects than now. What kind of work can I do for an isolated individual software process?

Even if there is no formal management rules or leadership, you can also take several measures to improve your individual software engineering methods, speed up the development process of the work group. It turns out that you will eventually affect people outside the project team. But you will save time for you to improve your ability, reduce modifications to improve productivity. Watts Humphrey's Individual Software Process (Personal Software Process) provides you with an effective way to enhance development capabilities (refer to the Software Engineering Specifications "published by Addison-Wesley Publishing House 1995), but not everyone meets harsh PSP requirements. Prepare the task periodically.

It is recommended that you take time to learn and apply PSP knowledge, but don't spend a lot of money on tools and training. Selective adopts some common means as individual development habits and gives them to the team members to explain them. Don't promote your software development knowledge, skills, and means by forcing others' compliance. Because, when you get better results than previous results, others will notice that they will follow.

Project planning and tracking

Most developers have to assess their work, but regret is that they are very proficient in assessment. I will write down your plan progress and efforts as an assessment of personal tasks and actual results. Compare the two groups of data and find the gap, which will help you improve your assessment. You can also develop an individual assessment method, such as a method of evaluating the number of programs, such as classes, methods, or GUI screens and windows. Data and experience are more assumed to make you a good assessment. Analysis data also helps you adjust the schedule of the management project. Time schedule may still be inconsistent with your initial progress, but it is better than you to evaluate more than your personal experience.

To further improve individual assessment capabilities, you can establish a plan checklist for public project activities, such as implementing a class, performing a system test or making a product based on the components stored in the configuration management system. This checklist will help you prevent ignition of the necessary tasks, causing too low assessments. While updating this checklist, you also grow experience.

In fact, because no one will spend more than 40 hours a week and track you how to use time on the project. Therefore, you have to write down the hours that spend daily during the development or maintenance phase. Don't be accurate to every minute, so you will find how much you really use the effective project time for a week. This hourly number converts the evaluation of task efforts (in labor time) to the evaluation of the calendar. When planning, remember to leave time for quality activities, conferences, other tasks, and inevitable modifications.

Even if you can't do a detailed project plan, you have to write a short task description to ensure that you don't ignore the steps that need to be executed. You can guarantee the project development record to ensure that each project is tracked, without self-righteousness, has completed the task, and left a big pile. When you complete a project or complete one of the stages, with the group members a review, find out which parts are progressing smooth, which can be further improved. This is the essence of process improvement. In addition, it is difficult to determine the difficulties you may encounter in future projects.

demand

Individual developers are often unable to control the software needs in front of them. Therefore, you should work hard and provide assistance to establish partnerships, whether they are marketers, business analysts, managers or actual users. Check all the needs before starting the project, carefully check whether each function is required to design and complete all the information. Find out a blurred language that is likely to cause you subjective precaution. These unclear places are likely to make you unable to meet our customers' expectations. Note the following fuzzy words: support, for example, with / or, etc., including, many, many, user friendly, simple, typical, standard, usually fast, strong, flexible, effective and improved. When you don't sure the purpose of a requirement, you must ask. Point out that you don't sure what customers need, don't ask for questions repeatedly, or re-establish the system when you guess wrong. Find out an extra condition that is not indicated. Consider whether you can test each requirement by testing or other ways. This strict check will allow you to find out the needs of the analyst or customer in demand.

When it is convinced that each of the prerequisites are mastered, you can implement these needs in a reasonable order. It is best to complete the prerequisite formulation through the common cooperation of customer representatives and technicians (refer to "Software Development" magazine in September 1999 "First Things First: Prioritizing Requirements). The client is evaluated by an example of analyzing or give special provisions to assess the value of each requirement. At the same time, developers can determine the cost and technical difficulty of achieving each requirement.

Maybe you will find that the demand document given by the marketing staff or business analysts cannot meet your requirements, because these documents are loose, lack of substantive information or decentralize your attention to key content attention. And you will often find that the key documentation between the different groups is just based on the understanding of the document author. For example, marketers may write a marketing demand document that they seem to be reasonable but contain too many defects that cannot be used by the next segment. This is probably because they ignore the use of the range and limitations of the product usage, or the information of the product usage is lacking, or the reason for the quality characteristics of the contradiction is described.

Try to work with those who can provide you with key documents, and reach a consensus on the document model to meet the requirements of developers. You have to explain why good document structures or content will reduce the modified workload to accelerate the development speed. This is the first step that makes a key document as simple as possible.

Some fancy features users may like it, but you have to avoid these additional features. Because "Gold Plate" will increase the development cost of the product, it will not increase the value of the product. Similarly, representatives to the customer indicate that you think, let them make an assessment to prevent them from proposing other possible needs. After you start working, if the customer wants to add new features or to change the needs, you have to make our customers understand the new cost and workload. These needs are not implemented before the "a public version of the customer is related to the product or the release of the product or the binding". If the customer wants some small changes, you have to add these changes to the change in the process of the project. This will ensure that you have achieved excellent business results, and these results include the most reasonable changes, thereby increasing your group to meet the requirements of the project requirements.

Design and encoding

The most difficult part of programming is not typing but design. Detaver time design before implementing the software, avoiding the modification software in order to make the software meet the functional and performance requirements. The first plan cannot generate the most suitable design. Therefore, I will study for a long time before modifying the design. Understand, adopt and share those standard design methods with colleagues. Unified Modeling Language (UML) is the popular design language today, but traditional structured modeling techniques are still valid within a certain range.

The model is the foundation of communication, so avoids yourself to create a design method. Using those already existing rules can make communication more efficient; there is no software barrier problem. As a member of the team, members will agree on design methods and tools, which will help you get a robust software design. Using reasonable software design principles, such as strong internal strength, weak coupling, information hiding, etc.

You have to be familiar with programming tools. In fact, after understanding a language, editor, compiler, and other tools, you can improve efficiency and enhance the ability to develop high quality codes. Each programmer will think that your coding style is the best, otherwise, if they know more, they will not continue to keep their own style. Even so, we have to learn from the master and improve our original programming method. Read some classic programming books, such as Steve McConnell, "Code", "Code Complete", Microsoft Press, 1993), Jon Bentley "Programming Pickup (Second Edition)" ("Programming Pearls, 2nd Edition ", Addison-Wesley Press, 1998), Donald Knuth's Three Volumes of" The Art of Computer Programming, 3rd Edition ", Addison-Wesley Press, 1998). Under these huge guidance, persist in compliance with the rules, you will form a reasonable coding standard and good structural skills. For example, after I saw a better annotation method in "Code Daquan", I have modified my own comment style. I know that the original style is not very good, even if it looks quite like. Looking for a better way, this belief is encouraged to face their own shortcomings, overcome all difficulties and constantly improve.

In version control, you have to maintain the source code of the project and other key documents, adopt a good access / exit check configuration management system. When checking a module, you have to record the reason you make changes. Do not enter only a string fixed character or empty character in order to save typography in a few seconds. Write the system's writing process documentation, automate, enabling any of the programs in the project. Cultivate the habit of testing the new program, using the automatic "smoke" test method, find the original bug.

Quality test

Each developer is responsible for its work. Unfortunately, a very small number of developers have received sufficient training in quality analysis and measurement, testing and technical inspection. You can read some books about software testing, such as Brian Marken's Software Test Process ("The Craft of Software Testing", Prentice Hall Press, 1997). Then use the knowledge learned to be flexible to your own work. When you say the test of a program, make sure you mean. Have you been out of time? Do you have any tests made by the program? Or do you have a consciously selected quality screening method and test range?

Effective unit testing is another important technique. I have helped a programmer, he spent three weeks to test a program, but did not do any records. We have to start doing all the tests because we don't know what tests he has already made.

Typically, you can also find errors in your code only. You can record your test results in the form of code annotations, so that these test results can be reused. Use automated test tools to accelerate regression test, such as functions and methods that can be called through conditional compilation. When you modify a program, make sure there is no other error by performing these regression tests. Record the complete system test conditions, so as not to do it later, while others have accurately test your program when necessary. When you find an error, add a new test condition to help you verify each patch to form a robust regression test package.

Use quality tools to help you clear the code as much potential problem as possible. At least, you have to use the code static analysis tools such as CodeReview for Visual Basic and Parasoft Codewizard in the Numega series of Gimpel software companies in the United States, CodeWizard, which might find compilers and temporary visual scans Leaked tiny errors. A developer once told me that when his group workers run their procedure in Lint, the Lint reported 10,000 errors and warnings. 100,000 errors and warnings were discovered, which showed me that there were some quality problems. The "ostrich" method did not make the program more reliable. Even if you don't have to use the LINT tool, you must pay attention to and correct the errors and warnings found by the compiler. A best programmer I have learned before taught me to set the compiler to the most rigorous level and listen to everything you tell you. Your developers should use the same strict compiler settings and do it once to change the errors and warnings immediately. If your code has an error, turn it now when it is cheap, so as not to pay the cost of pain.

Another type of quality tool is a dynamic code analyzer. For example, Rational Software's Purify, COMPARE Software Numega Series Boundschecker and Parasoft's Insure . These tools can discover errors at runtime, like memory overflow, write array offshore, and pointer types do not match errors. These tools cannot detect errors or logical errors that are not designed by user needs, but they can help you shorten the debugging time and reduce the dissatisfaction of users.

Test between colleagues is also an effective technique for improving quality of work products. Find some colleagues you respect and personal comparative trust, began to check each other's needs, design, code, and testing. Listen to the lessons of the software test, then introduce these regular tests into your group. Many people complain that test is spent too much time. Although they take time, but test can effectively find defects, anyone who has got this benefit never wants to be programmed. Testing will not waste your time --- but bug will. (to be continued)

转载请注明原文地址:https://www.9cbs.com/read-23073.html

New Post(0)