waashk/dblp huggingface dataset:
multi-platform user interface construction: a challenge for software engineering-in-the-small. the popular view of software engineering focuses on managing teams of people to produce large systems. this paper addresses a different angle of software engineering, that of development for re-use and portability. we consider how an essential part of most software products - the user interface - can be successfully engineered so that it can be portable across multiple platforms and on multiple devices. our research has identified the structure of the problem domain, and we have filled in some of the answers. we investigate promising solutions from the model-driven frameworks of the 1990s, to modern xml-based specification notations (views, xul, ximl, xaml), multi-platform toolkits (qt and gtk), and our new work, mirrors which pioneers reflective libraries. the methodology on which views and mirrors is based enables existing gui libraries to be transported to new operating systems. the paper also identifies cross-cutting challenges related to education, standardization and the impact of mobile and tangible devices on the future design of uis. this paper seeks to position user interface construction as an important challenge in software engineering, worthy of ongoing research.
debugging by asking questions about program output. one reason debugging is the most time-consuming part of software development is because developers struggle to map their questions about a program's behavior onto debugging tools' limited support for analyzing code. interrogative debugging is a new debugging paradigm that allows developers to ask questions directly about their programs' output, helping them to more efficiently and accurately determine what parts of the system to understand. an interrogative debugging prototype called the whyline is described, which has been shown to reduce debugging time by a factor of eight. several extensions and generalizations to it are proposed, including plans for evaluating their effectiveness.
software process management: lessons learned from history. regarding history, george santayana once said, &ldquo;those who cannot remember the past are condemned to repeat it.&rdquo;i have always been dissatisfied with that statement. it is too negative. history has positive experiences too. they are the ones we would like both to remember and to repeat.the three papers in this session are strong examples of positive early experiences in large-scale software engineering. the papers are:h.d. benington, &ldquo;production of large computer programs,&rdquo; proceedings, onr symposium, june 1956.w.a. hosier, &ldquo;pitfalls and safeguards in real-time digital systems with emphasis on programming,&rdquo; ire transactions on engineering management, june, 1961.w.w. royce, &ldquo;managing the development of large software systems: concepts and techniques,&rdquo; proceedings, wescon, august 1970.given the short lifespan of the software field, they can certainly be called &ldquo;historic.&rdquo; indeed, since many people date the software engineering field from the nato garmisch conference in 1968, two of them can even be called &ldquo;prehistoric.&rdquo; they are certainly sufficiently old that most people in the software engineering field have not been aware of them. the intent of this session is to remedy this situation by reprinting them in the conference proceedings, and by having the authors (or, in one case, hosier's colleague j.p. haverty) discuss both the lessons from their papers which are still equally valid today, and the new insights and developments which have happened in the interim.
haemo dialysis software architecture design experiences. in this paper we present the experiences and architecture from a research project conducted in cooperation with two industry partners. the goal of the project was to reengineer an existing system for haemo dialysis machines into a domain specific software architecture. our main experiences are (1) architecture design is an iterative and incremental process, (2) software quality requires a context, (3) quality attribute assessment methods are too detailed for use during architectural design, (4) application domain concepts are not the best abstractions, (5) aesthetics guides the architect in finding potential weaknesses in the architecture, (6) it is extremely hard to decide when an architecture design is ready, and (7) documenting software architectures is an important problem. we also present the architecture and design rational to give a basis for our experiences. we evaluated the resulting architecture by implementing a prototype application.
software architectures: critical success factors and cost drivers. some useful perspectives on the potential and the pitfalls of software architecture investments can be gained via analysis of software architecture critical success factors and their associated cost and benefit drivers. basically, the potential of software architecture investments comes from appropriately identifying and exploiting positive cost-benefit relationships. the pitfalls come from neglecting critical success factors or from making unrealistic assumptions about their associated cost drivers. examples from practice of both potential and pitfalls are given in the context of a table which summarizes a framework of software architecture critical success factors and cost drivers being developed at usc
production of large computer programs. the paper is adapted from a presentation at a symposium on advanced programming methods for digital computers sponsored by the navy mathematical computing advisory panel and the office of naval research in june 1956. the author describes the techniques used to produce the programs for the semi-automatic ground environment (sage) system.
software engineering: as it is. this paper presents a view of software engineering as it is in 1979. it discusses current software engineering practice with respect to lessons learned in the past few years, and concludes that the lessons are currently not heeded roughly half of the time. the paper discusses some of the factors which may account for this lag, including rapid technological change, education shortfalls, technology transfer inhibitions, resistance to disciplined methods, inappropriate role models, and a restricted view of software engineering. the paper also updates a 1976 state of the art survey of software engineering technology, including such topics as requirements and specifications, design, programming, verification and validation, maintenance, software psychology, and software economics. it concludes that the field is making solid progress, but that it is growing more complex at a faster rate than we can put it in order.
polymorphism measures for early risk prediction. polymorphism is an essential feature of the object-oriented paradigm. however, polymorphism induces hidden forms of class dependencies, which may impact software quality. in this paper, we define and empirically investigate the quality impact of polymorphism on oo design. we define measures of two main aspects of polymorphic behaviors provided by the c++ language: polymorphism based on compile time linking decisions (overloading functions for example) and polymorphism based on run-time binding decisions (virtual functions for example). then, we validate our measures by evaluating their impact on class fault-proneness, a software quality attribute. the results show that our measures are capturing different dimensions than loc a size measure, as well as they are significant predictors of fault proneness. in fact, we show that they constitute a good complement to the existing oo design measures.
quantitative evaluation of software quality. the study reported in this paper establishes a conceptual framework and some key initial results in the analysis of the characteristics of software quality. its main results and conclusions are: &bull; explicit attention to characteristics of software quality can lead to significant savings in software life-cycle costs. &bull; the current software state-of-the-art imposes specific limitations on our ability to automatically and quantitatively evaluate the quality of software. &bull; a definitive hierarchy of well-defined, well-differentiated characteristics of software quality is developed. its higher-level structure reflects the actual uses to which software quality evaluation would be put; its lower-level characteristics are closely correlated with actual software metric evaluations which can be performed. &bull; a large number of software quality-evaluation metrics have been defined, classified, and evaluated with respect to their potential benefits, quantifiability, and ease of automation. &bull;particular software life-cycle activities have been identified which have significant leverage on software quality. most importantly, we believe that the study reported in this paper provides for the first time a clear, well-defined framework for assessing the often slippery issues associated with software quality, via the consistent and mutually supportive sets of definitions, distinctions, guidelines, and experiences cited. this framework is certainly not complete, but it has been brought to a point sufficient to serve as a viable basis for future refinements and extensions.
a laboratory for the development and evaluation of bmd software quality enhancement techniques. this paper describes a software quality laboratory which will be used to develop new software quality analysis tools and evaluate their effectiveness. the laboratory will consist of a centralized data base for storing information about programs and a set of analysis routines which can be invoked interactively. a major effort using the laboratory will be the development of an executable assertion language. the laboratory will also be used to perform research in program verification and testing.
software requirements negotiation: some lessons learned. negotiating requirements is one of the first steps in any software system life cycle, but its results have probably the most significant impact on the system's value. however, the processes of requirements negotiation are not well understood. we have had the opportunity to capture and analyze requirements negotiation behavior for groups of projects developing library multimedia archive systems, using an instrumented version of the usc winwin groupware system for requirements negotiation. some of the more illuminating results were: most stakeholder win conditions were noncontroversial (were not involved in issues); negotiation activity varied by stakeholder role; lco package quality (measured by grading criteria) could be predicted by negotiation attributes; and winwin increased cooperativeness, reduced friction, and helped focus on key issues
the evaluation of large, complex uml analysis and design model. this paper describes techniques for analyzing largeuml models. the first part of the paper describesheuristics and processes for creating semantically correctuml analysis and design models. the second part of thepaper briefly describes the internal designadvisorresearch tool that was used to analyze siemens models.the results are presented and some interestingconclusions are drawn.
the trw software productivity system. this paper presents an overview of the trw software productivity system (sps), an integrated software support environment based on the unix operating system, a wide range of trw software tools, and a wideband local network. section 2 summarizes the quantitative and qualitative requirements analysis upon which the system is based. section 3 describes the key architectural features and system components. finally, section 4 discusses our conclusions and experience to date.
metrics for model driven requirements development. the cmmi defines two process areas associated with requirements elicitation: requirements development (rd) and requirements management (reqm). the measurements and analysis process area (ma) requires measurements and quantitative objectives for rd and reqm, but nowhere does it state what those measurements are. furthermore, in order to extract measurements and evaluate them, a process must enable or otherwise support the taking of measurements. it is especially difficult to do this during requirements development, as it is generally viewed as a writing activity that does not lend itself to quantitative measurements. this paper describes a cmmi compliant formal approach to measurement and analysis during a model-driven requirements development process. it presents a set of metrics that were used successfully on several siemens projects, describing team dynamics, project size and staffing, how the metrics were captured and used, and lessons learned.
software component models. component-based development (cbd) is an important emerging topic in software engineering, promising long sought after benefits like increased reuse and reduced time-to-market (and hence software production cost). however, there are at present many obstacles to overcome before cbd can succeed. for one thing, cbd success is predicated on a standardised market place for software components, which does not yet exist. in fact currently cbd even lacks a universally accepted terminology. existing component models adopt different component definitions and composition operators. therefore much research remains to be done. we believe that the starting point for this endeavour should be a thorough study of current component models, identifying their key characteristics and comparing their strengths and weaknesses. a desirable side-effect would be clarifying and unifying the cbd terminology. in this tutorial, we present a clear and concise exposition of all the current major software component models, including a taxonomy. the purpose is to distill and present knowledge of current software component models, as well as to present an analysis of their properties with respect to commonly accepted criteria for cbd. the taxonomy also provides a starting point for a unified terminology.
an experiment in technology transfer: paisley specification of requirements for an undersea lightwave cable system. from may to october 1985 members of the undersea systems laboratory and the computer technology research laboratory of at&t bell laboratories worked together to apply the executable specification language paisley to requirements for the &ldquo;sl&rdquo; communications system. this paper describes our experiences and answers three questions based on the results of the experiment: can sl requirements be specified formally in paisley? can members of the sl project learn to read and write specifications in paisley? how would the use of paisley affect the productivity of the software-development team and the quality of the resulting software?
prototyping vs. specifying: a multi-project experiment. in this experiment, seven software teams developed versions of the same small-size (2000-4000 source instruction) application software product. four teams used the specifying approach. three teams used the prototyping approach. the main results of the experiment were: prototyping yielded products with roughly equivalent performance, but with about 40% less code and 45% less effort. the prototyped products rated somewhat lower on functionality and robustness, but higher on ease of use and ease of learning. specifying produced more coherent designs and software that was easier to integrate. the paper presents the experimental data supporting these and a number of additional conclusions.
educating software engineering students to manage risk. in 1996, usc switched its core two-semester software engineering course from a hypothetical-project, homework-and-exam course based on the bloom taxonomy of educational objectives (knowledge, comprehension, application, analysis, synthesis, evaluation). the revised course is a real-client team-project course based on the cresst model of learning objectives (content understanding, problem solving, collaboration, communication, and self-regulation). we used the cresst cognitive demands analysis to determine the necessary student skills required for software risk management and the other major project activities, and have been refining the approach over the last four years of experience, including revised versions for one-semester undergraduate and graduate project course at columbia. this paper summarizes our experiences in evolving the risk management aspects of the project course. these have helped us mature more general techniques such as risk-driven specifications, domain specific simplifier and complicator lists, and the schedule as an independent variable (ssiv) process model. the largely positive results in terms of review pass/fail rates, client evaluations, product adoption rates, and hiring manager feedback are summarized as well.
about the development of a point of sale system: an experience report. this report comprises some experiences, which were made during the development of a point of sale (pos) system. specific about the project is the fact that it started as an attempt to develop customizable standard software, and then was restructured to deliver a unique project solution. this report details the situation before and after the restructuring, and discusses the experiences made through the ongoing development. these experiences relate mostly to three areas, which are: software project management, prototyping, and testing.
theory-w software project management: a case study. the search for a single unifying principle to guide software project management has been relatively unrewarding to date. most candidate principles are either insufficiently general to apply in many situations, or so general that they provide no useful specific guidance. this paper presents a candidate unifying principle which appears to do somewhat better. reflecting various alphabetical management theories (x, y, z), it is called the theory w approach to software project management. theory w: make everyone a winner the paper explains the theory w principle and its two subsidiary principles: plan the flight and fly the plan; and, identify and manage your risks. to test the practicability of theory w, a case study is presented and analyzed: the attempt to introduce new information systems to a large industrial corporation in an emerging nation. the case may seem unique, yet it is typical. the analysis shows that theory w and its subsidiary principles do an effective job both in explaining why the project encountered problems, and in prescribing ways in which the problems could have been avoided.
observations and lessons learned from automated testing. this report addresses some of our observations made in a dozen of projects in the area of software testing, and more specifically, in automated testing. it documents, analyzes and consolidates what we consider to be of interest to the community. the major findings can be summarized in a number of lessons learned, covering test strategy, testability, daily integration, and best practices.the report starts with a brief description of five sample projects. then, we discuss our observations and experiences and illustrate them with the sample projects. the report concludes with a synopsis of these experiences and with suggestions for future test automation endeavors.
dimensions of software engineering course design. a vast variety of topics relate to the field of software engineering. some universities implement curricula covering all aspects of software engineering. a number of other courses cover detailed aspects, e.g. programming, usability and security issues, analysis, architecture, design, and quality. other universities offer general curricula considering software engineering in few or single course only. in each case, a course set has to be defined which directly relates to a specific student outcome. this work provides a method for categorizing and analyzing a course set within abstract dimensions for course design. we subsequently show the results of applying the dimensions to the course degree scheme in use. the course design dimensions can also be related to the student outcomes defined in se2004 cc section 3.2 [10].
balancing agility and discipline: evaluating and integrating agile and plan-driven methods. rapid change and increasing software criticality drive successful development and acquisition organizations to balance the agility and discipline of their key processes. the emergence of agile methods in the software community is raising the expectations of customers and management, but the methods have shortfalls and their compatibility with traditional plan-driven methods such as those represented by cmmi, iso-15288, and uk-defstan-00-55 is largely unexplored.this tutorial pragmatically examines the aspects of agile and plan-driven methods and provides an approach to balancing through examples and case studies.
database system support for software engineering. the activity of computer-aided software engineering (case) generates much data. although there are few, if any, database system products with features that attend to the requirements of case environments, there is a flurry of research work in the database field to develop technology to meet these requirements. the purpose of this paper is to raise the level of awareness in the software engineering community about this research on database systems for design applications. it describes technical problems and proposed solutions, and provides an extensive bibliography.
second international workshop on from software requirements to architectures (straw?03). the second international workshop on from software requirements to architectures (straw'03) was held in portland, oregon, usa on 9 may 2003 just after the twenty- fifth international conference on software engineering (icse'03). this brief paper outlines the motivation, goals, and organization of the workshop, summarizes the presen- tations, and, along the way, gathers some lessons learned about running a workshop.
4th international workshop on scenarios and state machines: models, algorithms and tools (scesm'05). no abstract available
a scalable formal method for design and automatic checking of user interfaces. the article addresses the formal specification, design and implementation of the behavioral component of graphical user interfaces. the complex sequences of visual events and actions that constitute dialogs are specified by means of modular, communicating grammars called veg (visual event grammars), which extend traditional bnf grammars to make them more convenient to model dialogs.a veg specification is independent of the actual layout of the gui, but it can easily be integrated with various layout design toolkits. moreover, a veg specification may be verified with the model checker spin, in order to test consistency and correctness, to detect deadlocks and unreachable states, and also to generate test cases for validation purposes.efficient code is automatically generated by the veg toolkit, based on compiler technology. realistic applications have been specified, verified and implemented, like a notepad-style editor, a graph construction library and a large real application to medical software. it is also argued that veg can be used to specify and test voice interfaces and multimodal dialogs. the major contribution of our work is blending together a set of features coming from gui design, compilers, software engineering and formal verification. even though we do not claim novelty in each of the techniques adopted for veg, they have been united into a toolkit supporting all gui design phases, that is, specification, design, verification and validation, linking to applications and coding.