Dewayne E. Perry

Research Projects at Bell Laboratories (Present - 1983)

Current Projects

Empirical Studies --- with Adam Porter and Larry Votta
- Our experimental designs and empirical studies have been aimed at creating a new paradigm for experimental software engineering by incorporating aspects of social and organizational studies into the current experimental approach. Critical to this are two concepts that we have formulated and refined in our tutorial ``A Primer on Empirical Studies''. The first is the concept of validity; the second is the concept of credibility. While it is true that these concepts have well established meaning in other disciplines, they must be reformulated in the context of the new empirical work that we have initiated.
Parallel Changes in System Evolution --- with Harvey Siy and Larry Votta
- Parallel change is an essential aspect of large-scale software development. Our study is important for two reasons. First, the feature-driven nature of 5ESS development intensifies this parallelism. Our hypothesis is that these parallel and conflicting changes represent an underlying mechanism that leads to code decay. Second, the configuration management (CM) support enforces a sequentialization (and interleaving) of these changes. There have been several CM solutions proposed with little attention given to the actual data about the problem.
  Our observational case study looks at this problem from the various levels of parallelism: releases, features, IMRs, MRs and files. In all cases, the distributions of the data do not follow standard engineering distributions (ie, normal or poisson), but have significant tails. This data and the extent to which we have prima facie conflicts within files provides us with the basis for pruning the solution space for adequate technical and methodical support for parallel changes.
Generic and Product Line Architecture Research.
- I have determined the fundamental concepts needed as a basis for describing such a generic software architecture and sketched out the structures needed for their descriptions. Critical to the approach are the conceptual and representational structures that provide sufficient abstractness so that an individual product architecture can be instantiated and customized in a disciplined way from the generic (or reference) architecture. As part of the research process to arrive at this point, I have summarized this work and the current state of the art in software architecture in my invited talks the 1997 International Software Engineering and the Coordination 97 Conferences.
- There are a number of important research issues to support generic and product line architectures.
  - An increasingly critical issue in generic architectures is that of dynamic (re)configuration, the ability to change the system without sending it back to the supplier to be reconfigured manually. An important aspect of dynamic reconfiguration is the the ability to maintain the minimum configuration resident in the system is of paramount importance. I have designed and implemented a set of tool fragments that determine what modules need to be deleted from the system configuration and what needs to be added (when a base component is either deleted, added or replaced) to maintain the minimum configuration.
  - For a generic architecture that covers a wide range of products that vary in both size and complexity, the issue of how to treat the problem of distribution is fundamental. A very useful solution to this problem is to bury the aspects of distribution in the supporting platform so that the generic architecture is distribution-independent. Thus we are looking at the underlying support needed to provide this independence.
  - The notion of a generic (or reference) architecture for a product line entails a deep understanding of the domain for the product line. This means that the subsequent generic architecture should focus on the domain as the user or customer might view it rather than in terms of the underlying implementation. One of the basic issues then is the process by which the various domain-specific architectural elements are determined. How do you identify common architectural elements? How do you determine which have a common implementation and which have a common interface that needs a subdomain specific implementation?
Feedback and Control in Software Processes. With Prof. M.M. Lehman, Imperial College, London, and Prof. Dr hab. Wladyslaw M. Turski, Institute of Informatics, Warsaw University, Juan Fernandez Ramel and Paul Wernick, Imperial College. See also Feast site
- We have collected further system growth data from our industrial partners and are investigating how well the growth phenomena support Lehman's fourth law. Previously analyzed data of Lehman's together with new data suggest further support for this interpretation. Our analysis of the data is still preliminary and we will continue this investigation.
- We have some preliminary results in our investigation (Juan and I) of the effects of the evolutionary phenomena in which we open up the black box model (that is, viewing strictly the external behavioral phenomena) into a model with two evolutionary submodels, each of which represents a release process and each of which are concurrent but overlapping in a time-shifted way. By modeling each release process using the inverse square model, we get an overall release phenomena similar to the data we have seen in actual data and as predicted by the inverse squares model. We continue this investigation to see if, given the external phenomena, we can deduce the internal release structure.
- We have some very interesting results about the evolutionary phenomenology. We have data from Logica for 21 releases of their financial transaction system and it exhibits much of the same characteristics as the original OS/360 system. The data we have from the Code Decay Project for the Domestic OSPS also is very similar even though we have only 12 releases for OSPS. In modeling and comparing the two sets of data we have an amazing similarity between the two sets of data. Using an inverse squares model to predict the evolutionary growth (due to an insight by Wlad based on Manny's Laws of Evolution) we have a very good fit for the systems' growth over time. The second effect of this model is that after about 5 to 7 releases, the effort needed to produce the next version can be predicted quite accurately.
- Our proposal efforts have culminated in FEAST/1, funded for 2 years by the Engineering and Physical Sciences Research Council to support two PostDocs at Imperial College and interaction with our industrial partners (British Aerospace, ICL, Logica, and Ministry of Defense).
- Data on the phenomenology of OS/360's system evolution suggest that such evolution involves and is, to some extent, governed by feedback. Our investigations over the past year, using a basic model for feedback control, have exposed a variety of reasons why examples of classical feedback control are so hard to find in software processes: software processes are design, not production processes; control-directed process changes tend to be step functions, not regulatory ones, and are often as creative as the processes they control; system development and evolution processes are still immature with little theory to guide the design and application of regulation control mechanisms; and feedback overload. Our initial findings for the FEAST (Feedback, Evolution And Software Technology) Project are summarized in ``Why is it So Hard to Find Feedback Control in Software Processes'' which was presented as an invited keynote talk at the 19th Australasian Computer Science Conference, 31 January - 2 February, Melbourne, Australia.
Geographically dispersed code inspections --- With Jim Perpich, Mike Wade, Adam Porter and Larry Votta.
- In addition to establishing a principle about the effectiveness of meetingless code reviews in support of this distributed code review tool, we established two other important results. First that the use of empirical studies to gain a deeper understanding of the problem to be solved is more effective than a technology-driven research approach in crafting a specific and novel problem solution. Second, this study in conjunction with others that we have done enabled us to categorize the the primary independent factors in inspections (coarse-grained control knobs if you will) that determine the dependent factors of cost, quality and interval.
- We exploit properties of the internet to provide a meetingless inspection tool. Its justification comes from the analysis of a currently running natural experiment where inspections are done either with meetings or by desk inspections with no significant differences between the two approaches. Coupled with the cost savings gained by electronic dissemination and collection, the tool is a significant improvement.
- The goal of our geographically distributed software development experiments is to determine the utility and effectiveness of processes and technology that enable developers to work cooperatively from more than one development location. Specifically, Mike Wade, Larry Votta and I are experimenting with distributed, asynchronous code inspections to be used in the software development organization with groups in Naperville IL and Whippany NJ. We have defined and built a tool using Netscape to provide a distributed and asynchronous inspection process that incorporates the core of their current inspection process.

Past Projects

Process Simplification.
- In addition to the useful techniques that we found for process simplification and improvement, this study led to an insight that has not been appreciated in the earlier generation of empirical work: that the use of historical or retrospective studies before launching into prospective studies is fundamental to making progress in empirical work.
- We have brought our collaboration on 5ESS processes to a logical conclusion with two papers: one discussing the barriers to an effective process system architecture and the principles gleaned from our architectural visualization and analysis work, and one discussing our studies in process simplification (the best of the ICSP4 papers -- it will be published in a special issue of Software Process: Improvement and Practice).
- As a result of our process interface analyses, the core development processes were selected by 5ESS process management (Dandekar, Carr, Barshefsky, and Kania) and me as candidates for process interface improvement. The tool pia (process interface analysis) was designed and implemented as a extension of the pichk tool suite to analyze individual process interfaces in the context of the entire set of interface specifications. Improvement of the process interface specifications is in progress.
- A.V. Dandekar, A. Barshefsky D.C. Carr, and I defined a set of criteria for selecting candidates for experiments in process simplification and improvement. As a result, we have negotiated with the Customer Documentation and Training (CD&T) and the Customer Services (CS) Process Management Teams to be experimental subjects. We invited N. Barghouti, J.O. Coplien, D.S. Rosenblum and L.G. Votta to participate in the experiments and to use their various tools and techniques. I put together a process questionnaire to guide the team in capturing process information.
Process Descriptions, Visualization and Analysis -- A.V. Dandekar, A. Barshefsky, D.C. Carr, and S.M. Kania.
- Our primary focus has been on the process architecture of the 5ESS software development processes. I Have designed, developed, and extended two basic tool suites, piv and pichk. piv is a suite of tool fragments that takes a set of process interface descriptions and produces visualizations (using S. North's dot and E. Koutsofios dotty of various kinds (for example, the input and output relationships between processes and artifacts, the input and output relationships between sources and sinks, etc). They also provide the ability to visualize subsets of the 5ESS process as well as only the set of connected processes. Various forms of the ``big picture'' have been used to advantage to understand both the overall process architecture and various facts about individual processes. I have incorporated coloring on the basis of object characteristics as a part of the visualization and used that to emphasize various aspects of the ``big picture''. We plan to provide interactive visualization using C.D. Blewett's Xtant and incorporate multi-level visualization, interface and cost analysis, and direct access to the On-Line Methodology.
- pichk provides automated interface analysis both of the entire set of processes as well as subsets (in both isolation and context) of the entire set. We have also done manual analysis of the process sources/sinks and artifacts. We have used both the automated and manual analyses to correct the simplest problems with the process interface descriptions. The overall result of visualization and analysis has been a significant understanding of a number of process architectural issues. Our approach and our insights are detailed in my talk entitled ``Process Architecture''. I have added simple cost analysis to the interface analysis and plan to incorporate more complex cost analysis and simulation (with L.G. Votta) as part of the tool suite.
- A.V. Dandekar and I arranged our benchmarking trip to visit some of the best in class software development organizations. For that effort, I defined a set of benchmark questions to be used in our discussions. I summarized the results of our visit to Hughes, Fullerton.
- Another of the results of my work on visualization and analysis has been the establishment of the Process Architecture QIT, led by A.V. Dandekar. We have been meeting weekly for the past several months and have come to a deeper understanding of the problems, their root causes, and some of the counter measures that might be used to improve the process architecture.
Software Leadership Group -- Software Process Subteam (a cross-business unit venture). The goals of this SLG subteam are to determine the level of existing commonality in the software development processes across AT&T, to define the desired state of commonality that should be achieved across AT&T BUs, to set out a development plan to move to the ``best'' processes, and to generate a proposed schedule with an effort estimate for the deployment of these common processes.
Process and Data Model Visualization. Requests from M.E. Biell and C.M.Stach resulted in the design and implementation of ``low-threshold'' visualization tool suites for use in reengineering the 5ESS front end processes. pv and dmv are suites of tool fragments that provide the processing of simple model descriptions into graph visualizations (provided by dot with excellent support from S. North) of process and data models, respectively. Important aspects of the models are represented graphically with distinct symbols and connections. The models are composable, enabling the modelers to decompose their descriptions appropriately. dmchk was designed and implemented to find duplicate data elements among various data models.
Process Monitoring and Analysis -- With Mark Bradac and Larry Votta.
- Mark Bradac, Larry Votta and I have prototyped a process monitoring experiment by reconstructing one lead designers experience for the ISLU2 project (32 months of data) using an initial set of tasks and states and analyzed the data in terms of these task and states. The primary results of this prototype is a reformulation of the general binary decision of worked or blocked to worked, not worked, or blocked and a reformulation of the states to reflect this trinary decision. A byproduct of this exercise is an interesting set of observations and questions to consider when correlating the data from the various processes in the experiment.
- After the prototype was done, we then instrumented the collection of data from various diagnostic software features (with 7 experimental subjects covering 5 features). We conducted initial interviews with the subjects to make sure that the developers understood the instrumentation. We have now collected two months of data and analyzed it by person as well as by feature. We have conducted feedback interviews with the analyses of the collected data to determine the subjects understanding of the experiment and to determine better ways of instrumenting the data collection and refining the task and state categories.
- Nancy A. Staudenmayer (MIT Sloan School and a summer student), L.G.Votta, and I designed, executed, and completed a study to assess the precision of the software developer time reports. We found a fidelity rate of \(ap80%. Further, we found that the discrepancy was caused by interruptions in the ``planned'' work day of the developer. The magnitude of these interruptions is caused in part by the size of 5ESS and some poor quality releases. Thus, we can quantify some the cost of poor releases and poorly documented architecture with respect to its impact on software developers. An important by-product of this study is an insight into the various means of interaction among developers, their frequency and duration, and their effectiveness. The work is documented in ``Finding Out What Goes on in Large Software Developments''.
Process Modeling Experiment -- With Al Barshefsky, Paul Kohorn, David Long, Walt Scacchi (USC), Pi-Wi Mei (USC), Larry Votta, Mike Wish. and various others.
- Walt Scacchi and Pi-Wi Mei described the Design and Document Review Processes from the OLM within Scacchi's Articulator Model, emphasizing the roles of the people in the processes, the resources required, consumed and produced in the processes, and the various tasks contained in these processes.
- Paul Kohorn, Larry Votta, Mike Wish and I have described and summarized the experiment indicating the various goals for the participants in the experiments, the costs associated with the experiment, data about the Articulator Model descriptions, comparisons with the current OLM, resulting evaluations of both the Articulator and the OLM descriptions, and finally delineating various possible alternative experiments to further our understanding of process modeling technology.
Consumer Messaging Project -- with John Nestor, Persistent Data Systems; Alex Gillon, Joe Bednar, Fred Imbrogno, Peter Ott, and Paul Chisholm)
- John and I reviewed the current 0.5 Telescript Documentation and identified a number of serious problems in both the design and the documentation of the language. The general problems with the current state of the language are: both the design and the documentation are incomplete (among other things there are no substantive examples), the peripatetic execution paradigm is currently beyond the state of the art and hence unacceptable as the basis for a (inter)national network product, and the language is extremely irregular and complex. Among the more specific problems are 1) the synchronization of communicating tasks, 2) the asynchronous termination of tasks, 3) the validation of mobile agents, 4) problems guaranteeing the availability of the network, 5) the persistence of objects, 6) naming and identity of objects, 7) the exception model, 8) the range of applicability of the language and its features, and 9) reverse polish syntax and 10) the lack of any static analysis.
- John and I next reviewed the 0.6 Telescript Documentation with the following results: the documentation is still far from complete; the major technical problems obtained in our previous review were only superficially addressed; and the language is even more complex than before. Our mode of interaction then changed from reviewers to language designers to assist them in solving the critical language problems. We sketched out an approach that would provide traceability (which was then fleshed out by Peter Ott, LZ) and provided design proposals together with sets of examples for concurrency control, atomicity and persistence. We then documented the design and review process to date, indicated where progress had been made and where there were still significant problems, and provided damage control and risk reduction recommendations.
- Worked with Joe Bednar on fall-back positions that AT&T might take in case the language effort does not succeed. We have presented a preliminary design that provides substantially the same functionality but with significantly simpler and well-understood
With Larry Votta, collected the process improvement experience of two unrelated projects. Summarized the importance of organization as an integral part of process in the paper ``A Tale of Two Projects'' (which is targeted for management).
Participated in DARPA Module Interconnection Formalism Working Group (one of the organizers of the WG and the principle scribe for the group). The focus thus far has been on the definition of the basic transport layer for the prototyping languages (with the ML type system as the basis for this layer). On top of that layer will be a services layer that will include an Inscape-like interface descriptions to support static analysis of module interconnections as well as to provide the basis for dynamic linking of modules.
The Interact/Intermediate Process Modeling and Support Environment
- Designed the Interact (goal-directed) process modeling language and the architecture for Intermediate, the process support environment. Important aspects of I/I are the specification of timed obligations and scheduled activities; the static and dynamic aspects of model modification, specialization and generalization; the scope, migration, and persistence of process state; the reflectivity of the modeling language and the reification of process definitions, state and history.
- (With Alex Wolf, David Rosenblum, and Bala Krishnamurthy) Modeled the ADVSOFT process -- the process for coordinating the (approximately) 25 researchers in Dave Belanger`s Department in releasing and distributing their tool set. Used this example with the ISPW6 and ISPW7 process examples as a means of focusing the work on both the language design and the architecture of the support environment.
Competitive Analysis of Software Engineering Trends and Technologies (with Jan Norton and Jim Fritsch). Part of a team to review the state of the art in software engineering, direct and review the findings of William Riddle, Mark Dowson, and Brian Nejmeh, and assess the state of other competitive companies relative to Bell Labs.
Consulted with Team 95 on issues of software architecture, software development environments, errors in the development process and the software process.
Software Architecture, with Alexander Wolf. Defined a model of software architecture, delineated several views of software architecture, defined the context of software architecture relative to requirements and design, projected the effects of this approach to architecture on the software product and software process, and provided several detailed examples to illustrate the various intuitions gleaned from various related architectural disciplines. Our examples indicated the kinds of notation needed to describe software architecture.
Joint Task Force on the Front-End [Software- Development] Process.
- Participated fully in survey of existing productivity and quality problems, technical planning, product planning, schedule planning, and budget planning.
- Provided description of a streamlined, formalized, and automated front-end process on which the front-end process for a representative group of features.
- Project plan (with 1-2 THCY funding from the task force budget) to demonstrate a complete (on paper) example of the new front-end process demonstration.
- Consolidated and expanded the research Triad vision of how the products of the front end are represented and analyzed in a paper ``Living Representations for Industrial Software Development''.
- Defined the syntax and semantics of the Triad naming scheme which provides a uniform naming mechanism that enables machine processing of both formal and informal documents.
IMR Survey and Analysis, with Carol Stieg. Worked on the survey questionnaire for design and coding errors in one of the releases of 5ESS incorporating questions about effort to find and fix the errors, underlying causes and means of prevention (as well as information about various aspects of interface errors). Analyzed the resulting data, weighting the results by the find and fix effort, and indicating the trends in the underlying causes and their means of prevention.
Represented research on the Next Generation Network Software Architecture Team which was comprised of representatives from various parts of network-related organizations. The focus of the work was to define the issues and components of a common software architecture for the next generation of networking products.
The Inscape Environment Project -- investigates the constructive us of formal interface specifications and the building and evolving of large software systems.
- Defined the notion of a semantic interconnection model in which dependencies between program fragments are defined in terms of semantics rather than just unit or syntactic dependencies. This provides the underlying basis for the Inscape research.
- Defined the Instress module interface specification language and build a language oriented editor using Carnegie Mellon's Gandalf Generator system.
- Developed the semantics of program construction based on the composition of program fragments into various larger fragments -- composition of sequences, selection, iteration, assignment) and the propagation of the fragment interfaces.
- Built a prototype incorporating a simple logic and simplified interface specifications, but incorporating all of the composition and propagation research.
- Investigated the problems of version control and system generation exploiting the reasoning available due to the formal specifications. Defined various forms of compatibility and notions of substitution in terms of interface relationships.
- Codified the various forms of fault handling and their semantics in terms of composition and interface propagation.
- Explored the use of graphical interfaces to pictorially represent the semantic interconnections of software constructed in Inscape. The use of ellipses and viewer directed expansion provide useful handles on simplifying the problem to manageable proportions.
- Provided an economic model of the Inscape Environment (with Helen Diamontides). We constructed a simple model of the Inscape environment to determine the effect that would result if Inscape were used in place of current tools.
- Inquire (with Steve Popovich). We first revamped the symbol tables to provide the needed structures for the browsing and search capabilities. We then implemented a browser that enables the user to navigate through the modules on the basis of module, data object, operation or predicate names, following both definitions and uses. More importantly, we provide a predicate-based deductive search mechanism that is available both to the system and to the user to retrieve various system objects on the basis of predicates used in the interface specifications. Commands enable the user to ask for single entities or composite entities to satisfy the desired predicate requirements.
- Investigated the problems of shared dependencies and defined a formalism for describing shared dependencies in terms of interface dependencies and the process of reasoning about those dependencies and the problem of multiple, simultaneous substitution in a system configuration.
FSM-Inscape (with Bill Schell and Jim Krist) Created a specification language for describing states and their transitions and built a prototype to show the feasibility of applying Inscape technology to finite state machine designs and to SDL type specifications (ie, adding semantic descriptions to states and their transitions and analyzing the state machine for interface errors between the states and their transitions).
The Infuse Environment (with Gail Kaiser, Columbia University, Peggy Quinn and Bill Schell) -- investigates the problems of managing various kinds of change in very large systems and the kinds of data structures needed to support both the changes themselves and their management.
- Collected data on the patterns of change in various size systems to determine the effects of scale on the change process. In particular, the number of components changed as a result of various kinds of evolution (eg, bug fixes, refinements, optimizations, and new features).
- Created a model of SDEs within which to discuss the problems of scale and their effects on the requirements of software development environments. In particular, we distinguished four different classes of SDE models that reflect the social structure of environments to support single, small group, large group and multiple group projects.
- Designed the underlying structure of Infuse in terms of its hierarchical experimental databases (HEDBs) and local workspaces, and the policies determining when deposits are allowed into the parent HEDB.
- Explored various graph partitioning algorithms for insight into the partitioning needed to support Infuse's model of automated cooperation. Built several tools to determine call graphs, syntactic dependencies, etc. of systems constructed using Smile (the software development environment used in Gandalf) in order to obtain interconnectivity data. In the end, we used one of Gail's students' clustering algorithm to provide the partitioning needed to support Infuse's model of automated cooperation.
- Incorporated integration testing into Infuse using its HEDB structure and adding unit testing at the leaves of the HEDBs and integration testing at each HEDB level. The integration structures needed to incorporate 1) keeping track of which tests exercise which stubs and then doing automatic regression tests when those stubs are replaced by real components, and 2) the interactive construction of the appropriate test drivers for each HEDB on the basis of the component drivers.
- Explored the issues of inheritance and its effect on reuse and testing. Given certain uses of inheritance, reuse requires the retesting of OO classes.
- Defined Infuse's transaction and concurrency control model.
Consulted on the Ada Translator System with Charles Wetherell. Reviewed the compiler design and design documentation.
Bibliography on debugging and testing.
Interface error study with Mike Evangelist for a large real-time operating system, delineating the kinds of interface errors that occur, their proportion to non-interface errors, and their root causes.
Explored Prolog control and environment facilities with Nam Woo. Investigated Prolog as an inference mechanism and data base mechanism using fault diagnosis and transitive closure algorithms as examples for the interface mechanism and an interactive database construction program as an example data base.

Dewayne E. Perry - This information last updated October 1997