Employees are motivated intrinsically as well as extrinsically. Intrinsic motivation is crucial when tacit knowledge in and between teams must be transferred. Organizational forms enable different kinds of motivation and have different capacities to generate and transfer tacit knowledge. Since knowledge generation and transfer are essential for a firm s sustainable competitive advantage, we ask specifically what kinds of motivation are needed to generate and transfer tacit knowledge, as opposed to explicit knowledge.

Construct validity is about the question, how we know that we're measuring the attribute that we think we're measuring? This is discussed in formal, theoretical ways in the computing literature (in terms of the representational theory of measurement) but rarely in simpler ways that foster application by practitioners. Construct validity starts with a thorough analysis of the construct, the attribute we are attempting to measure. In the IEEE Standard 1061, direct measures need not be validated. "Direct" measurement of an attribute involves a metric that depends only on the value of the attribute, but few or no software engineering attributes or tasks are so simple that measures of them can be direct. Thus, all metrics should be validated. The paper continues with a framework for evaluating proposed metrics, and applies it to two uses of bug counts. Bug counts capture only a small part of the meaning of the attributes they are being used to measure. Multidimensional analyses of attributes appear promising as a means of capturing the quality of the attribute in question. Analysis fragments run throughout the paper, illustrating the breakdown of an attribute or task of interest into sub-attributes for grouped study.

The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work. Published studies typically use data collected using the PSP to draw quantitative conclusions about its impact upon programmer behavior and product quality. However, our experience using PSP led us to question the quality of data both during collection and its later analysis. We hypothesized that data quality problems can make a significant impact upon the value of PSP measures---significant enough to lead to incorrect conclusions regarding process improvement. To test this hypothesis, we built a tool to automate the PSP and then examined 89 projects completed by ten subjects using the PSP manually in an educational setting. We discovered 1539 primary errors and categorized them by type, subtype, severity, and age. To examine the collection problem we looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time ...

In recent years, a growing number of software organizations have begun to focus on applying the concepts of statistical process control (SPC) to the software process, usually as part of an improvement program based on the Software CMM. There are a number of technical challenges to the successful use of these statistical techniques, primarily centered on the issues associated with high variation between individual software professionals. A growing number of organizations, however, are demonstrating that SPC techniques can be applied to the software process, even if questions remain on the specific processes, measures, and statistical techniques that will provide significant business value. This paper illustrates the application of the XmR control chart to the Personal Software Process. SM Introduction During the last decade, the focus of software process improvement has been on fundamental project management and organizational learning issues. In recent years, more mature organizati...

The software industry and academia believe that software review, specifically Formal Technical Review (FTR), is a powerful method for improving the quality of software. FTR traditionally is a manual process. Recently, computer mediated support for review has had a large impact on review. Computer support for FTR reduces the overhead of conducting reviews for reviewers and managers. This reduction in overhead increases the likelihood that software development organizations will adopt FTR. Computer support of FTR also allows for the easy collection of empirical measurement of process and products of software review. These measurements allow researchers or reviewers to gain valuable insights into the review process. With these measurements reviewers can also derive a simple measure of review efficiency. A very natural process improvement goal might be to improve the numerical value of review efficiency over time.

According to many best practices frameworks for quality management and process improvement, statistical thinking is an intrinsic part of building organizational capability. In all of these frameworks there is a degree of flexibility in how the statistical thinking concepts are implemented, because these frameworks apply to many different contexts. Flexibility, however, also leads to ambiguity and inconsistency. The purpose of this article is to identify what has been observed in some organizations implementing statistical thinking. These observations can be lessons learned to help accelerate the learning curve for others implementing these frameworks.

hod, focuses on the individual software engineer. In PSP, software engineers record the time they spend programming, the defects they find in their software and the size of the software. Based upon these measurements, the engineer can track their productivity, make better predictions for future projects, gain insight to what types of 1 errors they make, and learn how to remove defects earlier in their development process. The PSP, as described by Humphrey, is a manual process. The engineer records, transfers and analyses the data all on paper forms. After many projects, the engineer accumulates a large paper database of their historical data. After using the PSP for two years, we noticed three general problems. First, we started to question the quality of the data recorded. We noticed that we did not record all of our defects, in part because the overhead of recording each defect is too expensive. Anne Disney and Philip Johnson conducted a study to look at the data quality of

Software developers work too hard and yet do not get enough done. Developing high quality software efficiently and consistently is a very difficult problem. Developers and managers have tried many different solutions to address this problem. Recently their focus has shifted from the software organization to the individual software developer. The Personal Software Process incorporates many of the previous solutions while focusing on the individual software developer. I combined ideas from prior research on the Personal Software Process, Formal Technical Review and my experiences building automated support for software engineering activities to produce the Leap toolkit. The Leap toolkit is intended to help individuals in their efforts to improve their development capabilities. Since it is a light-weight, flexible, powerful, and private tool, it allows individual developers to gain valuable insight into their own development process. The Leap toolkit also addresses many measurement and d...

This paper presents a study designed to investigate the occurrence of certain kinds of errors in Java[5] programs using JavaWizard (JWiz), a static analysis mechanism for Java source code. JWiz is a tool that supports detection of certain commonly occurring semantic errors in Java programs. JWiz was used within a research framework designed to reveal (1) knowledge about the kinds of errors made by Java programmers, (2) differences among Java programmers in the kinds of errors made, and (3) potential avenues for improvement in the design and/or implementation of the Java language or environment. We found that all programmers inject a few of the same mistakes into their code, but these are only minor, nondefect causing errors. We also found that the types of defects injected vary drastically with no correlation to program size or developer experience. Finally, we found that for those developers who make some of the mistakes that JWiz is designed for, JWiz can be a great help, saving s...

The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work and to produce empirically based evidence for the improvement of planning and quality in future projects. Published studies have suggested that adopting the PSP results in improved size and time estimation and in reduced numbers of defects found in the compile and test phases of development. However, personal experience using PSP in both industrial and academic settings caused me to wonder about the quality of two areas of PSP practice: collection and analysis. To investigate this I built a tool to automate the PSP and then examined 89 projects completed by nine subjects using the PSP in an educational setting. I discovered 1539 primary errors and analyzed them by type, subtype, severity, and age. To examine the collection problem I looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time Recording Logs and Defect Rec...