Search

The term software engineering has had a problematic history since its appearance in the 1960s. At first seen as a euphemism for programming, it has now come to encompass a wide range of activities. At its core lies the desire of software developers to mimic 'real' engineers, and claim the status of an engineering discipline. Attempts to establish such a discipline, however, confront pressing commercial demands for cheap and timely software products. This paper briefly examines some of the claims for the engineering nature of software development, before moving to argue that the term 'engineering' itself carries with it some unwanted baggage. This contributes to the intellectual quandary in which software development finds itself, and this is exacerbated by many writers who rely upon and propagate a mythical view of 'engineering.' To complicate matters further, our understanding of software development is grounded in a series of metaphors that highlight some key aspects of the field, but push other important issues into the shadows. A rereading of Brooks' “No Silver Bullet” paper indicates that the metaphorical bases of software development have been recognized for some time. They cannot simply be jettisoned, but perhaps they need widening to incorporate others such as Brooks' concepts of growth and nurture of software. Two examples illustrate the role played by metaphor in software development, and the paper concludes with the idea that perhaps we need to adopt a more critical stance to the 'engineering' roots of our endeavours. [ABSTRACT FROM AUTHOR]

Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems, i.e., systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events, etc., used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support. [ABSTRACT FROM AUTHOR]

Developing and maintaining large-scale software systems is very expensive. The concept of software architecture has recently emerged as a way to support the evolution of large-scale software systems. Several architecture description languages (ADLs) have been proposed to support the specification of software architectures. However, current ADLs do not provide strong support for the analysis of software architecture properties. On the other hand, various analysis tools have been developed for system analysis in the formal verification community. In this paper, we make two contributions. First, for the tools which are applicable to the property analysis of software architectures, we establish a connection between different analysis tools and the software systems modeled by architecture description languages. Second, we conduct experiments to study the performance of four different analysis tools in detecting deadlocks. Based on these experiments, we are able to compare the efficiency of these analysis tools in verifying certain software properties. [ABSTRACT FROM AUTHOR]

This paper describes a methodology for the specification and analysis of distributed real-time systems using the toolset called PARAGON. PARAGON is based on the Communicating Shared Resources paradigm, which allows a real-time system to be modeled as a set of communicating processes that compete for shared resources. PARAGON supports both visual and textual languages for describing real-time systems. It offers automatic analysis based on state space exploration as well as user-directed simulation. Our experience with using PARAGON in several case studies resulted in a methodology that includes design patterns and abstraction heuristics, as well as an overall process. This paper briefly overviews the communicating shared resource paradigm and its toolset PARAGON, including the textual and visual specification languages. The paper then describes our methodology with special emphasis on heuristics that can be used in PARAGON to reduce the state space. To illustrate the methodology, we use examples from a real-life system case study. [ABSTRACT FROM AUTHOR]

One of the most intractable problems in software is getting engineers to consistently use effective methods. The Software Engineering Institute (SEI) has worked on this problem for a number of years and has developed effective methods for addressing it. This paper describes these methods and shows what they have accomplished with several hundred students and working engineers. After first describing the problem of changing engineers' practices, the paper discusses the logic engineers typically follow in deciding what methods to use. Next is a description of the Personal Software Process (PSP) and the Team Software Process (TSP). Finally, the implications of SEI's experiences with the PSP and TSP are described, with particular emphasis on software engineering and computer science education. [ABSTRACT FROM AUTHOR]

Programmes in “Software Engineering” have become a source of contention in many universities. Some Computer Science departments, many of which have used that phrase to describe individual courses for decades, claim software engineering as part of their discipline. However, Engineering faculties claim “Software Engineering” as a new speciality in the family of engineering disciplines. This paper discusses the differences between traditional computer science programmes and most engineering programmes and argues that we need programmes that follow the traditional engineering approach to professional education and educate engineers whose speciality within engineering is software construction. One such programme is described. [ABSTRACT FROM AUTHOR]

This paper describes how we have modified a software engineering stream within a computer science course to include broader concepts of systems engineering. We justify this inclusion by showing how many reported problems with large systems are not just software problems but relate to system issues such as hardware and operational processes. We describe what we mean by ‘systems engineering’ and go on to discuss the particular course structure which we have developed. We explain, in some detail, the contents of two specific systems engineering courses (Software Intensive Systems Engineering and Critical Systems Engineering) and discuss the problems and challenges we have faced in making these changes. In the appendix, we provide details of the case studies which are used as linking themes in our courses. [ABSTRACT FROM AUTHOR]

This paper describes the development of an undergraduate degree programme in software engineering over the ten year period from 1988 to 1998. Particular emphasis is given to the fundamental principles that have been established to guide the creation and evolution of this programme during this period, and to ensure that it has been distinctively a course in software engineering rather than in any other branch of computing. To this end, the fundamental engineering characteristics of the programme are compared with those of undergraduate courses in other branches of engineering. Desirable future developments in this programme are then discussed, and finally the different principles identified in the paper are evaluated. [ABSTRACT FROM AUTHOR]

Software engineering education has a 30-year history. It is a story of academics struggling to fulfill industry needs with almost no support from computer science curriculum designers. It is a story of industry finally winning over some of academia to teach software engineering rather than vanilla computer science. It is a story of a discipline still incomplete, but having made great strides in the last decade. This paper discusses the succeeding eras of software engineering education, from lone teachers to master's curricula to undergraduate degree programs. Even though the maturity of the discipline is as yet unattained, it will achieve adult status through practice, not by waiting for academia to glacially catch up. [ABSTRACT FROM AUTHOR]

As software technologies advance, the software community uses the newest and most powerful technology and associated notations. However, mapping software with a set of notations that would survive the test of time is becoming increasingly difficult. A survey of current methodologies indicates that half-lives of various software notations are short. The dependence of software notations on programming languages and environment specific methodologies often makes these notations obsolete. In this paper, development of a standard set of software notations that is independent of programming paradigms, yet extensible enough to accommodate programming needs, is proposed. [ABSTRACT FROM AUTHOR]

Technical issues are important for software work, but so are personal disciplines, team-working skills, and application-domain knowledge. Also, much like an artistic performance, first-class software engineering requires constant practice, good technique, and effective coaching. The challenge of producing high-quality large-scale software products is substantial today and will be even more demanding in the future. Without concerted action, we cannot expect software organizations' capabilities to improve. To address these problems, the Software Engineering Institute (SEI) has developed the Personal Software Process (PSP) and the Team Software Process (TSP). This paper addresses the problems of software engineering and discusses the intellectual nature of software work. It then reviews the characteristics of this kind of work and describes the principal conditions for effective software performance. In the conclusion, the author makes some observations about the challenges ahead and the future actions required. [ABSTRACT FROM AUTHOR]

The contribution of this paper is three empirical evaluations of a reference model for the practice of software reuse. Our research thesis is that software development based upon a software reuse reference model improves quality of products, productivity of processes and product time-to-market for many software development enterprises. The definition and investigation of such a model has been carried out using three steps. First, the reference model is developed based on existing software reuse concepts. Second, this reference model is empirically evaluated using three studies: one using a survey method, one using a case studies method, and one using a legacy studies method. Third, the impact of the reference model on software development productivity, quality, and time-to-market is empirically derived. [ABSTRACT FROM AUTHOR]

With the rapid growth of network computing, the demand for large-scale and complex software systems has increased dramatically. However, the development of large-scale and complex software systems is much more difficult and error prone. This is due to the fact that techniques and tools for assuring the correctness and reliability of software systems lag far behind the increasing growth in size and complexity of software systems. The concept of software architecture has recently emerged as a new way to improve our ability to effectively construct and maintain large-scale complex software systems. The architecture based development of software systems focuses on the architectural elements and their overall interconnection structure. Several Architectural Definition Languages (ADLs) have been proposed for specifying domain specific or general purpose architectures. On the other hand, formal verification is rapidly becoming a promising and automated method to ensure the accuracy and correctness of software systems. In this paper, we survey several architecture description languages and formal verification methods. We present an environment to conduct experiments to study the performance of five different verification tools on software architecture specifications. Based on these experiments, we are able to compare the efficiency of these verification tools in verifying certain software property. [ABSTRACT FROM AUTHOR]

This paper summarizes several classes of software cost estimation models and techniques: parametric models, expertise-based techniques, learning-oriented techniques, dynamicsbased models, regression-based models, and composite-Bayesian techniques for integrating expertise-based and regression-based models. Experience to date indicates that neural-net and dynamics-based techniques are less mature than the other classes of techniques, but that all classes of techniques are challenged by the rapid pace of change in software technology. The primary conclusion is that no single technique is best for all situations, and that a careful comparison of the results of several approaches is most likely to produce realistic estimates. [ABSTRACT FROM AUTHOR]

ASTRAL is a formal specification language for real-time systems. It is intended to support formal software development and, therefore, has been formally defined. The structuring mechanisms in ASTRAL allow one to build modularized specifications of complex systems with layering. A real-time system is modeled by a collection of state machine specifications and a single global specification. This paper discusses the ASTRAL Software Development Environment (SDE), which is an integrated set of design and analysis tools based on the ASTRAL formal framework. The tools that make up the support environment are a syntax-directed editor, a specification processor, a verification condition generator, a browser kit, a model checker, and a mechanical theorem prover. [ABSTRACT FROM AUTHOR]

This paper investigates implementations of process algebras which are suitable for modeling concurrent real-time systems. It suggests an approach for efficiently implementing real-time semantics using dynamic priorities. For this purpose a process algebra with dynamic priority is defined, whose semantics corresponds one-to-one to traditional real-time semantics. The advantage of the dynamic-priority approach is that it drastically reduces the state-space sizes of the systems in question while preserving all properties of their functional and real-time behavior. The utility of the technique is demonstrated by a case study that deals with the formal modeling and verification of several aspects of the widely-used SCSI-2 bus-protocol. The case study is carried out in the Concurrency Workbench of North Carolina, an automated verification tool in which the process algebra with dynamic priority is implemented. It turns out that the state space of the bus-protocol model is about an order of magnitude smaller than the one resulting from real-time semantics. The accuracy of the model is proved by applying model checking for verifying several mandatory properties of the bus protocol. [ABSTRACT FROM AUTHOR]

Postgraduate degree programs in “software engineering” have been in existence for some time and now undergraduate degree programs with this title are beginning to appear. A number of questions and issues of only moderate importance with respect to the postgraduate programs now become critical and of overriding importance. While one could (and did) by and large gloss over these issues earlier, this will be much more difficult, and probably impossible, in the future. These issues must be resolved in a wider context than that in which they have been dealt with before, involving engineering in the universities and professional engineering societies in the larger social context. Much of the disagreement regarding these issues can, ultimately, be traced back to differing fundamental views and definitions of the term “engineering” and whether “software engineering” should be treated as “just” another engineering discipline or in a significantly and fundamentally different way. After examining two different definitions and views of “engineering,” this paper states and discusses a number of the questions and issues which planners of new undergraduate software engineering degree programs must deal with. Some pros and cons of various alternative answers are presented and a few answers suggested. The issues discussed here begin with questions of general policy and concept (e.g., which culture – that of the traditional engineering disciplines or that of computer science – should be instilled in the students in these new degree programs), include organizational matters (e.g., the position of the new degree program in the university hierarchy) and end with selected, more detailed questions regarding the curriculum (e.g., how to deal with programming, design and management topics). It is conjectured that, although the scientific foundation for the undergraduate software engineering degree programs must and will come from computer science, their culture and orientation must come from engineering if they and their graduates are to be successful in satisfying society's needs in the long term. [ABSTRACT FROM AUTHOR]

In this paper we describe and review the course plan and syllabus we use in a course on formal methods in software engineering currently included in the degree in Informatics of the Faculty of Sciences at the University of Bologna. The course matches the theory of formal methods with their practice based on actual tool usage. In fact, the course is centered upon a project whose main goal is to let students learn some formal specification techniques, all supported by specific tools. The students use well-known notations for both requirements specification and formal design. The formal methods we use are based on the Z notation for requirements specification and on the Larch family of languages for design specifications. [ABSTRACT FROM AUTHOR]

A project course in software engineering is often part of the curriculum in computer engineering or computer science. This paper studies the relationship between academic and industrial projects in software engineering. The purpose is to compare the practices followed in a project-course approach with the practices of professional software engineers. The approach is to compare the measurements obtained from academic and industrial projects. The critical factors regarding the process, the people and the project are discussed. The structure of the software processes and the measurement tools are presented. The data analyses show that the academic projects are found to be strongly dominated by programming activities. Based on the data from the industrial projects, we formulate seven recommendations to improve the software engineering practices in academic projects. They are related to management, predevelopment, development, testing, reviews documentation and team activities. The concluding remarks discuss some of the actions that could be taken to improve academic projects. [ABSTRACT FROM AUTHOR]

Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to "behave" in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena. [ABSTRACT FROM AUTHOR]

Software engineering is an often used term to describe the activities, methods, and tools of large scale software development. There is an ongoing discussion whether Software Engineering can be considered as an engineering discipline. In many respects the development of software shares common properties of other engineering disciplines. In contrast to “classical” engineering fields, theories, questions, and approaches from the social sciences are more important than those from the natural sciences. This is investigated here by comparing the situation found in software engineering with several concepts of engineering in general. Three viewpoints are used to guide this comparison: one is a social stereotype of engineers; the second is the organization of engineering profession organizations; and the third are capabilities which the engineers of the future will need. [ABSTRACT FROM AUTHOR]