Software Engineering: A Roadmap

Anthony Finkelstein Jeff Kramer

Department of Computer Science Department of Computing
University College London Imperial College
Gower St. 180 Queens Gate
London WC1E 6BT, UK London SW7 2BZ
+44 020 7380 7293 +44 020 7594 8271
[email protected] [email protected]

ABSTRACT We do not aim to provide a summary of the overall state-

This paper provides a roadmap for software engineering. It of-the-art in software engineering. The reader interested in
identifies the principal research challenges being faced by a general introduction should refer to the many excellent
the discipline and brings together the threads derived from textbooks that are available. Best known, and a good
the key research specialisations within software starting point, are [5], [3] and [2], all of which are
engineering. The paper draws heavily on the roadmaps reasonably up to date. [1] affords a good start to the broader
covering specific areas of software engineering research literature. The research literature on software engineering is
collected in this volume. readily available. IEEE Transactions on Software
Engineering (IEEE-TSE) and ACM Transactions on
Keywords
Software Engineering and Methodology (ACM-TOSEM)
software engineering, research, discipline, future, strategy
are the principal archival journals. There are a large number
1 INTRODUCTION of specialised journals including for example Automated
This paper attempts to construct a roadmap for software Software Engineering (ASE), Requirements Engineering
engineering research. It seeks to identify the principal Journal (REJ), Software Process Journal (SPJ). IEEE
research challenges being faced by the discipline and to Software plays an important role in bridging between the
bring together the threads derived from the key research ÔpureÕ research literature and practitioner-oriented articles.
specialisations within software engineering. In doing so it The International Conference on Software Engineering
draws heavily on the roadmaps covering specific areas of (ICSE) is the flagship conference of the software
software engineering research collected in this volume. engineering community; papers in this conference are
generally of a high standard and the proceedings reflect a
Definitions are notoriously difficult but for working
broad view of research across software engineering. The
purposes and those of this volume - software engineering is
European Software Engineering Conferences (ESEC) and
the branch of systems engineering concerned with the
the Foundations of Software Engineering Conferences
development of large and complex software intensive (FSE), which are held jointly in alternate years, are similar
systems. It focuses on: the real-world goals for, services to ICSE though have tended historically to have a slightly
provided by, and constraints on such systems; the precise
more ÔtheoreticalÕ orientation. There are a large number of
specification of system structure and behaviour, and the
specialised conferences and workshops ranging from
implementation of these specifications; the activities
established meetings such as the International Workshop on
required in order to develop an assurance that the
Software Specification and Design, International Software
specifications and real-world goals have been met; the
Architecture Workshop, International Symposium on
evolution of such systems over time and across system
Software Testing and Analysis to the Ôhot-topicÕ workshops
families. It is also concerned with the processes, methods
held in conjunction with ICSE. There are excellent
and tools for the development of software intensive systems
resources on the web (links are provided on the web site
in an economic and timely manner.
associated with this volume). General software engineering
announcements are distributed through the community-
wide ÒseworldÓ mailing list.
The structure of the paper is approximately as follows. In
sections 2 and 3 we discuss the changing context of
software system development and the changing orientation
of software engineering research. In section 4 we make
some broad observations about the evolution of the
discipline. Then, in section 5, we analyse the key research
challenges and show how these challenges are reflected in understandably, encountered significant resistance from
the specialised roadmaps that comprise the volume. We practitioners.
finish by drawing some broad and necessarily speculative
It has taken a long time for researchers to realise that we
and personal conclusions about the future of software
cannot expect industry to make very large big-bang
engineering.
changes to processes, methods and tools, at any rate
2 CONTEXT without substantial evidence of the value derivable from
The context of software system development is changing. those changes. This, accompanied again by the increased
Systems are rarely developed from scratch; most system disciplinary maturity, has lead to a higher ÒvalidityÓ barrier
development involves extension of preexisting systems and which research contributions must cross. It is readily
integration with ÔlegacyÕ infrastructure. These systems are observable that research that proposes new frameworks,
embedded in complex, highly dynamic, decentralised methods and processes are not accepted without positive
organisations; they are required to support business and evidence that they are of use rather than simply airy and
industrial processes which are continually reorganised to unfounded speculation.
meet changing consumer demands. The services that such a
Particular attention is being paid to the issue of scalability.
system provides must, for the life of the system, satisfy the
It has, in the past, proved all too easy for researchers to
requirements of a diverse and shifting group of
ignore or make light of the problems that the shear scale of
stakeholders. There is a shift towards client and user
industrial software systems development gives rise to.
centered approaches to development and an accompanying
Problems that appear simple in paper-and-pencil exercises
shift from a concern with whether a system will work
in the laboratory are often far from simple when dealing
towards how well it will work. Overall, fewer ÔbespokeÕ
with very large amounts of data. The internet too has
software systems are being constructed. Instead, generic
implications for scalability. In an open internet setting there
components are built to be sold into markets. Components
may be millions of potential users of a software service.
are selected and purchased Ôoff the shelfÕ with development
effort being refocused on configuration and While research methodology remains a potent issue there is
interoperability. some evidence of an increasing acceptance of
methodological diversity. Case studies, qualitative studies,
The resulting systems are composed from autonomous,
experiments, proof and mathematical analysis are being
locally managed, heterogeneous components, which are
combined judiciously to make a case for research
required to cooperate to provide complex services. They
contributions. Research is expected to, and increasingly
are, in general, distributed and have significant non-
does, build on the work of others. Using existing standards
functional constraints on their operation. There are a wide
and building on, rather than in parallel to, proven research
range of new, and constantly changing business models
contributions characterises the best research. There is
relating to the provision of software and software-mediated
however less tolerance for reinventing the wheel.
services resulting from internet and e-commerce
technology. 4 DISCIPLINE
In defining software engineering we described it as a
The overall setting is characterised by on the one hand an
Òbranch of systems engineeringÓ. Unfortunately systems
increasing business dependence on reliability of software
engineering, despite a long history, is less mature than
infrastructure and on the other hand rapid change and
software engineering! Software engineering research is
reconfiguration of business services necessitating rapid
increasingly aware of the interplay between systems
software development and frequent change to that software
context and software and there are attempts to take into
infrastructure.
account the co-development of hardware and organisational
3 ORIENTATION systems with software. We anticipate a further shift in
Reflecting an increased disciplinary maturity the orientation among software engineers towards a broader
ÔorientationÕ of software engineering research has changed. systems engineering view with software engineers taking a
Software engineering research is being more carefully lead in the creation of a truly integrated systems
targeted towards ÒrealÓ industrial problems. This entails engineering discipline
thorough problem analysis. Increasingly software
A traditional theme in software engineering discourse has
engineering research is aimed towards engineering
been Òwhy canÕt we build software like other engineers
solutions that are lightweight, in the sense that they make
build bridgesÓ [or similar traditional engineering product].
minimal assumptions about the engineering environment in
This refrain has lead to some productive thinking and has
which they are deployed. This is often related to the need
forced software engineers to think hard about
for solutions to be simple enough that they can be adopted
achievements, aspirations and the status of our claim to be
in practice. Much, but by no means all, software
ÔengineersÕ. It has however lead us to apply inappropriate
engineering research to date has been characterised by
analogies with, for example, mechanical and other
overly complex, heavyweight, solutions that have,
artefacts, which have fundamentally different ¥ Change - How can we cope with requirements change?
characteristics from software. It has also given rise to a How can we build systems that are more resilient or
perceived sense of inferiority, unjustified by the significant adaptive under change? How can we predict the effects
research accomplishments of software engineering. We of such changes?
believe that this self-deprecation has in turn had an adverse ¥ Non-functional Properties - How can we model non-
effect on the funding and the status of software engineering functional properties of systems and reason about
in computer science. There is some evidence that this them, particularly in the early stages of system
traditional theme is finally becoming less frequently heard development? How can these models be integrated
and that a more robust self-image with respect to other with other models used in system development?
disciplines is emerging. We need to recognize, claim and
¥ Service-view - How can we shift from a traditional
publicize our many successes.
product-oriented view of software system development
Software engineering has, to a large extent, historically towards a service view? What effects do new modes of
defined itself in terms of testing and debugging. Most software service delivery have on software
software engineering textbooks start with a discussion of development?
early error detection and removal. Software engineers seem ¥ Perspectives - How can we devise and support new
to enjoy talking about errors. Failures such as that of the structuring schemes and methods for separating
London Ambulance Service Computer Aided Despatch concerns?
system and the Ariane 5 receive much attention. While
¥ Non-classical life cycles - How can we adapt
such a focus on failures can be instructive - even
conventional software engineering methods and
construction engineers study bridge failures as a means of
techniques to work in evolutionary, rapid, extreme and
learning lessons - it can also be said to lead to a negative
other non-classical styles of software development?
orientation in which the absence of bugs rather than the
positive presence of quality, however defined, is the most ¥ Architecture - How can we represent, reason about and
important goal. The changing context of software manage the evolution of software architectures? How
development in which there is a pressing need to roll out a can we relate software architecture to other parts of the
service rapidly and to change it to meet new business software development process?
demands, forces a change in this outlook towards a more ¥ Configurability - How can we allow users, in the
positive ÔholisticÕ view of the role of software engineering broadest sense, to use components in order to
in delivering satisfaction to users. configure, customize and evolve systems?
5 RESEARCH CHALLENGES ¥ Domain specificity - How can we exploit the properties
A wholly mature discipline is one that is able to identify of particular domains (telecommunications, transport)
Òdead problemsÓ. Dead problems are those to which effort to make any of these challenges easier to address?
need no longer be devoted because they have been solved. The detailed tables that follow look at these challenges set
Computer science is slowly building up a list of such dead against the detailed challenges or pointers identified by the
problems reinforcing its claim as a mature discipline. By authors of the individual roadmaps. The tables also serve as
contrast software engineering is still struggling to identify a useful quick reference to the volume. A grayed box
its own dead problems. Any list we constructed of such indicates a clear and straightforwardly identifiable
problems would almost certainly be more controversial relationship between a ÔbigÕ challenge and a more fine-
than the attempt, which follows, to pick out key research grained one. Also included in the tables are links or cross-
challenges across software engineering. These overall references from one set of fine-grain challenges to another.
software engineering research challenges are not
comprehensive and the determined reader can infer our While the challenges that we have been identified do not
subsume all of the issues raised by the roadmaps they
view of dead problems from it. The questions associated
appear to subtly impact many of them. Very large
with each challenge are exemplars and individual
proportions of the fine-grained challenges relate to the big
researchers may derive much more specific research
challenges. Most of those which do not, relate different
questions. Clearly these challenges are not orthogonal and
areas of research activity as indicated by links. A small
there are complex relationships binding them together.
proportion of the fine-grained challenges relates to neither
Many of the most interesting research programmes look at
big challenges nor other parts of the research agenda. These
these relationships.
are, for the most part, technical problems blocking
¥ Compositionality - When we compose components advances in particular areas.
what effect does this have on the properties of those
components? Can we reason about, and engineer for,
the emergent properties of systems composed from
components whose behaviour we understand?
6 CONCLUSIONS
This paper takes a positive view of current progress and
future challenges in software engineering. We believe the
discipline has delivered and is well set to continue to
deliver both practical support to software developers and
the theoretical frameworks which will allow that practical
support to be adopted, used and extended with confidence.
It is well known that software engineering innovations take
a surprisingly long time to percolate through to every day
use [4]. Despite this lag current software engineering
practice is being radically reshaped by object-oriented
design methods, CASE tools with powerful code
generation, testing and analysis environments, development
patterns, incremental delivery based life-cycles, component
models and document management environments. All of
these have been formed through software engineering
research.
A vision of the future of software engineering suggests a
setting in which developers are able to wire together
distributed components and services (heterogeneous and
sourced over the net) having established at an early stage,
through rigorous (yet easy-to-use) formal analysis that the
particular configuration will meet the requirements (both
functional and non-functional). The overall process in
which this takes place will have seamless tool support that
extends through to change over the system or service life.
Each facet of the resulting system or service will be
traceable to (and from) the originating stakeholders who
will be involved throughout the process.
This vision is in fact an old one! The difference is that
making it a reality is now within our grasp. We know what
we have to do. What makes our field even more exciting is
that, in addition to the steady progress towards our vision,
there are also the discontinuities, such as was introduced in
the last ten years by the web. The impact of such major
innovations cannot be predicted but they certainly offer
wonderful new opportunities and challenges.
REFERENCES
1. Dorfman, M. & Thayer, R.H. (Eds) Software
Engineering, (November 1999), IEEE Computer
Society.
2. Ghezzi, C. Jazayeri, M. & Mandrioli, D. Fundamentals
of Software Engineering, (January 1991), Prentice Hall.
3. Pressman, R.S. Software Engineering : A PractitionerÕs,
4th edition (August 1996), McGraw Hill College Div.
4. Redwine S.T. & Riddle, W.E. Software Technology
Maturation, Proceedings of the 8th International
Conference on Software Engineering, 1985, pp 189-
200, IEEE Computer Society.
5. Sommerville, I. Software Engineering (International
Computer Science Series), 5th edition (November
1995) Addison-Wesley Pub Co.
1 Software Process Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
1.1 PML must be tolerant and allow for incomplete,
informal, and partial specification

1.2 PSEE must be non-intrusive. It must be possible to

deploy them incrementally.

1.3 PSEE must provide the software engineer with a clear 18

state of the software development process (from many
different viewpoints).

1.4 The scope of software improvement methods and

models should be widened in order to consider all the
different factors affecting software development
activities. We should reuse the experiences gained in
other business domains and in organizational behavior
research.

1.5 Statistics is not the only source of knowledge. We 23

should also appreciate the value of qualitative
observations.

2 Requirements Engineering Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

2.1 Better modelling and analysis of problem domains, as

opposed to the behaviour of software.

2.2 Development of richer models for capturing and

analysing non-functional requirements.

2.3 Bridging the gap between requirements elicitation 10

approaches based on contextual enquiry and more
formal specification and analysis techniques.

2.4 Better understanding of the impact of software

architectural choices on the prioritisation and evolution
of requirements.

2.5 Reuse of requirements models to facilitate the

development of system families and the selection of
COTS.

2.6 Multi-disciplinary training for requirements 25

practitioners.
3 Reverse Engineering Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
3.1 Teach reverse engineering, program understanding, 25
and software analysis in computer science, computer
engineering, and software engineering curricula.

3.2 Investigate infrastructure, methods, and tools for

continuous program understanding to support the
entire evolution of a software system from the early
design stages to the long-term legacy stages.

3.3 Develop methods and technology for computer-aided

data and database reverse engineering.

3.4 Develop tools that provide better support for human

reasoning in an incremental and evolutionary reverse
engineering process that can be customized to different
application contexts.

3.5 Concentrate on the tool adoption problem by

improving the usability and end-user programmability
of reverse engineering tools to ease their integration
into actual development processes.

4 Testing Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

4.1 Development of techniques and tools that will help

component users integrate and test the components
with their applications more efficiently and effectively

4.2 Creation of techniques and tools that can use precode 6

artifacts, such as architectural specifications, for
planning and implementing testing activities.

4.3 Development of techniques and tools for use in

estimating, predicting, and performing testing on
evolving software systems.

4.4 Establishment of effective processes for analyzing and

testing software systems.

4.5 Investigation of methods that use testing artifacts to

assist in software development.
5 Software Maintenance and Evolution Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
5.1 The production of new management approaches to
evolution, leading to better understanding of the
relationships between technology and business.

5.2 How can software be designed so that it can easily be

evolved?

5.3 More effective tools and methods for program 3

comprehension for both code and data

5.4 A better formalism and conceptualisation of

ÔmaintainabilityÕ; how do we measure it?

5.5 The development of a service-based model of software,

to replace a product view.

6 Software Architecture Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

6.1 Software architectures that support dynamic coalitions

of software services.

6.2 New techniques for composing heterogeneous

components, and certifying the properties of those
compositions.

6.3 Software architectures that adapting themselves to their 17

physical setting.

6.4 Design principles for making architectural tradeoffs

between correctness, resource consumption, and
reliability.

6.5 Self-monitoring systems.

7 Object-oriented modelling Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
7.1 To identify appropriate language means for modelling
an "aspect" of a system.

7.2 To separate a core modelling language from domain-

specific extensions.

7.3 To define the semantics of a high-level, heterogeneous 10

modelling language

7.4 To develop means to compose and to refine complex

structured models.

7.5 To identify guidelines for an incremental, round-trip

software development process

8 Software Engineering for Middleware Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

8.1 A large class of distributed systems need not be built

from scratch but can exploit middleware to resolve
heterogeneity and distribution of the system
components.

8.2 State of practice middleware products enable software

engineers to build systems that are distributed across a
local area network.

8.3 The state of the art in middleware research aims to

push this boundary towards Internet-scale distribution,
adaptive systems and middleware that can meet
reliability and hard real-time constraints.

8.4 The software engineering challenges lie in devising 7

methods, notations and tools for distributed system
construction that systematically build and exploit what
middleware products will deliver, now and in the future.

8.5 Software engineering research can contribute to the 18, 19

further development of middleware, particularly in the
areas of version- and configuration management and
development environments
9 Software Analysis Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
9.1 Checking conformance of code to designs is likely to
become a central problem for software analysis.

9.2 Tools that analyze designs in their own right will grow
in importance.

9.3 Abstract design models are the lynchpin for exploiting

code analyses in this context: they not only make the
analysis results more relevant, but can be used to focus
the analysis and extend it.

9.4 Both powerful tools that can check complex properties

and simpler tools that provide rapid but rough results
will be useful.

9.5 Many kinds of analysis will play a role: static and

dynamic, sound and unsound, operational and
declarative.

10 Formal Specification Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

10.1 Formal specification technology needs to provide

constructive methods for specification development,
analysis, and evolution.

10.2 Formal specifications need to be fully integrated with

other software products and processes all along the
software lifecycle.

10.3 Specification techniques should move from functional

design to requirements engineering; higher-level,
problem-oriented ontologies must therefore be
supported instead of program-oriented ones.

10.4 The scope of formal specification and analysis must be

extended to cover non-functional requirements that play
a prominent role in architectural design --such as
performance, security, fault tolerance, accuracy,
maintainability, etc.

10.5 Tomorrow's technology will provide lightweight 9

interfaces for multiparadigm specification and analysis.
11 Mathematical Foundations of Software Engineering Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
11.1 Representing behaviour (including concurrency and
duration of activities) and being able to analyse it.
There may be many different kinds of behaviour and
there is no obvious necessity to have a universal
representation - quite the opposite! Engineering tools
are the most useful when they are specific, so different
classes of problems may demand differing languages
to represent them.

11.2 Representing 'ility' properties and devising

corresponding engineering theories enabling the use of
the 'ility' in design.

11.3 Systematising domain knowledge for the area of

application. This is hard, long and often tedious work.

11.4 Defining the specification and refinement

patterns/architectures required to encapsulate design
choices. This results in support for the 'cookbook'
aspects of normal design. The work on product line
architectures, if properly driven towards formal
engineering systematisation, will contribute enormously
to this.

11.5 Better understanding of modularity principles. The only

effective method for dealing with the complexity of
software based systems is decomposition. Modularity is
a property of systems, which reflects the extent to which
it is decomposable into parts, from the properties of
which we are able to predict the properties of the
whole. Languages that do not have sufficiently strong
modularity properties are doomed to failure, in so far
as predictable design is concerned.

11.6 Improved and specialised analysis tools, many more 9

abstraction (interpretation) tools to address
feasibility/tractability of analysis; more and specialised
decision procedures for interesting properties (using
abstractions to approximate same).
12 Software Reliability & Dependability Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
12.1 Shifting the focus from software reliability to user-
centred measures of dependability in complete
software-based systems.

12.2 Influencing design practice to facilitate dependability

assessment.

12.3 Propagating awareness of dependability issues and the 25

use of existing, useful methods.

12.4 Injecting some rigour in the use of process-related

evidence for dependability assessment.

12.5 Better understanding issues of diversity and variation as

drivers of dependability.

13 Software Engineering for Performance Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

13.1 To create a well understood formalism, probably based 7

on UML, allowing performance annotations to design
models.

13.2 To create a methodology which embeds performance

questions within the software lifecycle in terms of widely
used approaches.

13.3 To integrate solution tools for performance measures

transparently within extended design tools, such as
object oriented CASE tools.

13.4 To develop ways of returning performance results from

specialised tools in terms of the design models from
which they were derived.

13.5 To integrate performance modelling measures within a 4

performance monitoring and testing framework in a
consistent manner.
14 Software Engineering for Real-Time Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
14.1 The development of a system architecture that supports 4
the precise specification of the interfaces between
components in the value domain and in the temporal
domain, such that the components can be developed
and tested independently.

14.2 The constructive integration of exisiting prevalidated

components into diverse system contexts.

14.3 The systematic validation of ultradependable real-time

systems that are used in safety critical applications.

14.4 The development of a framework that supports the 12

generic implementation of fault-tolerance without
introducing additional complexity into the application
software.

14.5 The derivation of tight upper bounds for the worst-case

execution time of real-time programs.

15 Software Engineering for Safety Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

15.1 Provide readier access to formal methods for 10, 7

developers of safety-critical systems by further
integration of informal and formal methods.

15.2 Develop better methods for safety analysis of product

families and safe reuse of Commercial-Off-The-Shelf
software.

15.3 Improve the testing and evaluation of safety-critical 4

systems through the use of requirements-based testing,
evaluation from multiple sources, model consistency,
and virtual environments.

15.4 Advance the use of runtime monitoring to detect faults

and recover to a safe state, as well as to profile system
usage to enhance safety analyses.

15.5 Promote collaboration with related fields in order to 16, 12, 6,

exploit advances in areas such as security and
survivability, software architecture, theoretical computer 11, 25
science, human factors engineering, and software
engineering education.
16 Software Engineering for Security Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
16.1 Integrating security considerations smoothly into early 2
life-cycle activities: uniform application of cost-benefit
analyses to both functional, and security requirements;
unified modelling approaches to integrate the
engineering of both functional requirements and
security requirements.

16.2 The development of architectures and designs that are

easier to adapt to rapidly evolving security policies, and
approaches to facilitate the integration of security
features into legacy systems.

16.3 The invention of cogent, flexible economic models of

adversary behaviour which can underly the rational
design of software copy-protection and watermarking
techniques in different application contexts.

16.4 Better techniques for formulating desirable security 9

properties, and the development of scalable,
predictable, static and dynamic verification tools to
evaluate the security of software systems.

16.5 The development of automated, robust, flexible infra- 8

structures for post-deployment system administration,
that can adapt to the organization's confidentiality,
non-repudiation, and trust-delegation requirements.

17 Software Engineering for Mobility Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

17.1 Mobility challenges old assumptions and demands

novel software engineering solutions including new
models, algorithms, and middleware.

17.2 Coordination mechanisms must be developed to bridge

effectively a clean abstract model of mobility and the
technical opportunities and complexities of wireless
technology, device miniaturization, and code mobility.

17.3 Logical mobility opens up a broad range of new design

opportunities, physical mobility forces consideration of
an entirely new set of technical constraints, and the
integration of the two is an important juncture in the
evolution of software engineering as a field.

17.4 Key concepts shaping software engineering research on

mobility are the choice of unit of mobility, the definition
of space and location, and the notion of context
management.
17 Software Engineering for Mobility Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
17.5 Middleware is the most likely vehicle by which novel 8
perspectives on mobility grounded in clean formal
models and effective technical solutions will make their
way into industrial practice.

18 Software Engineering Tools and Environments Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
18.1 The development of methodologies, formalisms, and
tool and environment support for separation, extraction
and integration of concerns

18.2 Linguistic and tool support for morphogenic software:

software that is malleable for life, sufficiently adaptable
to allow context mismatch to be overcome with
acceptable effort, repeatedly, as new, unanticipated
contexts arise.

18.3 The development of new methodologies, formalisms,

and processes to address non-traditional software
lifecycles, and the tool and environment support to
facilitate them.

18.4 The development of new methodologies, formalisms, 17

processes and tool and environment support to address
the engineering of software in new, challenging
domains, such as pervasive computing and e-
commerce.

18.5 The adoption or adaptation of XML, Enterprise Java 21, 8

Beans and sophisticated message brokering for
integration of both tools and commercial applications.
19 Software Configuration Management Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
19.1 Functionality & efficiency. The basic core functions of
SCM systems, like versioning, data management or
workspace support, are still semantically weak, they
lack usability, adaptability and so on.

19.2 PDM vs. SCM. Any serious industrial product now

includes a significant amount of software. We need
tools covering consistently and homogeneously the
development and evolution of products containing
software and other kind of components.

19.3 Process support. Many tools include some process 1

support; SCM in nothing else than one of these. There
is a need to make all these (heterogeneous) process
fragments interoperate with minimum redundancy, to
cover consistently the complete process spectrum of a
company.

19.4 Web support. The Web opens new possibilities for 21

remote access, but the concepts and mechanism for
managing remote concurrent engineering are missing.
On the other hand, managing the evolution of web
pages and other web artifacts raises new challenges.

19.5 Interoperability and architecture. Advanced SCM 20

service have to be componentized, and tailored
solutions will be proposed. The SCM core is likely to be
part of the kernel on which the many company tools
cooperate and interoperate. It will become part of an
architecture and interoperability kernel.

20 Databases in Software Engineering Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

20.1 Separation of concerns between database system and

software engineering applications.

20.2 Application of database technology to provide the

infrastructure for the integration of distributed software
engineering teams.

20.3 Provision of intelligent querying functionality for

heterogeneous information sources supported by
powerful meta-information management.

20.4 Leverage of integral elements of the transaction

concept such as consistency control and recovery to
software engineering (environments).

20.5 Application of database component technology

allowing the deployment of database services in a
requirement-driven manner.
21 Software Engineering and the Internet Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
21.1 The field of software engineering can heavily profit 18
from markup languages, since they provide validation
of structure, display-independent formats and
sophisticated linking capabilities.

21.2 Web integration of all types of project documents, with 18

full support for notations, code and diagrams.

21.3 Creation of tools that take advantage of the semantic

richness of markup languages in order to provide
sophisticated analysis and verifications.

21.4 Exploitation of sophisticated hypertext linking

mechanisms to express complex interconnections
among different documents of the software process.

21.5 Identification of key aspects of documents, process 1

descriptions, and all other types of data objects that are
relevant to the field of software engineering and that
can benefit from standardization.

21.6 Creation of tools that provide useful, non-trivial services

through the comparison and integration of information
deduced from data objects relevant to the field of
software engineering and not created to work together.

22 Software Economics Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

22.1 Principles, models, methods and tools for reasoning 24

about and dynamic management of software
development as an investment activity.

22.2 Models for reasoning about benefits and opportunities 24

in software development as well as costs and risks.

22.3 Principles, models, methods and tools for dealing with 24

uncertainty, incomplete knowledge, and market forces,
including competition and change, in software
development.

22.4 Principles, models, methods, and tools for resolving 24

multi-attribute decision issues in software design and
development.

22.5 Integration of economic considerations into software 6, 7

design and development methods.
23 Empirical Studies of Software Engineering Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
23.1 Empirical study play a fundamental role in modern
science, helping us understand how and why things
work, and allowing us to use this understanding to
materially alter our world.

23.2 Defining and executing studies that change how

software development is done is the greatest challenge
facing empirical researchers.

23.3 The key to meeting this challenge lies in understanding

what empirical studies really are and how they can be
most effectively used - not in new techniques or more
intricate statistics.

23.4 If we want empirical studies to improve software

engineering research and practice, then we need to
create better studies and we need to draw more
credible conclusions from them.

23.5 Concrete steps we can take today include: designing 24

better studies, collecting data more effectively, and
involving others in our empirical enterprises.

24 Software Metrics Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change

24.1 Software metrics should provide information to support 22

quantitative managerial decision-making during the
software lifecycle.

24.2 Good support for decision-making implies support for 22

risk assessment and reduction.

24.3 Traditional metrics approaches, often driven by 22

regression-based models for cost estimation and
defects prediction, provide little support for managers
wishing to use measurement to analyse and minimise
risk.

24.4 The future for software metrics lies in using relatively

simple existing metrics to build management decision-
support tools that combine different aspects of software
development and testing and enable managers to
make many kinds of predictions, assessments and
trade-offs during the software life-cycle.

24.5 Handle the key factors largely missing from the usual 22
metrics approaches (causality, uncertainty, and
combining different, often subjective, evidence) using
causal modelling (for example Bayesian nets), empirical
software engineering, and multi-criteria decision aids.
25 Software Engineering Education Links

Domain specificity
Compositionality

Configurability
NF Properties

Service view

Perspectives

Architecture
Lifecycles
Change
25.1 Identifying distinct roles in software development and
providing appropriate education for each.

25.2 Instilling an engineering attitude in educational

programs.

25.3 Keeping education current in the face of rapid change.

25.4 Establishing credentials that accurately represent ability.