Internet of things (IoT) while providing virtually unlimited opportunities, is also prone to many "risks". Risk analysis is therefore a mandatory action for any IoT system to ensure security, privacy, performance and reliability. Moreover, the complexity and structural dynamism of these mobile cloud/IoT systems further adds to the need for specialized, systematic and automated risk analysis and mitigation as well as the context awareness of risk management. This paper represents a part of our ongoing work towards creating a quantitative context-aware risk management system, suitable for dynamic mobile cloud and IoT environments, which would use the current context parameters to predict/identify potential risks and where possible, manage risks autonomously.

There is a growing interest in software summarization and tools for automatically producing summaries. Discussions of relevant papers at recent conferences led to the observation that software summarization needs to consider migrating away from ``is this a good summary?" and towards ``is this a useful summary?" As a result, it has been suggested that to judge usefulness, one needs to view the summary through the lens of a particular task. A preliminary investigation of this suggestion was undertaken at the 2013 ICSE workshop NaturaLiSE. Initial results and lessons learned from this investigation support the notion that task plays a significant role and thus should be considered by researchers building and accessing automatic software summarization tools.

In today's environment, software companies are engaged in multiple projects delivered on heterogeneous platforms for a wide class of applications in disparate application domains. They are increasingly engaged in the co-development of software systems through joint software development projects including staff from partners and customers as well as their own. As a result, they must support multiple software development processes while trying to guarantee uniform levels of process enactment, and product quality across all projects. Our approach is capable of providing process measurement in a joint-project, multi-process model business environment. It is based on a simple meta-model for computing across-process, multiple-project metrics designed to permit monitoring of CMMI compliance. The open source tool Spago4Q has been developed to support our approach and is capable of producing the measurements needed for monitoring of a set of large-scale development projects using different process models, in a real industrial setting in Europe. The results support the view that that it will not always be possible to aggregate the same set of metrics across disparate process models.

Ideally, all black-box testing methods should be interpreted in the same way by different testers. In reality however, inconsistencies and ambiguities in original method descriptions may lead to differing interpretations and varying test set quality. In this paper, we decompose these methods into atomic rules for selecting test data and constructing test cases. We validate the rules via a worked example and discuss a pilot experiment to determine whether atomic rules are simpler to learn and use. Our approach also enables method tailoring and may simplify method comparison.

For research into multimedia development practices to progress, the actual processes and activities performed need to be recorded and compared. For accurate comparison, some agreed means of describing the material is needed. In other fields such as botany and zoology, taxonomies are constructed to facilitate such recording and comparison. We draw on the published literature on multimedia to obtain appropriate terms, and then constructs a taxonomy using traditional techniques, in particular, faceting. We compare our results with existing taxonomies and argue that the latter's focus on aesthetics is not suitable for research into process and estimating issues. Finally, we discuss the use of the taxonomy as a basis for comparing multimedia projects, and as a basis for identifying the critical factors in multimedia project development. This will be used to support the development of improved process and estimating models.

The definition and understanding of software architectures and architecture views still shows considerable disagreement in the software engineering community. The paper argues that the problems we face exist because our understanding is based on specious analogies with traditionally engineered artefacts. A review of the history of ideas shows the evolution of this understanding. A detailed examination is then presented of the differences that exist between the nature of the systems, the content of their large-scale representations, and how they are used in practice in the respective disciplines. These differences seriously undermine the analogies used to develop our understanding and this is discussed in terms of software engineering as a whole.

In recent years, software engineering researchers have elevated the study of software architecture to the level of a major area of study. A review of the published literature however, shows quite clearly that a unified view of software architecture has not been forth-coming. This paper contends that the existence of a "software architecture level of design" is based on the implicit assumption that the software development process is analogous to those "construction" disciplines in which the completed artefacts or systems exhibit a unique representational abstraction, fixed during the early stages of design, which we describe as "the architecture". We argue that our problems in obtaining an acceptable definition of software architecture are due to the assumption that software systems have an analogous, unique design abstraction determinable at the early stages of the design. To determine the validity of this analogy, we contrast the nature and use of architecture in the traditional building process with software development to identify the differences, rather than the similarities that exist. These differences are explained using a theory of the software development process which highlights why these differences arise and, subsequently why there has been trouble in developing a community-wide understanding of software architecture. Our conclusion is that due to the fundamental nature of the systems we construct, attempts to depict the large-scale structure of the system, in an analogous manner traditional building disciplines, results in many different architectures. These are fundamentally different representations and not merely different views of a single whole. Moreover, each of these is equally qualified to be labelled as the system architecture with respect to the general notion of what architecture is.

This paper describes RARE (Reuse-Assisted Requirements Elicitation), a method enabling software requirements engineers to process informal software requirements effectively. RARE's object is to assist analysts in transforming requirements expressed in natural language into a comprehensive collection of rigorous specifications that can be used as a starting point in software development. However, unlike other approaches to managing requirements documents, RARE focuses on the application of reuse-intensive methods of dealing with requirements documents, their contents and structure, and the processes involved in the analysis and refinement of requirements texts. The RARE method circumscribes an iterative process of planning, gathering and elaboration analysis, refinement, adaptation, integration and validation of requirements texts. The paper also describes the operation of IDIOM (Informal Document Interpreter, Organiser and Manager), a requirements management tool that supports the RARE method.

The paper shows that memory mapping tables can be used to implement the display registers used in providing architectural support for block-structured languages such as Algol 60. This allows full lexical level addressing to be implemented on so-called von-Neuman machines.The problems of fragmentation of the paged address space are explored, and machines with memory mapping schemes capable of supporting the proposals identified.Attention is drawn to the similarity between segmented and paged schemes, and it is suggested that the latter may be used to support the former.