Search

Sustaining large open source development efforts requires recruiting new participants; however, a lack of architectural documentation might inhibit new participants since large amounts of project knowledge are unavailable to newcomers. We present the results of a multitrait, multimethod analysis of the effects of introducing architectural documentation into a substantial open source project—the Hadoop Distributed File System (HDFS). HDFS had only minimal architectural documentation, and we wanted to discover whether the putative benefits of architectural documentation could be observed over time. To do this, we created and publicized an architecture document and then monitored its usage and effects on the project. The results were somewhat ambiguous: by some measures the architecture documentation appeared to effect the project but not by others. Perhaps of equal importance is our discovery that the project maintained, in its web-accessible JIRA archive of software issues and fixes, enough architectural discussion to support architectural thinking and reasoning. This “emergent” architecture documentation served an important purpose in recording core project members’ architectural concerns and resolutions. However, this emergent architecture documentation did not serve all project members equally well; it appears that those on the periphery of the project—newcomers and adopters—still require explicit architecture documentation, as we will show.

The number and variety of cyber-attacks is rapidly increasing, and the rate of new software vulnerabilities is also rising dramatically. The cybersecurity community typically reacts to attacks after they occur. Being reactive is costly and can be fatal, where attacks threaten lives, important data, or mission success. Taking a proactive approach, we are: (I) identifying potential attacks before they come to fruition, and based on this identification; (II) developing preventive counter-measures. We describe a Proactive Cybersecurity System (PCS), a layered, modular service platform that applies big data collection and processing tools a wide variety of unstructured data sources to identify potential attacks and develop countermeasures. The PCS provides security analysts a holistic, proactive, and systematic approach to cybersecurity. Here we describe our research vision and progress towards that vision.

Design practice and artifacts in engineering design organizations can be ordered along four orthogonal dimensions, namely (i) the principle of ordering (top down vs bottom up), (ii) the structure of ordering (aggregation-decomposition vs generalization-specialization), (iii) the breadth of ordering (diversity vs parsimony) and (iv) the perspective of ordering (horizontal vs historical). Four case histories of design organizations are used to illustrate the above and also to demonstrate the tension (either in conjunction or in cyclic sequence) and/or balance between the extremes of the above dimensions. Mechanisms for creating a balance or tension between bottom up generation and top down influence are proposed.

Recent studies have claimed a disconnect between the disciplines of information science and information systems even though, prima facie, there seems to be considerable overlap or potential overlap in their respective subject matter. The present study will target representative journals in the areas of information science and information systems and examine in more detail the overlap or lack of overlap between the two fields as reflected in the co-word analysis of the titles and abstracts of these journal articles. That the subject matters of the two fields can be combined in a discipline will be shown by a similar analysis of a third field, medical informatics, a new discipline in it its own right and a seeming subject matter hybrid of information science and information systems.

Participatory design is the antithesis of traditional design in which designers are expected to exhibit their expertise. The right to participate in design is often ignored and even when it is accepted, many obstacles including perceived pragmatic/economic deficiencies and organizational concerns, impede participation. This paper critizes the foundations of traditional design and elaborates some features of participation in various design disciplines particularly in the context of architectural design and urban planning. An approach to participation founded on widening communication channels among participants is presented. Finally, the potential applications of computer tools for supporting participation are discussed.

Arguing that design is a social process, we expand the meaning of modeling and analysis to include all activities facilitating continual refinement and criticism of the design requirements, process, and solutions. We do not assume any a priori methods for modeling or analysis; rather, we provide a framework and an approach to study designers and give them whatever modeling and analysis capabilities they choose. Our approach is the basis for a support tool, /i-dim, currently under development. 1 The Objective of Modeling and Analysis Design as a social process involving designers, customers, and other participants consists of creating and refining a shared meaning of requirements and potential solutions through continual negotiations, discussions, clarifications, and evaluations. This shared meaning, crystalized as the design artifact and made persistent as shared memory forms the basis of accumulated experience upon which subsequent designs draw. Therefore, design requires support for the following activities: negotiating to establish shared meaning, maintaining and refining the components of the shared meaning, and maintaining and accessing prior information constituting fragments of shared memory. All these requirements are facilitated through iterative modeling and analysis (MA) activities of various forms. If the information about these MA activities is maintained property, the development of shared meanings can be incremental. Therefore, MA activities can rely on previous experience, instead of being rc-invcnied each time, and pitfalls typically encountered in MA can be avoided. In the process of reaching this shared meaning, both modeling and analysis take place, albeit often in an informal and inchoate fashion. For instance, when two designers interact, their exchange involves a particular aspect of the design that is modeled in their discussion. A question posed by one designer constitutes modeling and the response an analysis. Often, the focus of the discussion or negotiation drifts marking the use of several models which, while possibly loosely connected, are nevertheless invaluable for the negotiation. Therefore, to benefit from past models arising in collaborative processes, the information derived from previous negotiations between designers needs to be maintained. Access to information from previous, analogically related, design situations is a basic requirement for improving design. In fact, the very act of accessing and applying previous information implies a model of past information and requires models and analyses of the present. To illustrate, if designers create a quexy to retrieve pans from a database for satisfying a specific function, they model the functionality required using a relatively small set of parameters related to, and perhaps derived from, past models. If the query retrieves useful pans, the analysis was successful and the modeling appropriate. If the query fails, knowledge about the failure constitutes valuable information as well. Consequently; it is necessary that not only successes but also that failures be MA activities manifest in negotiation and information retrieval are by and large informal, as opposed to formal modeling via models cast in mathematical form as traditionally conceived of in engineering.

Research on machine learning in design has concentrated on the use and development of techniques that can solve simple well-defined problems. Invariably, this effort, while important at the early stages of the development of the field, cannot scale up to address real design problems since all existing techniques are based on simplifying assumptions that do not hold for real design. In particular, they do not address the dependence on context and multiple, often conflicting, interests that are constitutive of design. This paper analyzes the present situation and criticises a number of prevailing views. Subsequently, the paper offers an alternative approach whose goal is to advance the use of machine learning in design practice. The approach is partially integrated into a modeling system called n-dim. The use of machine learning in n-dim is presented and open research issues are outlined.

This paper presents a new unifying theme for design theory by emphasizing the importance of context. We arrive at our conclusions by examining and then criticizing the legitimacy of universal methods in design upon which the critical importance of context emerges. The collaborative aspects of design focuses attention on the conception of shared meaning. We introduce and elaborate the concept of shared memory as the embodiment both of context and of shared meaning. Using the concept of shared memory in vertical and horizontal forms, within and between disciplines, respectively, we both account for past observations of design in practice and recommend actions to improve design in the future. We examine several practical implications of the growing importance of shared memory in industrial firms and for design teams. We then consider and recommend specific research programs which will help designers capture and make better use of this critical resource.

The authors characterize the problems inherent to mapping across or combining terms from different vocabularies, focusing especially on MeSH and SNOMED. They also describe the exploration of the development of a frame-based representation of SNOMED.

The authors describe CLARIT processing as an approach to automatic indexing. They also explore two elements of the indexing process, identifying concepts in text and selecting concepts to reflect the perspective of a domain.

Requirements documents, test procedures, and problem and change reports from a U. S. Army Software Engineering Center (SEC) were analyzed to identify, clarify, and begin categorizing recurring patterns of issues raised throughout the product life cycle. Semiautomated content analysis was used to identify underlying patterns in the SEC documents. Automated tools and techniques were used to support efficient search and related semantic analysis that would not be possible manually. Discussions with Army personnel were used to confirm and elaborate initial findings and interpretations. The same analytic methods can be used as a basis for novel, proactive causal analysis processes. One of the patterns identified here suggests that usability is not sufficiently articulated and quantified early in the product life cycle. While the SEC has established exemplary processes to handle usability-related issues when they arise, some of them might be mitigated or prevented by documented consideration upstream.

Effective intelligence work must uncover possible scenarios, however improbable, that need to be tracked until they can be eliminated from consideration. What is most important is identifying and maintaining contact with improbable hypotheses or ones that are inconsistent with one's own or ones that appear to have high probability. Improbable patterns must also be maintained as information accumulates, and not be drowned out by mounting "evidence" for other patterns. All patterns, both probable and improbable, need to be tracked and evaluated as they evolve. The paper will focus on methods, techniques and technologies for capturing the emerging semantics of accumulating information emphasizing empirically-based bottom-up text processing that suggests semantic relations based on term associations. It will also discuss combining text-processing with disciplined top-down semantic formalisms (such as ontologies) and maintenance and use of outlier data that can be combined with subsequent data leading to potential new discoveries. We will also note that the complexity and sheer volume of information requires that computational tools are only one part of the infrastructure, processes and interactions needed. The paper and presentation will describe both completed and proposed work.

To be effective in practice, concurrent engineering requires access to and organization of knowledge accumulated over time, product versions, and customers. More important, separate knowledge resources have to be shared and coordinated over space and time if successful design is to be accomplished. The authors, address the nature of communication in design, especially across disciplines, and the support systems that facilitate better communication. While a lot of research effort is being expended on same-time communications within a group, they consider, as well, the need for, and the problems associated with, different-time, different-placed communication. they present these views in connection with an on-going development effort, n-dim. >

Individual users of medical language manifest great variation in the expression of concepts and have difficulty in selecting appropriate terminology when confronted with systems that rely on standardized language, such as MeSH, SNOMED, or ICD, and the special terms sets of systems such as HELP, INTERNIST-I/QMR, and DXplain. Indeed, the need to map natural language into appropriate special terms—as well as the need to map one system’s specialized terminology into another’s—is one of the problems being addressed by the National Library of Medicine’s UMLS System, with its associated information sources maps. The problem is extremely difficult, in part, because such mappings depend on semantic equivalences among terms, not merely the superficial matching of words or phrases.

This study applies various tools, techniques, and methods that the Software Engineering Institute is evaluating for analyzing information being produced at a very rapid rate in the discipline--both in practice and in research. The focus here is on mapping the evolution of the research literature as a means to characterize software engineering and distinguish it from other disciplines. Software engineering is a term often used to describe programming-in-the-large activities. Yet, any precise empirical characterization of its conceptual contours and their evolution is lacking. In this study, a large number of publications from 1982-1994 are analyzed to determine themes and trends in software engineering. The method used to analyze the publications was co-word analysis. This methodology identifies associations among publication descriptors (indexing terms) from the Computing Classification System and produces networks of terms that reveal patterns of associations. The results suggest that certain research themes in software engineering remain constant, but with changing thrusts. Other themes mature and then diminish as major research topics, while still others seem transient or immature. Certain themes are emerging as predominate for the most recent time period covered (1991-1994): object-oriented methods and user interfaces are identifiable as central themes.

This report summarizes the results of an experiment that uses terminological structures derived from the application of knowledge summarization, analysis, and visualization (K-SAV) technology to textual data from the Software Engineering Risk Repository (SERR) resident at the Software Engineering Institute. This study evaluates the use of several tools including shared word clustering (Monarch 94) and a co-word analysis software program, leximappe Tell 92. The experiment seeks to determine whether an application of co-word analysis to baseline risk assessment data would enable a reduction of the information load while simultaneously providing a succinct but encompassing picture of the risk information within the program. This study is based upon a somewhat limited data set. Nevertheless, the results of this investigation are encouraging and suggest that there may be value and potential for the effective use of co-word analysis and K-SAV technology more generally in risk management. Additional investigations are underway to confirm, alter, or challenge the results.

As part of of the ARPA MADE initiative, we are beginning to develop ACORN, an Advanced Collaborative Open Resource Network, ACORN will provide the infrastructure to create an electronic community which will be able to design and sell engineered products in competitive markets as well as conduct research and development by collaborating through a network. Creating such a community is a task of national proportions and cannot be accomplished by our group alone since the target community encompasses the entire country. We have an unprecedented opportunity to create and experiment with an electronic community which can serve as the model for a larger national community. In this paper, we outline the architecture for an information infrastructure to create and sustain such a community. This paper is not a standard research paper; it is being published to invite the members of the community to participate in the evolution of the ideas expressed here and to encourage the shared development of the infrastructure necessary to create this network. L Introduction This paper describes an open network to provide resources to the design and manufacturing community. As part of the ARPA MADE initiative, we have been funded to begin developing the necessary infrastructure. The ACORN infrastructure must leverage off existing facilities such as the Internet and the research laboratories that have been developed within the community. Whenever possible, we will use tools and services that already exist commercially and in universities. Initially, the ACORN infrastructure will be created as a test bed for designing electro-mechanical devices. A crucial part of creating the ACORN infrastructure is the development of the community that will use and expand the network. Such an electronic community can increase in scale only if the community shares its resources to build continually on the work of each participant, not only for the creation of engineered products but also for the infrastructure itself. The evolution of the infrastructure requires that as software modules arc created they become products and parts in themselves and be used to bootstrap and sustain the infrastructure. Thus the effort expended in the creation of the ACORN infrastructure is expected to produce results that are three fold: 1. a prototype electronic design and manufacturing community 2. a basis for the National Information Infrastructure and 3. a national repository in which engineering designs (including software) can be stored and retrieved for reuse. The creation of such an electronic community in the market place requires a critical mass of participants representing the entire potential user community: industry, government, and universities. In the absence of such a critical mass, the test bed will not grow beyond the universities because the necessary diversity of offerings will be absent. In short, an economically viable electronic community can exist only if each participant perceives advantages to belonging to the community which outweigh the costs as seen from the parochial perspective of purely competitive advantage. The proposed work must therefore draw on a microcosm of the larger community. The lessons learned in its creation and sustenance will serve as the basis for the creation and maintenance of the community which, in turn, can serve as the basis for similar communities focused other interests. The community we envisage can be composed only of voluntary participants. Creating an environment which facilitates such voluntary participation requires considerably more than just generating the necessary hardware and software elements. It requires the careful orchestration of evolving practices, conventions, and standards. These issues must be addressed by one or more bodies that concentrate on the issues that surround any voluntary entity: the basis for entry, the conventions and standards that arc required, the processes for establishing conventions and transforming them into standards, and the systems to ensure the safety, security, and confidentiality of individual interests without jeopardizing the interests of the community. Our community is not monolithic; it is composed of business firms, universities, research establishments, the government, consultants, etc. Each group also has users with widely different technical skills, requirements, facilities, and needs. As such, ACORN must be flexible enough to accommodate the needs and constraints of each potential user. This flexibility requires that the entire effort be based on a compositional approach to systems building where each participant brings their services to both building and creating new applications and work-relationships. This demands that the application services should not be layered; layering would hinder the community's dynamic and ad-hoc composition of working design environments (combination of interaction modes, types of information exchanged etc.) In order to understand the requirements that will drive the architecture of the system, it is important to recognize that ACORN is predicated on organizational and institutional solutions as well as software and hardware solutions. If all aspects are not addressed, ACORN will fail to achieve fully its intended goal of creating flexible design and manufacturing shops based on electronic commerce. Consequently, this technical rationale treats hardware, software, the architecture, the derived procedures, and organizational process all as products of proposed effort. 2. Design Scenario To show the potential benefits of ACORN, we present three scenarios that involve solving the same design problem: first with a geographically co-located design team, then with a geographically distributed team without the ACORN infrastructure, and finally with a geographically distributed team with the ACORN infrastructure. The first two scenarios are examples of certain types of design situations as they occur today. The third is an example of how design might be done once the ACORN infrastructure is in place. Reference is made within the scenarios to software that is being developed by the members of the ACORN team. Although we do not describe the software in this paper, the functions of the software should be clear within the context of the scenario. The first scenario is based on a class design project at CMU. The other two scenarios are variations on the first scenario. 2.1. Co-located Design Team A team of six students from four disciplines is assigned the task of designing and building VuMan 2, a wearable computer with a heads-up display. The project is organized to achieve concurrency in time and resources. The students work together in a single room, so the class operates like an industrial skunk works. The students have access to the expertise and computational tools that are available on campus in much the same way that an industrial team would have access to in-house expertise and tools. Similarly, the students have been given a budget and can use local job shops for tasks such as PCB manufacture. The goal of the VuMan 2 project is to create a prototype of a half pound, belt-mounted computer with a heads-up display. The students must design and build the hardware, software, and mechanical systems in four months. The design is based on a prior, heavier version with less functionality than the specifications for VuMan 2. Figure 1 illustrates the primary tasks and the interactions between the tasks as they evolve over time. Together, the team lays out the expected tasks: create functional specifications for the hardware, software, and mechanical design, assess similar designs and available technologies, synthesize the electronics, design the software and user interface, and design the housing. Because the design team is co-located in close quarters, the members of the team can interact continuously. The need for interaction among subgroups representing various disciplines varies depending on the state of the design. In the beginning, discussions are frequent and intense. As the specifications for each subsystems becomes firmer, the subgroups tend to work among themselves. Each time the systems are integrated, interactions across groups again becomes frequent and intense. Due to time pressure, the students often do not document or record their design decisions. This can lead to problems for absent or new members of the team who will need to be filled in on all the changes and decisions that have been made. Moreover, if design problems arise later in the process, not keeping track of prior negotiations and compromises for how and why certain design threads fit together may make it very difficult to fix problems without causing the threads to unravel. This is especially true when a design is sewn together by groups or team members from different disciplines. Each group spends two or three weeks reading trade magazines and calling vendors to assess the price, capabilities, robustness, and compatibilities of available technologies. As the design progresses, the colocation of the design team allows some (but by no means all) potential problems to be resolved before they became inextricably embedded in a subsystem. For example, when a member of the industrial design team sees a 4" high backplane that the electronic designers are planning on using, he objects that PCB domain PCB manufacture Industrial Housing: design manufacture. _ Electronici domain Mechanical: Software domain domain domain 0) Etec. Designs & Wirewrapy r PCB \ \manufacturej ( PCB route ( Populate \ PCB jc Software \ &UII J Electronics N test J f Housing \ manufacture/

This report describes a method for facilitating the systematic and repeatable identification of risks associated with the development of a software-dependent project. This method, derived from published literature and previous experience in developing software, was tested in active government- funded defense and civilian software development projects for both its usefulness and for improving the method itself. Results of the field tests encouraged the claim that the described method is useful, usable, and efficient. The report concludes with some macro-level lessons learned from the field tests and brief overview of future work in establishing risk management on a firm footing in software development projects.