Abstract: Over the last decade, a lot of research has been directed toward integrating performance analysis into the software development process. Traditional software development methods focus on software correctness, introducing performance issues later in the development process. This approach does not take into account the fact that performance problems may require considerable changes in design, for example, at the software architecture level, or even worse at the requirement analysis level. Several approaches were proposed in order to address early software performance analysis. Although some of them have been successfully applied, we are still far from seeing performance analysis integrated into ordinary software development. In this paper, we present a comprehensive review of recent research in the field of model-based performance prediction at software development time in order to assess the maturity of the field and point out promising research directions.

Abstract: The confluence of component based development, model driven development and software product lines forms an approach to application development based on the concept of software factories. This approach promises greater gains in productivity and predictability than those produced by incremental improvements to the current paradigm of object orientation, which have not kept pace with innovation in platform technology. Software factories promise to make application assembly more cost effective through systematic reuse, enabling the formation of supply chains and opening the door to mass customization.

Abstract: Interest in adaptive computing systems has increased dramatically in the past few years, and a variety of techniques now allow software to adapt dynamically to its environment. Compositional adaptation enables software to modify its structure and behavior dynamically in response to change in its execution environment. A review of current technology compares how, when, and where recomposition occurs.

Abstract: Concept location identifies parts of a software system that implement a specific concept that originates from the problem or the solution domain. Concept location is a very common software engineering activity that directly supports software maintenance and evolution tasks such as incremental change and reverse engineering. This work addresses the problem of concept location using an advanced information retrieval method, Latent Semantic Indexing (LSI). LSI is used to map concepts expressed in natural language by the programmer to the relevant parts of the source code. Results of a case study on NCSA Mosaic are presented and compared with previously published results of other static methods for concept location.

Abstract: Software security is the idea of engineering software so that it continues to function correctly under malicious attack. Most technologists acknowledge this undertaking's importance, but they need some help in understanding how to tackle it. The article aims to provide that help by exploring software security best practices. A central and critical aspect of the computer security problem is a software problem. Software defects with security ramifications, including implementation bugs such as buffer overflows and design flaws such as inconsistent error handling, promise to be with us for years. All too often, malicious intruders can hack into systems by exploiting software defects. Internet-enabled software applications present the most common security risk encountered today, with software's ever-expanding complexity and extensibility adding further fuel to the fire. By any measure, security holes in software are common, and the problem is growing.

Abstract: All software projects are guaranteed to have one artifact in common $source code. Together with architectural risk analysis, code review for security ranks very high on the list of software security best practices. We look at how to automate source-code security analysis with static analysis tools.

Abstract: As software systems become increasingly complex, the need to investigate and evaluate them at high levels of abstraction becomes more important. When systems are very complex, evaluating the system from an architectural level is necessary in order to understand the structure and interrelationships among the components of the system. There are several existing approaches available for software architecture evaluation. Some of these techniques, pre-implementation software architectural evaluations, are performed before the system is implemented. Others, implementation-oriented software architectural evaluations, are performed after a version of the system has been implemented. This chapter briefly describes the concepts of software architecture and software architectural evaluations, describes a new process for software architectural evaluation, provides results from two case studies where this process was applied, and presents areas for future work.

Abstract: Software Product Line Development advocates software reuse by modeling common and variable artefacts separately across members of a family of products. Aspect-Oriented Software Development aims at separation of concerns with “aspects†​ to increase modularity, reusability, maintainability and ease of evolution. In this paper, we apply an as-pect-oriented use case modeling approach to product line system modeling. A use case specification captures stake-holders concerns as interactions between a system and its actors. We adapt our previous work with the introduction of a “variability†​ r 40 Open Source, Free and Top Unified Modeling Language (UML) Tools : Review of Top Open Source and Free Unified Modeling Language (UML) Tools including ArgoUML, StarUML, UMLet, Dia, BOUML, Violet, EclipseUML, gModeler, RISE, NClass, NetBeans IDE, GenMyModel, Plantuml, UML Modeller, Open ModelSphere, Oracle Jdeveloper, Papyrus, Oracle SQL Developer are the Top Open Source and Free Unified Modeling Language (UML) Tools.Top Unified Modeling Language (UML) Tools : Review of Top Unified Modeling Language (UML) Tools including IBM Rational Rose, Visio, StarUML, Visual Paradigm, Sparx Enterprise Arch Explore a Service-Oriented Software product lines (SoSPL) methodology that applies SPL variability analysis techniques to Web services to design customized service-based applications. Find out how software product lines (SPL) promote agile and flexible application development for evolving system families. And discover how the adoption of SPL principles can provide a systematic way to analyze and design service-oriented applications. You can model business processes using Unified Modeling Language (UML) activity diagrams. Activity diagrams are particularly useful in detailing the workflow of business processes during domain business modeling. Figure 1 shows a hotel reservation process.

Abstract: This paper discusses the trustworthy computing security development lifecycle (or simply the SDL), a process that Microsoft has adopted for the development of software that needs to withstand malicious attack. The process encompasses the addition of a series of security-focused activities and deliverables to each of the phases of Microsoft's software development process. These activities and deliverables include the development of threat models during software design, the use of static analysis code-scanning tools during implementation, and the conduct of code reviews and security testing during a focused "security push". Before software subject to the SDL can be released, it must undergo a final security review by a team independent from its development group. When compared to software that has not been subject to the SDL, software that has undergone the SDL has experienced a significantly reduced rate of external discovery of security vulnerabilities. This paper describes the SDL and discusses experience with its implementation across a range of Microsoft software.

Abstract: Software systems contain entities, such as functions and variables, which are related to each other. As a software system evolves to accommodate new features and repair bugs, changes occur to these entities. Developers must ensure that related entities are updated to be consistent with these changes. This paper addresses the question: How does a change in one source code entity propagate to other entities? We propose several heuristics to predict change propagation. We present a framework to measure the performance of our proposed heuristics. We validate our results empirically using data obtained by analyzing the development history for five large open source software systems.

Abstract: End-user programming has become the most common form of programming in use today [2], but there has been little investigation into the dependability of the programs end users create. This is problematic because the dependability of these programs can be very important; in some cases, errors in end-user programs, such as formula errors in spreadsheets, have cost millions of dollars. (For example, see www.theregister.co.uk/content/67/31298.html or panko.cba.hawaii.edu/ssr/Mypapers/whatknow.htm.) We have been investigating ways to address this problem by developing a software engineering paradigm viable for end-user programming, an approach we call end-user software engineering.

Abstract: Test Driven Development (TDD) is a software development practice in which unit test cases are incrementally written prior to code implementation. We ran a set of structured experiments with 24 professional pair programmers. One group developed a small Java program using TDD while the other (control group), used a waterfall-like approach. Experimental results, subject to external validity concerns, tend to indicate that TDD programmers produce higher quality code because they passed 18% more functional black-box test cases. However, the TDD programmers took 16% more time. Statistical analysis of the results showed that a moderate statistical correlation existed between time spent and the resulting quality. Lastly, the programmers in the control group often did not write the required automated test cases after completing their code. Hence it could be perceived that waterfall-like approaches do not encourage adequate testing. This intuitive observation supports the perception that TDD has the potential for increasing the level of unit testing in the software industry.

Abstract: Methods and systems for network-based or Internet-based software delivery are described. In one embodiment, an application program or software platform resides on a client and is configured so that it is extensible based on software extensions that are deliverable over a network such as the Internet. Various extensions can be developed by third party developers for incorporation into the program or platform.

Abstract: System family engineering seeks to exploit the commonalities among systems from a given problem domain while managing the variabilities among them in a systematic way. In system family engineering, new system variants can be rapidly created based on a set of reusable assets (such as a common architecture, components, models, etc.). Generative software development aims at modeling and implementing system families in such a way that a given system can be automatically generated from a specification written in one or more textual or graphical domain-specific languages. This paper gives an overview of the basic concepts and ideas of generative software development including DSLs, domain and application engineering, generative domain models, networks of domains, and technology projections. The paper also discusses the relationship of generative software development to other emerging areas such as Model Driven Development and Aspect-Oriented Software Development.

Abstract: Refactorings are widely recognised as ways to improve the internal structure of object-oriented software while maintaining its external behaviour. Unfortunately, refactorings concentrate on the treatment of symptoms (the so called code-smells), thus improvements depend a lot on the skills of the maintained coupling and cohesion on the other hand are quality attributes which are generally recognized as being among the most likely quantifiable indicators for software maintainability. Therefore, this paper analyzes how refactorings manipulate coupling/cohesion characteristics, and how to identify refactoring opportunities that improve these characteristics. As such we provide practical guidelines for the optimal usage of refactoring in a software maintenance process.

Abstract: For software quality estimation, software development practitioners typically construct quality-classification or fault prediction models using software metrics and fault data from a previous system release or a similar software project. Engineers then use these models to predict the fault proneness of software modules in development. Software quality estimation using supervised-learning approaches is difficult without software fault measurement data from similar projects or earlier system releases. Cluster analysis with expert input is a viable unsupervised-learning solution for predicting software modules' fault proneness and potential noisy modules. Data analysts and software engineering experts can collaborate more closely to construct and collect more informative software metrics.

Abstract: Product line engineering has become an important and widely used approach for efficiently developing portfolios of software products. The idea is to develop a set of products as a single, coherent development task from a core asset base (sometimes called a platform), a collection of artifacts specifically designed for use across a portfolio. This approach produces order-of-magnitude economic improvements compared to one-at-a-time software system development. Because the product line approach isn't limited to specific technical properties of the planned software but rather focuses on economic characteristics, high return on investment has become the anthem of the approach's protagonists. Our software product line cost model can calculate the costs and benefits (and hence the ROI) that we can expect to accrue from various product line development situations. It's also straightforward and intuitive.

Abstract: Knowing where to start reverse engineering a large software system, when no information other than the system's source code itself is available, is a daunting task. Having the history of the code (i.e., the versions) could be of help if this would not imply analyzing a huge amount of data. We present an approach for identifying candidate classes for reverse engineering and reengineering efforts. Our solution is based on summarizing the changes in the evolution of object-oriented software systems by defining history measurements. Our approach, named Yesterday's Weather, is an analysis based on the retrospective empirical observation that classes which changed the most in the recent past also suffer important changes in the near future. We apply this approach on two case studies and show how we can obtain an overview of the evolution of a system and pinpoint its classes that might change in the next versions.

Abstract: Current software quality estimation models often involve using supervised learning methods to train a software quality classifier or a software fault prediction model. In such models, the dependent variable is a software quality measurement indicating the quality of a software module by either a risk-based class membership (e.g., whether it is fault-prone or not fault-prone) or the number of faults. In reality, such a measurement may be inaccurate, or even unavailable. In such situations, this paper advocates the use of unsupervised learning (i.e., clustering) techniques to build a software quality estimation system, with the help of a software engineering human expert. The system first clusters hundreds of software modules into a small number of coherent groups and presents the representative of each group to a software quality expert, who labels each cluster as either fault-prone or not fault-prone based on his domain knowledge as well as some data statistics (without any knowledge of the dependent variable, i.e., the software quality measurement). Our preliminary empirical results show promising potentials of this methodology in both predicting software quality and detecting potential noise in a software measurement and quality dataset.

Abstract: An execution environment accommodating object-based software transparently monitors interactions with software objects to generate operational management information for managing programs executing at plural computers. Notifications are directed to a software manager in the form of events, which can additionally be provided to applications or user programs. The software manager can group the events into sets and derive various operational management metrics from them to provide an overall picture of a program's performance, including availability. A hierarchical arrangement feature facilitates gathering information for programs scattered over plural computers. An alert feature provides warnings if metrics fall outside a specified threshold. In addition, the alert feature can automatically subscribe to additional sets of events to dynamically select the information collected by the software manager. Since the operational management information is collected transparently by logic outside the objects, manual instrumentation of the program is unnecessary, and software management technology is made available to organizations without software management expertise.

Abstract: design transforms the semi-formal requirements specification into a formal specification that represents the architecture of the entire system and functional definitions of its components. There is a substantial difference between the requirements specification and the design specification: the former focuses on the description of the user's requirements, while the latter focuses on the architecture of the system to provide a solution to the problem. Therefore, such a transformation is not only a formalization, but also involves the creation of a system structure that fulfils the requirements. In general, the system architecture is different from the structure of the requirements specification, but this does not mean that the semi-formal requirements specification cannot be reused in the design. In fact, it is often the case that during the construction of the system architecture, some of the modules, types, processes, and functions in the semi-formal specification may be employed without any change to their interfaces and functionality, but some others may need to be modified, extended, or combined with others. In addition to formalizing the existing semi-formal specification, new specification components are usually created and integrated into the system to support the functionality of the entire system. Formalization of abstract design can benefit the system development in several ways. Firstly, the designer is given a chance to study the requirements rigorously and to clarify the ambiguity in the semi-formal specification. This would force the designer to communicate with the analyst who wrote the semi-formal specification. In the era of globalization in business and communication, distributed software projects carried out through the Internet are 244 14 The Software Development Process increasing. Requirements analysis may be conducted in one place, while the design may be carried out in another remote location. In this situation, formalization of abstract design based on the semi-formal requirements specification definitely helps the designer to study, clarify, and understand the requirements thoroughly. Secondly, the activity of formalization can also stimulate discussions among the developing team members, and therefore it would help to improve their understanding of their tasks. Finally, the design specification serves as a firm foundation for the detailed design, coding, and testing; therefore, it can facilitate the transformation from the abstract design to the detailed design and, further, to the program. Apart from the criteria imposed to the semi-formal specification, a formal specification is required to satisfy the following additional criteria: • All the modules are integrated into a hierarchy of CDFDs. • All the given types are defined precisely. In other words, no given types are allowed in the formal specification, because their values are not defined precisely. • The pre and postconditions of every process and function in modules are written in the SOFL language, not in any informal language. Note that these criteria do not forbid the use of explicit specifications for processes, but implicit specifications are encouraged because the focus of this phase is on the architecture of the entire system and the functionality of its components; the issue of how the components are expressed in an algorithmic manner should be left to the detailed design. In principle, in the stage of abstract design, we do not encourage defining classes and then using their objects in process and function specifications. The reason is that, in the use of objects, invoking their methods may cause undesirable changes of the same object, and therefore cause confusion in pre and postcondition semantics. If methods of an object must be invoked in a process specification in order to define its behavior, an explicit specification must be adopted to define the process. In order to avoid undesired side effects, no object is allowed to be used as a parameter of a function in its specification. Let us consider the simplified hotel reservation system as an example to see how to transform a semi-formal specification into a formal specification. On the basis of our understanding of the semi-formal specification, a top-down approach is taken to design the formal specification. The top level CDFD in the specification aims at dealing with various requests, such as reservation, cancellation, and change of reservation, but takes one at each time. Then, the request is passed to a specific program component to process. Figure 14.4 illustrates the top level CDFD of this system, and the associated module is given as follows: module SYSTEM_Hotel_Reservation;

Abstract: We present a traceability recovery method and tool based on latent semantic indexing (LSI) in the context of an artefact management system. The tool highlights the candidate links not identified yet by the software engineer and the links identified but missed by the tool, probably due to inconsistencies in the usage of domain terms in the traced software artefacts. We also present a case study of using the traceability recovery tool on software artefacts belonging to different categories of documents, including requirement, design, and testing documents, as well as code components.

Abstract: Methods and arrangements to propagate application software to a virtual deployment target are contemplated. More specifically, a user may create multiple virtual deployment targets in a software system such as WebSphere™ and deploy applications to multiple the virtual deployment targets without having to manually fit policy-driven applications into each virtual deployment target. Embodiments are particularly advantageous when the application software is a business solution that needs to be deployed multiple times such as during the development and testing of the business solution. For example, application software of a business solution typically includes a group of applications designed to cooperatively function as a single entity. An application bundle such as an Enterprise Application Solution (EAS) file describes the application software and includes pertinent information about the application software, application configuration data, and runtime configuration data to implement the business solution. Then, the application bundle can be deployed automatically or substantially automatically.

Abstract: This paper proposes a four-dimensional evaluation framework for software product family engineering. The four dimensions relate to the software engineering concerns of business, architecture, organisation, and process. The evaluation framework is intended for use within software developing organisations to determine the status of their own software product family engineering and the priorities for improving. The results of the evaluation can be used for benchmarking, roadmapping, and developing improvement plans. An initial evaluation of a real industrial case is presented to show the validity of the framework.

Abstract: The principle of information hiding has been very influential in software engineering since its inception in 1972. This principle prescribes that software modules hide implementation details from other modules in order to decrease their interdependencies. This separation also decreases the dependency among software developers implementing modules, thus simplifying some aspects of collaboration. A common instantiation of this principle is in the form of application programming interfaces (APIs). We performed a qualitative study on how practitioners use APIs in their daily work. Although particularly interested in aspects of collaboration, we report all findings about their observed use. The findings include mundane observations that are predicted by theory, ways that APIs support collaborative software development. But the findings also include some surprises, ways that APIs hinder collaboration. The surprises indicate directions for further improvement of collaborative software development practices and tools.