Managing Complexity in Software Engineering
Software engineering products are becoming ever more complex, because software is being used in the solution of more technically difficult problems and because the size of software projects continues to grow. A key question for software engineers is how to cope with this complexity. There is no single answer, and software engineers must attack the problem from a number of perspectives. A technical perspective reveals new paradigms for system development, including two paradigms that show particular promise: object-oriented design and formal methods. A management perspective recognises that good project management is vital to the success of a complex project. The scale of modern projects makes it essential to use automated support, so software engineers must also look at how to manage complexity from an automation perspective. Automated support can come in the form of discrete tools for particular tasks, or a packaged set of tools in a support environment. The papers in this book address the problem of managing complexity in software engineering from these different perspectives. The papers are grouped into three sections: Paradigms of software development; Project management; and Automated support. The papers are selected from those presented at the 4th European Seminar on Industrial Software Technology organised by the European Workshop on Industrial Computer Systems (EWICS), whose aim is to promote the effective use of industrial computer systems through education, the dissemination of information and the development of guidelines and standards.
Inspec keywords: project management; software engineering
Other keywords: project management; automated development support; complexity management; software engineering; development paradigms
Subjects: Software management; Software engineering techniques
- Book DOI: 10.1049/PBCM017E
- Chapter DOI: 10.1049/PBCM017E
- ISBN: 9780863411717
- e-ISBN: 9781849193566
- Page count: 280
- Format: PDF
-
Front Matter
- + Show details - Hide details
-
p.
(1)
-
Development paradigms
1 Paradigms of modular system development
- + Show details - Hide details
-
p.
1
–20
(20)
In this chapter, we characterize the deficiencies of current software development paradigms and propose a new object-oriented development paradigm which eliminates such deficiencies. The deficiencies of current software development paradigms lead in general to program structures which often badly reflect the design decisions during the development. In addition software development process models apply a Procrustes bed to the sequence and nature of development steps. From this analysis we develop a new paradigm of software development which tries to overcome these deficiences. Based on the principles of Divide and Conquer and Separation of Concerns we derive two abstraction concepts. The concept of information hiding abstraction provides a structure for software systems. The concept of information neglection abstraction helps to structure the description of specifications. Based on these structuring concepts a specification language is outlined allowing to express many software properties ranging from high-level design to (nearly) implementation including concurrency and distribution aspects. Since the whole range of software design has a common basis development process models are possible which give the necessary freedom to the developer.Thus it helps considerably to manage the complexity of the software development process.
2 The evolution of object-oriented design from concept to method
- + Show details - Hide details
-
p.
21
–50
(30)
This chapter describes the preliminary work performed at Logica, which has the overall aim of producing an object-oriented approach to software system development. The paper reports on the approach to make the transition from requirements into an object-oriented software architecture.
3 The role of formal methods in managing complexity
- + Show details - Hide details
-
p.
51
–86
(36)
This chapter examines the role of formal methods within the software development process. In particular the case is made that the formal development paradigm, emphasising as it does abstraction, stepwise reification and the processes of justification fits in well with the traditional contractual model of software development. In so doing the activity of producing abstract specifications relates to the requirements analysis and specification phases, so necessary in large scale software production. The activity of reification equates with the tasks of producing system, sub-system or object level specifications. The justification process provides a basis for effectively structuring reviews and for arguing “why” a design is correct.
4 Putting mathematics to use
- + Show details - Hide details
-
p.
87
–96
(10)
This chapter puts forward the view that theories are central to any engineering discipline that wishes to be scientific. Further, any formalisation of these theories will provide useful analytical power and insights, together with the provision of a precise shared language for communication between engineers. It should be noted, however, that the use of theories need not always be self-conscious. Highly experienced engineers may well continue to apply the results of analysis, and exploit the insights, founded on theories long forgotten. This is a good thing, in the sense that it increases productivity, but it may also lead to failures where technology changes without subsequent re-examination of the underlying theories, and also lost opportunities in applying new theories leading to improved solutions. Finding a safe and sensible middle-ground is another aspect of the professional judgement of the engineer. There are a number of barriers to the widespread adoption of this theoretically based software engineering.
5 The theory of organisation: a mathematical treatment of processing structures
- + Show details - Hide details
-
p.
97
–112
(16)
In this chapter, a mathematical treatment of processing structures is presented. It is based on a concise and powerful algebraic system utilizing just fourconnectives. The language accompanying the algebraic system can be considered as truly universal, because it allows us the representation of any processing structure by a single expression, no matter whether it is sequential, concurrent or distributive. The language is unique insofar as conventional computer languages need to make use of nonalgebraical constructs. The theory offers an excellent base for a powerful programming methodology, a methodology where software becomes a matter of calculation and conversion thereby making soft ware production a truly engineering business. In particular, this methodology should lend itself very well to system evolution.
-
Project management
6 The need for a quality culture for software development
- + Show details - Hide details
-
p.
113
–126
(14)
This chapter discusses the need for a quality culture for software development. Why quality is important in information technology, and software in particular. Improvements in quality can be achieved by introducing an effective quality system. There is now an international standard for quality systems, and it is possible to have independent assessment and registration of conformance to the standard.
7 Quality metrics for software management and engineering
- + Show details - Hide details
-
p.
127
–152
(26)
In the last 10-15 years, a multitude of software quality metrics has been developed. The most well-known of these metrics are Halstead's Software Science measures, McCabe's cyclomatic number, Gilb's logical complexity metrics, Henry and Kafura's information flow metrics, and Yau and Collofello's stability measures. In particular, metrics appropriate for quantifying characteristics of software maintainability drew widespread attention from both managers and engineers, since the rising cost of maintaining software systems is still an important concern for software developers and customers: The resources invested in software maintenance have been estimated to consume two thirds of the life cycle costs of software. Quality metrics are considered an effective aid to help manage the software development and maintenance process. Their periodic application is viewed as a control system providing continuous feedback and allowing corrective actions during the whole development process. This paper surveys the state of the art in measuring and predicting the quality of software by means of metrics. Emphasis is placed on metrics which are suited to quantify maintainability characteristics in the different stages of software development. Results of empirical validation studies are reported to show the analytical and predictive power of these metrics. From the survey it is concluded how far current metrics can be used for software management and engineering.
8 Measuring to manage
- + Show details - Hide details
-
p.
153
–166
(14)
This chapter discusses software metrics, that is to say measures (in terms of amounts or counts) related to software products and the process of software production and support. In this context, the 'software products' from which software metrics may be derived should be taken to include all the intermediate products, such as design documents, specifications, code listings, test reports, etc., which are produced during software development and maintenance, not just the final software product.
9 Structuring routine interactions in software engineering
- + Show details - Hide details
-
p.
167
–180
(14)
This chapter discusses structuring routine interactions in software engineering. The purpose of this chapter is to clarify the nature of team communication in software engineering. We limit our discussion to simple routine interactions in a team.
-
Automated development support
10 Methods and tools
- + Show details - Hide details
-
p.
181
–200
(20)
Software engineering methods are formalisms for describing software. The capabilities of tools are determined by the methods they implement. Software engineering tools usually support at least syntax-oriented editing and consistency checks. Transformation tools translate descriptions of one method into the formalism of others. Interpreters and simulators run specifications for evaluating the behaviour of a system. Integrated programming support environments integrate tools to cover the various tasks of software development. Heterogeneous environments are based on various methods. They allow the user choice of method but hardly permit incremental software development. Highly integrated environments are based on a key design method to which subordinate methods are added in order to detail specifications. They are bound to their methods but do not require rigid procedures for software development.
11 Development support environments
- + Show details - Hide details
-
p.
201
–216
(16)
This chapter examines the motives behind activities in software and systems engineering environments and comments upon the likely effectiveness of the strategies followed by current researchers and developers.
12 Structuring for managing complexity
- + Show details - Hide details
-
p.
217
–224
(8)
This chapter discusses structuring for managing complexity. In a software development project, complexity may be intrinsic to the problem to solve, but is also generated by the development process itself: the project organization, the tools supporting the development and their cooperation, the data manipulated by the developers, the number of elementary tasks the developers have to carry out, all participate in the global complexity of a project.
13 A method-driven support environment
- + Show details - Hide details
-
p.
225
–238
(14)
The general objectives of the ToolUse project are to provide active assistance in the various activities of software development through the formalization, and the support, of development methods. This formalization is done through a language, DEVA, used to express the design decisions related to methods as well as a specification language. The project is subdivided into four main tasks: two are devoted to the definition and support of the DEVA language, two others aim at extracting development knowledge from known development methods and then at experimenting with these knowledge parts through realistic case studies. This paper focuses on the linguistic framework used to formalize methods and presents some examples of methods to illustrate the DEVA use. The tools of the support environment are briefly sketched. The work related to application domain knowledge extraction and experimentation is presented through its contribution to test the adequacy of DEVA.
14 Automated support for marrying requirements to programs
- + Show details - Hide details
-
p.
239
–246
(8)
Although the standard contractual model is often used to describe the relationship between a customer and software supplier, it is unfortunately the case that the contract can be fulfilled without doing what the user really wanted. Building the right system and, even before that, understanding what the right system should do is often a formidable task for both sides of the contract. Nor can the proper marriage of requirements to programs be satisfied by post hoc changes to the requirements or documenting problems as if they were features. What is needed is to make sure that the customer is fully aware of requirements and, possibly more importantly, the consequences of those requirements. This paper discusses some of the general points in this area, illustrated by reference to one particular project the UK ALVEY "FOREST" Software Engineering project concerning formal requirements specification.
15 Configuration support for system description, construction and evolution
- + Show details - Hide details
-
p.
247
–260
(14)
Software systems can be conveniently described, constructed and managed in terms of their configuration, where configuration is the system structure defined as the set of constituent software components together with their interconnections. A specification of the system configuration can be used both to describe the required system structure and to generate the actual system itself. The performance of these tasks at the configuration level is termed configuration programming, and is best supported by the use of a declarative configuration language and associated support tools. This paper discusses the main principles of this approach and illustrates its practice by describing the support which has been provided in the Conic environment for distributed systems. These concepts are illustrated by using a simple example: a patient monitoring system (PMS).
-
Back Matter
- + Show details - Hide details
-
p.
261
(1)