I E E E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y I E E E S O F T W A R E 7 1evolution. While they address some aspects of the problem, however, understanding the software still poses some difficulty. This shift toward service orientation compels us to consider its implications for software understanding, which is potentially the primary cost in software engineering. 2 Using an example of on-the-fly software services construction, we discuss the problems software engineers still face when working with service-oriented software. We also introduce some new issues that they must consider, including how to address service provision difficulties and failures. The service-oriented visionSoftware evolution still poses a significant problem for many organizations despite new development methods that promise to enable flexibility and simplify systems' evolution as business needs change. Among the largest costs is the time software engineers spend trying to understand existing software, either to fix bugs or add functionality. We use the term software understanding to mean the application of techniques and processes that facilitate understanding of the software. We need this understanding to ensure the software evolves through the application of various maintenance activities.The SaaS framework, advanced as a solution to the evolution issue, 3 automatically discovers fine-grained software services, negotiates to acquire them, and composes, binds, executes, and unbinds them. This process potentially occurs for every execution of the software, and would Understanding ServiceOriented Software M any hail service-oriented software as the next revolution in software development. Web services' capabilities are constantly expanding from simple message passing toward the construction of full-fledged applications such as those envisaged by the UK's Pennine Group in their Software as a Service (SaaS) framework. 1 These new, service-oriented approaches appear to many to solve the significant issue of software inflexibility that arises during maintenance and service-oriented software Nicolas Gold and Andrew Mohan, UMIST Claire Knight, Volantis Systems Malcolm Munro, University of DurhamService-oriented software lets organizations create new software applications dynamically to meet rapidly changing business needs. As its construction becomes automated, however, software understanding will become more difficult.
The accurate estimation of the resources required to implement a change in software is a difficult task. A method for doing this should include the analysis of the impact of the change on the existing system. A number of techniques for analysing the impact of a change on the source code have been described in the literature. While these techniques provide a good example of how to apply ripple effect analysis to source code, a weakness in these approaches is that they can be difficult to apply in the risk assessment phase of a project. This is because the source code is often not very well understood at this phase, and change proposals are written at a much higher level of abstraction than the code. It is therefore often the case that in practice subjective impact analysis methods are used for risk assessment and project investment appraisal. The underestimated resources for dealing with the ripple effects of a change can result in project schedules becoming so tight that only the minimal quality is achieved. This paper surveys existing ripple analysis techniques and then presents a new technique for the early detection of ripple effects based on a simple graph‐theoretic model of documentation and the themes within the documentation. The objective is to investigate the basis of a technique for analysing and measuring the impact of a change on the entire system that includes not only the source code but the specification and design documentation of a system, and an early phase in the maintenance process.
Use policyThe full-text may be used and/or reproduced, and given to third parties in any format or medium, without prior permission or charge, for personal research or study, educational, or not-for-prot purposes provided that:• a full bibliographic reference is made to the original source • a link is made to the metadata record in DRO • the full-text is not changed in any way The full-text must not be sold in any format or medium without the formal permission of the copyright holders.Please consult the full DRO policy for further details. Abstract-In order to characterize and improve software architecture visualization practice, the paper derives and constructs a qualitative framework, with seven key areas and 31 features, for the assessment of software architecture visualization tools. The framework is derived by the application of the Goal Question Metric paradigm to information obtained from a literature survey and addresses a number of stakeholder issues. The evaluation is performed from multiple stakeholder perspectives and in various architectural contexts. Stakeholders can apply the framework to determine if a particular software architecture visualization tool is appropriate to a given task. The framework is applied in the evaluation of a collection of six software architecture visualization tools. The framework may also be used as a design template for a comprehensive software architecture visualization tool.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.