D.E. Perry, N.A. Staudenmayer, and L.G. Votta, "People, Organizations, and Process Improvement," IEEE Software, July 1994, pp. 36-45.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is functioning and what shortcomings stand in the way of better performance. Thus, the metrics not only highlight what is happening but also suggest areas for process improvement [14,38] A reasonably holistic measurement program is, in fact, a prerequisite for understanding the NPD process [36]. From the perspective of groupware implementation, the easiest metrics to obtain are those which deal with (1) the volume of documents in a certain category of a domain model, 2) the duration that documents spend in the different phases of their lifecycle, and (3) combinations of these. For ....

D.E. Perry, N.A. Staudenmayer and L.G. Votta, "People, organizations and process improvement, " IEEE Software, vol. 11, no. 4, pp. 36-45, 1994.

....of a much larger number of companies. Furthermore, such studies should include a multiple respondent approach to cover all major occupational cultures. They should also perform supplementary, etlmographic studies on how developers really work and how their work relate to formal routines see [31] on observational studies of developers at ATT. 6. CONCLUSION Results from the survey reported in this paper show that software developers do not perceive formal routines alone as an efficient way to transfer knowledge and experience. Furthermore, the study confirms our suspicions about large ....

Dewayne E. Perry, Nancy Staudenmayer, and Lawrence G. Votta, "People, Organizations, and Process Improvement", IEEE Software, Vol. 11, No. 4, July 1994, pp. 36-45.

....process progresses in the real world. Other, completely different, research directions were also investigated. Several researches carried out a series of empirical studies on software process to analyze how real software factories operate and how their processes could be improved (for example see [63,64]) Cusumano [24] also did an empirical analysis of how Japanese software factories operate at a more macroscopic level. Cusumano and Selby [25] did a well known recent study analyzing how Microsoft works. Yet another approach was investigated in [1] which defined a general model for software ....

D. E. Perry, N. A. Staudenmeyer, and L. G. Votta, "People, Organizations, and Process Improvement". In IEEE Software, July 1994.

....and process information described above was modeled using a formalism called ActorDependency models (AD models) 15] This model also included the actual data collected, and allowed us to automate some of the data analysis. The process used to produce the AD model is known as prior ethnography [10], the practice of taking some time before data collection begins to become familiar with the study setting. In November and early December of 1995, the researcher attended team meetings, conducted openended interviews with several developers and managers, observed several inspection meetings ....

....the following sections and are elaborated during the discussion of results. Data Collection The data for this study was collected between December, 1995, and April, 1996. The data collection procedures included gathering official documents, participant observation [14] and structured interviews [10]. The official documents of an organization are valuable sources of information because they are relatively available, stable, rich, and non reactive, at least in comparison to human data sources [10] Some of the documents which provided data for this study were: ffl organizational charts ffl ....

[Article contains additional citation context not shown here]

D. E. Perry, N. A. Staudenmayer, and L. G. Votta. "People, Organizations, and Process Improvement ". IEEE Software, July 1994.

....effort of 11 developers We use the developer name (see x2.1) to relate FSS data to software changes. 3 Model framework The following framework can help define an appropriate model and estimation procedure. Developer monthly effort is spread relatively uniformly over the month. According to [6] on average only 47 percent of developer effort in the considered organization goes to coding software changes. Hence it is natural to assume that there is significant background effort that consumes part of the monthly effort. Figure 2 shows an example of the distribution of effort over four ....

....across months and that the amount of work on an MR performed before its recorded open time or after its last delta time is insignificant. We did not address the issue of whether the effort is uniformly distributed over the time the MR is open. The proportion of background effort was obtained from [6] who studied the same project four years earlier. Since our method is scale invariant the proportion can be applied to the final result if the absolute value of change effort is desired. To use monthly reported effort data we took the simplest approximation, in which all changes open during a ....

D. E. Perry, N. A. Staudenmayer, and L. G. Votta, "People, organizations, and process improvement," IEEE Software, pp. 36--45, July 1994.

....for a researcher to observe the development process. One method is for the researcher to observe a software developer continuously, thus recording every communication that takes place with colleagues, either planned or unplanned. A good example of a study based on this type of observation is [16]. A less time consuming approach is to observe meetings of various types. These could include inspection meetings, design meetings, status meetings, etc. By observing meetings, a researcher can gather data on the types of topics discussed, the terminology used, the technical information that was ....

D.E. Perry, N.A. Staudenmayer, and L.G. Votta, "People, Organizations, and Process Improvement." IEEE Software, July 1994, pp. 36-45.

....kind of flexibility is essential for effective management of projects with diverse application needs. Finding an Expert Studies of development organizations have revealed that considerable attention and effort is applied to finding people in the organization that are needed to get one s work done [35]. A network of people with expertise in specific problem areas is usually formed by individuals in an informal manner that can cause gaps such as the GUI builder problem in the previous section. Because the repository will never have a full list of problems and solutions, it is important to have ....

D.E. Perry, N.A. Staudenmayer, L.G. Votta, "People, Organizations, and Process Improvement", IEEE Software, 11(4), July 1994, pp. 36-45.

....and organizations. Without quantitative information, the analysis results are not sufficient to effectively compare alternatives and to make decisions. Qualitative analysis, while important for intuitive understanding and insight, must be taken further to provide a basis for action. For example, [Perry et al. 1994] have recently attempted to characterize and quantify the workload of software developers across software development process activities. In fact, the AD model is particularly well suited to incorporating data, although there is not an explicit facility for this in the modeling methodology. One ....

Perry, D.; Staudenmayer, N.; Votta, L. (1994), "People, Organizations, and Process Improvement". IEEE Software, 11(4):36-45.

....but is still not well understood is how information flows between developers. It is clear that information flow affects productivity (because developers spend time communicating) as well as quality (because developers need information from each other in order to carry out their tasks effectively) [16]. It is also clear that efficient information flow is affected by the relationship between development processes and the organizational structure in which they are executed. A process requires that certain types of information be shared between developers and other process participants, thus ....

....communication, and its relationship to organizational structure, is well supported in the organization theory literature [8, 15] it has not been adequately addressed for software development organizations. Communication has been identified as an important factor in how developers spend their time [16], and some organizational characteristics that affect its efficiency have been suggested [5, 12] Some, but surprisingly little, of the process work in software engineering Flow Information Development Process information processing requirements Productivity developers spend time ....

D.E. Perry, N.A. Staudenmayer, and L.G. Votta. "People, Organizations, and Process Improvement". IEEE Software, pages 36--45, July 1994.

....and managerial communication, to reflect only that communication required by the development process, but to include all such process communication. These decisions are based on results presented in the organization theory [Ebadi84, MaloneSmith88] and empirical software engineering literature [Ballman94, Bradac94, Perry94]. The three independent variables also appear in these two areas of literature. Organization theory points to the benefits of organizational and physical proximity of communicators [Allen85, Mintzberg79] while empirical software engineering has shown the drawbacks of organizational and physical ....

....in many areas has helped shape the design of the proposed study by providing methods and experience. The choice and definition of the unit of analysis, the interaction (section 3. 2) has been influenced by the organization theory [Ebadi84, Liker86] and empirical software engineering literature [Perry94]. The scope of the study, in terms of the types of communication studied, has also been influenced by this literature. Data collection and analysis methods have come directly from the literature in empirical methods [Lincoln85, Taylor84] Despite the considerable support in the literature, there ....

[Article contains additional citation context not shown here]

Dewayne E. Perry, Nancy A. Staudenmayer, and Lawrence G. Votta. "People, Organizations, and Process Improvement". IEEE Software, July 1994.

....and organizations. Without quantitative information, the analysis results are not sufficient to effectively compare alternatives and to make decisions. Qualitative analysis, while important for intuitive understanding and insight, must be taken further to provide a basis for action. For example, [Perry et al. 1994] have recently attempted to characterize and quantify the workload of software developers across software development process activities. Release Integrity Unambiguous requirements Conformance to standards Reliable software High quality Release Release on time Figure 6: Representing ....

Perry, D.; Staudenmayer, N.; Votta, L. (1994), "People, Organizations, and Process Improvement". IEEE Software, 11(4):36-45.

....Furthermore, the main problem with attaining benefits from CASE tools were implementation problems, like training the analysts on the tool and the underlying methodology. Finding that non technical issues are important supports the beliefs of other researchers in software process improvement [18], and is concordant with the results of an earlier study of requirements engineering practices where the authors state [15] It was strikingly obvious that many of the problems faced by the projects we interviewed were organizational and non technical. Moreover, projects tend to adopt ....

D. Perry, N. Staudenmayer, and L. Votta. "People, organizations, and process improvement". In IEEE Software, pages 36-45, July 1994.

....meetings, etc. One may be able to fill in the intervening time productively, but for a particular sequence of activities there may be a significant difference between the actual time spent and the time that elapses before completion (for example, see the discussions of how time is spent in [2] [11] and [12] To this end, we included two things in the data we needed to analyze the process: estimated race 2 and elapse times, and estimated percentages of time spent in various paths in the process (that is the percentage of time taking one path over another out of the decision points) Using ....

....and rethinking its use as a business value added mechanism resulted in a reduction of effort without a significant cost in quality. Estimates and measurements of resource usage, and time and effort cost studies are necessary preconditions to any simplification or improvement effort (see [11] and [12] for a more complete discussion of these issues) No single simplification produced a major result, rather the accumulation of modest simplifications in the right places resulted in a significant reduction in time and cost. These modest improvements resulted in removing some of the ....

Dewayne E. Perry, Nancy Staudenmayer and Lawrence G. Votta. "People, Organizations, and Process Improvement", IEEE Software, July 1994, pp 36-45.

....has a different set of goals and each provides us with a different class of experience. In scientific experiments we have well designed experiments in which we have a specific set of hypotheses to test and a set of variables to control. The time and motion studies of Perry, Staudenmayer, and Votta [PSV94] and the design studies of Guindon [Guindon90] are examples of these kinds of experiments. These approaches exemplify basic experimental science. We increase our understanding by means of the experiment and generate new hypotheses because of that increased experience and understanding. In ....

Dewayne E. Perry, Nancy A. Staudenmayer, and Lawrence G. Votta, "People, Organizations, and Process Improvement", IEEE Software, 11:4 (July 1994), pp 36-45.

....precondition to a major investment of effort on the part of feature development teams and of resources that should not be squandered. Last, but not least, the prototype is a 8. For further information about our experiments, see People, Organizations, and Process Improvement [19]. Days (A) Task n 1 n 25 n 50 n 75 Unassigned Estimate Plan Dev Requirmnts HL Design LL Design Test Plan Code Inspection LL Test HL Test Cust Doc Support Postmortem process worked process blocked ....

Dewayne E. Perry, Nancy A. Staudenmayer, and Lawrence G. Votta, "People, Organizations, and Process Improvement", IEEE Software, 11:4 (July 1994), pp 36-45.

....processes is GQM (Goal, Question, Metric) 2] This is primarily a formalization of the empirical paradigm tailored to understanding software products and processes. As such it is primarily prospective and not retrospective. Since understanding the process before improving it is fundamental [12] and since retrospective studies can supply a large degree of understanding at very low experimental cost, the GQM approach did not seem appropriate for the problems we addressed. Thus, in our iterations over various aspects of the studied process we use a mixture of retrospective and prospective ....

....process. 4. Understanding the Processes Fundamental to improving any process is a sufficient understanding of that process and the various alternative improvements to be able to choose wisely amongst those alternatives and achieve the desired improvement. Perry, Staudenmayer and Votta [12] argue this point and illustrate it with a series of studies aimed at understanding how people spend their time in a specific software development process. We follow that strategy here first with retrospective studies followed by a set of prospective studies. Watts Humphrey [10] distinguished ....

[Article contains additional citation context not shown here]

Dewayne E. Perry, Nancy Staudenmayer and Lawrence G. Votta. "People, Organizations, and Process Improvement", IEEE Software, July 1994, pp 36-45.

....and improving processes, the flaws in the process that were exposed as a result of the modeling process and the utility of the modeling formalism used in exposing those flaws. 1. Introduction An important step to improving processes is to first understand what the current processes are [5] and then use that understanding as the basis for measured process improvement. The advantage of using a process formalism as the means of modeling the current processes is that the formalism encourages you to think about certain aspects of the process (and if it is a good formalism, the most ....

....as solutions to these problems. We strongly encourage you to do the same. But, we also feel strongly about the need to document the existing process so that there is a firm basis for defining and measuring the various changes to the processes that will arise from this exercise. Baseline it first [5], then improve it by substantiated and measured changes [2] Projecting into the future of our enterprise, I would also extend this lesson: limiting improvements to substantiated and measured ones takes discipline as well. It is all too easy to rely on your intuition (even as accurate as it may ....

Dewayne E. Perry, Nancy Staudenmayer and Lawrence G. Votta, "People, Organizations, and Process Improvement", IEEE Software, July 1994.

No context found.

D.E. Perry, N.A. Staudenmayer, and L.G. Votta, "People, Organizations, and Process Improvement," IEEE Software, July 1994, pp. 36-45.

No context found.

Perry, D. E., Staudenmayer, N. A., Votta, L. G. "People, Organizations, and Process Improvement," IEEE Software, 11(4), pp. 36-45.

No context found.

D.E. Perry, N. Staudenmayer, and L.G. Votta, "People, Organizations, and Process Improvement," IEEE Software, vol. 11, no. 4, July 1994, pp. 36--45.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC