Mapping Agile Practices to CMMI-DEV Level 3 in Web Development Environments

Agile approaches formally appeared ten years ago and nowadays they are a valid alternative for organizations developing software. Agile methodologies are especially interesting to those developing Web environments applications, as they can fit properly the special characteristics of this type of developments. In addition, maturity models like CMMI-DEV (Capability Maturity Model Integration for Development) focus on assessing the maturity level of organizations developing or acquiring software. These models are well established and can increment quality of development process to enhance costumers’ satisfaction. CMMI-DEV level 3 provides a good compromise on maturity gained and effort needed. The feasibility of reaching it through a combination of Agile methods can be very useful to organizations developing systems in Web environments, as they can keep the adaptability of Agile together with a more mature development process. This paper proposes a set of Agile methods so as to reach all CMMI-DEV maturity level 3 generic and specific goals. Based on this analysis, the paper proposes further research lines

Design of Transformation Initiatives Implementing Organisational Agility -- An Empirical Study

This study uses 125 responses from companies of all sizes headquartered in Germany, Switzerland, France and UK to reveal perceptions of the drivers of organisational agility. It further investigates current understanding of managing principles of multiple organisational dimensions such as culture, values, leadership, organisational structure, processes and others to achieve greater organisational agility. The data set is disaggregated into four major profiles of agile organisations: laggards, execution specialists, experimenters, and leaders. The approach to agile transformation is analysed by each of those profiles. While the positive effect from a more holistic approach is confirmed, leaders tend to focus more on processes and products rather than project work. Respondents perceive that IT, product development and research are most agile functions within their organisations, while human resources, finance and administration are considered being not agile. Further, organisations with higher levels of organisational agility tend use more than one agile scaling framework. Implications on theories of agile transformations and organisational design are discussed

Software architecture visualisation

Tracing the history of software engineering reveals a series of abstractions. In early days, software engineers would construct software using machine code. As time progressed, software engineers and computer scientists developed higher levels of abstraction in order to provide tools to assist in building larger software systems. This has resulted in high-level languages, modelling languages, design patterns, and software architecture. Software architecture has been recognised as an important tool for designing and building software. Some research takes the view that the success or failure of a software development project depends heavily on the quality of the software architecture. For any software system, there are a number of individuals who have some interest in the architecture. These stakeholders have differing requirements of the software architecture depending on the role that they take. Stakeholders include the architects, designers, developers and also the sales, services and support teams and even the customer for the software. Communication and understanding of the architecture is essential in ensuring that each stakeholder can play their role during the design, development and deployment of that software system. Software visualisation has traditionally been focused on aiding the understanding of software systems by those who perform development and maintenance tasks on that software. In supporting developers and maintainers, software visualisation has been largely concerned with representing static and dynamic aspects of software at the code level. Typically, a software visualisation will represent control flow, classes, objects, import relations and other such low level abstractions of the software. This research identifies the fundamental issues concerning software architecture visualisation. It does this by identifying the practical use of software architecture in the real world, and considers the application of software visualisation techniques to the visualisation of software architecture. The aim of this research is to explore the ways in which software architecture visualisation can assist in the tasks undertaken by the differing stakeholders in a software system and its architecture. A prototype tool, named ArchVis, has been developed to enable the exploration of some of the fundamental issues in software architecture visualisation. ArchVis is a new approach to software architecture visualisation that is capable of utilising multiple sources and representations of architecture in order to generate multiple views of software architecture. The mechanism by which views are generated means that they can be more relevant to a wider collection of stakeholders in that architecture. During evaluation ArchVis demonstrates the capability of utilising a number of data sources in order to produce architecture visualisations. Arch Vis' view model is capable of generating the necessary views for architecture stakeholders and those stakeholders can navigate through the views and data in order to obtain relevant information. The results of evaluating ArchVis using a framework and scenarios demonstrate that the majority of the objectives of this research have been achieved

Report from GI-Dagstuhl Seminar 16394: Software Performance Engineering in the DevOps World

This report documents the program and the outcomes of GI-Dagstuhl Seminar 16394 "Software Performance Engineering in the DevOps World". The seminar addressed the problem of performance-aware DevOps. Both, DevOps and performance engineering have been growing trends over the past one to two years, in no small part due to the rise in importance of identifying performance anomalies in the operations (Ops) of cloud and big data systems and feeding these back to the development (Dev). However, so far, the research community has treated software engineering, performance engineering, and cloud computing mostly as individual research areas. We aimed to identify cross-community collaboration, and to set the path for long-lasting collaborations towards performance-aware DevOps. The main goal of the seminar was to bring together young researchers (PhD students in a later stage of their PhD, as well as PostDocs or Junior Professors) in the areas of (i) software engineering, (ii) performance engineering, and (iii) cloud computing and big data to present their current research projects, to exchange experience and expertise, to discuss research challenges, and to develop ideas for future collaborations

Migrating Integration from SOAP to REST : Can the Advantages of Migration Justify the Project?

This thesis investigates the functional and conceptual differences between SOAP-based and RESTful web services and their implications in the context of a real-world migration project. The primary research questions addressed are: • What are the key functional and conceptual differences between SOAP-based and RESTful web services? • How can SOAP-based and RESTful service clients be implemented into a general client? • Can developing a client to work with REST and SOAP be justified based on differences in performance and maintainability? The thesis begins with a literature review of the core principles and features of SOAP and REST, highlighting their strengths, weaknesses, and suitability for different use cases. A detailed comparison table is provided to summarize the key differences between the two web services. The thesis presents a case study of a migration project from Lemonsoft's web team, which involved adapting an existing integration to support SOAP-based and RESTful services. The project utilized design patterns and a general client implementation to achieve a unified solution compatible with both protocols. In terms of performance, the evaluation showed that the general client led to faster execution times and reduced memory usage, enhancing the overall system efficiency. Additionally, improvements in maintainability were achieved by simplifying the codebase, using design patterns and object factories, adopting an interface-driven design, and promoting collaborative code reviews. These enhancements have not only resulted in a better user experience but also minimized future resource demands and maintenance costs. In conclusion, this thesis provides valuable insights into the functional and conceptual differences between SOAP-based and RESTful web services, the challenges and best practices for implementing a general client, and the justification for resource usage in such a solution based on performance and maintainability improvements

Lean technology development

Thesis (S.M.)--Massachusetts Institute of Technology, Technology and Policy Program, 2001.Includes bibliographical references (leaves 89-91).In today's corporate world, successful technology management is separating market leaders from laggards. Because technology is in constant change and what is state-of-the-art today will be obsolete tomorrow, it is not companies with the best technologies that ultimately succeed. Instead, successful companies are those that succeed in institutionalizing and sustaining an efficient technology development process. Moreover, this process must be continuously improved by applying new techniques and concepts to cope with the increasing challenges of technology management. This thesis will explore the extent to which Lean principles can be applied in technology development and how they can contribute to achieving new technology development imperatives (fast cycle time, increasing number of technology introductions, etc.). In order to answer these questions, the thesis proceeds in a logical manner by decomposing the objectives of technology development into organizational solutions using Axiomatic Design. Then, Lean principles as they have developed within the Product Development Focus Team of the Lean Aerospace Initiative are mapped into the above decomposition. The research concludes that under some additional considerations, Lean principles do lead to the achievement of technology development objectives. More, the above theoretical research is applied to a real world case: Technology development at Ford Motor Company. After an assessment of the current process, opportunities of improvement are identified and a leaner process is proposed. Finally, issues and opportunities with OEMs-Suppliers partnerships for new technological systems development are studied. The objective was to formulate policies and make recommendations for a better management of technology supply.by Salim Bouzekouk.S.M

Software and Performance Testing Tools

Software Testing may be a method, that involves, death penalty of a software system program/application and finding all errors or bugs therein program/application in order that the result is going to be a defect-free software system. Quality of any software sys-tem will solely be acknowledged through means that of testing (software testing). Through the advancement of technology round the world, there inflated the quantity of verification techniques and strategies to check the software system before it goes to production and astray to promote. Automation Testing has created its impact within the testing method. Now-a-days, most of the software system testing is finished with the automation tools that not solely lessens the quantity of individuals operating around that software system however additionally the errors which will be loose through the eyes of the tester. Automation take look acting contains test cases that make the work simple to capture totally different eventualities and store them. Therefore, software sys-tem automation testing method plays a significant role within the software system test-ing success. This study aims in knowing differing kinds of software system testing, soft-ware system testing techniques and tools and to match manual testing versus automa-tion testing

Building a Systematic Legacy System Modernization Approach

A systematic legacy system modernizing approach represents a new approach for modernizing legacy systems. Systematic legacy system modernization has software reuse as an integral part of modernization. We have developed a modernization approach which uses software architecture reconstruction to find reusable components within the legacy system. The practice of software development and modernization continues to shift towards the reuse of components from legacy systems to handle the complexities of software development. Modernization of a legacy system requires reuse of software artefacts from legacy system to conserve the business rules and improve the system’s quality attributes. Software reuse is an integral part of our systematic legacy modernization approach. Software should be considered as an asset and reuse of these assets is essential to increase the return on the development costs. Software reuse ranges from reuse of ideas to algorithms to any documents that are created during the software development life cycle. Software reuse has many potential benefits which include increased software quality, and decreased software development cost and time. Demands for lower software production and maintenance costs, faster delivery of systems and increased quality can only be met by widespread and systematic software reuse. In spite of all these benefits software reuse adoption is not widespread in the software development communities. Software reuse cannot possibly become an engineering discipline so long as issues and concerns have not been clearly understood and dealt with. We have conducted two surveys to understand the issues and concerns of software reuse in the Conventional Software Engineering (CSE) Community and the Software Product Line (SPL) Community where reuse is an integral part of the product development. The quantitative and qualitative analysis of our surveys identified the critical factors which affect and inhibit software engineers and developers adopting software reuse. Software reuse has been talked about in generic terms in software product lines. Though software reuse is a core concept in SPL it has however failed to become a standardized practice. The survey conducted on the SPL Community investigates how software reuse is adopted in SPL so as to provide the necessary degree of support for engineering software product line applications and to identify some of the issues and concerns in software reuse. The identified issues and concerns have helped us to understand the difference between software reuse in the CSE and SPL Communities. It has also given us an indication of how both communities can learn good software reuse practices from each other in order to develop a common software reuse process. Based on the outcome of our surveys we have developed a systematic software reuse process, called the Knowledge Based Software Reuse (KBSR) Process, which incorporates a Repository of reusable software assets to build a systematic legacy system modernization approach. Being able to reuse software artefacts, be it software requirement specification, design, or code, would greatly enhance software productivity and reliability. All of these software artefacts can go in the Knowledge Based Software Reuse Repository and be candidates for reuse