How Agile COTS Selection Methods are (and can be)?

The use of commercial-off-the-shelf (COTS) software has become more and more important in state-of-the-art and state-of-the-practice software and system development. The use of COTS software promises faster time-to-market, reduced development costs, increased productivity, and the possibility for companies to focus on their own core competencies. At the same time, COTS software increases risks, such as the economic instability of the COTS software vendor, unknown quality properties of the COTS software in use, and side-effects of the COTS software on the final product. Typically, COTS-based development, in parallel with the traditional development cycle (e.g. waterfall, spiral), consists of four phases. The first phase (COTS assessment and selection) is the most crucial phase in the COTS-based cycle, since long-term decisions about which COTS software to use in a software system are made there. A late recognition that the wrong COTS software was used can become extremely costly for a software organization. This paper presents a repeatable, cost-efficient and systematic method for performing measurement-based COTS assessment and selection. Moreover, cost/benefit analysis results of two industrial pilot projects, in which the method was successfully applied, are presented.

In the process of selecting Commercial Off-The-Shelf (COTS) products, it is inevitable to encounter mismatches between system requirements and COTS products. These mismatches occur as a result of an excess or shortage of the COTS attributes. This paper proposes a decision support approach, called MiHOS (Mismatch Handling for COTS Selection), that aims at addressing COTS mismatches during and after the selection process. MiHOS can be integrated with existing COTS selection methods at two points: (1) For evaluating COTS candidates: MiHOS estimates the anticipated fitness of the candidates if their mismatches are resolved. This helps to base our COTS selection decisions on the fitness that the candidates will eventually have if selected. (2) Mismatch resolution after selecting a COTS product: MiHOS suggests alternative plans for resolving the most appropriate mismatches using suitable actions, such that the most important risk, technical, and resource constraints are met. A case-study is used to illustrate MiHOS and to discuss its added value.

This study aims to determine the governance of electronic-based medical records in making outpatient polyclinic reports using the agile method. The research method used is qualitative research with a descriptive approach. After analyzing the needs of the polyclinic reporting system, this study presents the steps of implementing the agile method of extreme programming. By using this method, a system that is adaptable, responsive, and focused on user needs can be developed. The results show that the use of the agile extreme programming method in the development of an electronic-based medical record system provides significant benefits. The process of planning, designing, coding, testing, and releasing is done iteratively and collaboratively. With this approach, the system can be continuously improved and adjusted to meet changing user needs and priorities. By describing the system design flowmap, context diagram, DFD and ERD to visualize the relationship between the components in the system that provides a systematic description of the stages of the report generation process. In conclusion, electronic-based medical record governance in making outpatient polyclinic reports using the agile extreme programming method is an effective and efficient approach. By combining the advantages of agile and extreme programming methods, an adaptive and responsive system can be developed.

This research work explores the trends in formal and agile software development methods. Software development has evolved, from the era of “code and fix” to methods categorized as “heavyweight” and “lightweight”. The heavyweight methods are championed by the waterfall method, while agile methods are considered the lead in lightweight methods of software development. Both methods have proven records of successes and failures. Bridging the divide between them and harmonizing their symbiotic properties has the synergy of creating beneficial and more robust methodology with complementary advantage which is termed ambidexterity. Ambidexterity allows for a high level approach of selecting a methodology on the basis of the problem requirements, and coordinates their independent processes complementarily without conflict. Keywords: Global Software Development, Agile Software Development, off Shoring, Near-shoring, Distribution

The agile paradigm is used today for software development and project as an alternative to structured and traditional heavier life cycles. Different meta-models have been proposed trying to unify agile methods. Yet, very few of them focus on agile partial method adoption. Intuitively, choosing which practices to adopt from agile methods should be made based on their most prioritized goals in the software development process. The paper answers this issue by building a goal-oriented meta-model where each agile concept is seen as a goal to achieve and explaining how goal modeling can help the software team to partially adopt agile methods. This will also make it easier to identify vulnerabilities associated with each goal and minimize risks.

When the traditional method lacking in adapting requirement variety, some agile software development methods appears, which flexible development mechanism could control the risk that requirement variety brings. Taking Extreme Programming as an example, this paper introduces ideas, values and process practice rules of agile methods. Extreme Programming is a software development methodology that is agile and based on practice. This paper introduces the features of Extreme Programming and how to practice Extreme Programming in developing management information system, also discuss and study the advantages and disadvantages when applying Extreme Programming in small or middle sized projects with inconstant requirements.

One of the main goals of Software Engineering is to produce software with quality. But with the increasing use of agile methodologies in software development, it is observed that the existing quality assurance models do not adapt easily to these methods. In this context, the objective of this research is to propose critical factors of success (CFS) and tools for software development and management environment using agile methods, focusing on quality. Thus, initially, a literature review was conducted in SCOPUS and SCIELO bases, identifying 21 CFS, which were grouped into three categories: Individual; Organizational; and Technical / Process. Based on these factors, a questionnaire was applied to specialists in software management and development, reaching the sample of 101 respondents, with the most important CFS belonging to the Personal category, which reinforces the need for investment in this area. After this field research, a case study was done in a public company that uses traditional methods, making it possible to propose a development and management environment of software, adding the best practices, tools and CFS with the purpose of improve the quality of delivery of the final product. It was also observed the applicability of the agile Scrum method, allied to Kanban, taking advantage of the best practices of both, and how much was relevant in the context of the company, demonstrating the importance of agile methods to improve the quality and productivity of the whole team, including customers and sponsors. In addition, the present work generates an CFS base for knowledge of the academic community.

Software development depends on various factors and organizational culture is one of them. Recently agile software development, with its emphasis on agility, has received much attention. Research so far has focused on the constructs that define agility and also identified the reasons that limit teams from exhibiting all the constructs of agile software development. This lead to re-defining agility by using economic, quality, simplicity and the relationship with the environment it operates on. One of the factors that contribute to relationship with environment is organizational culture. Though relationship of organizational culture and software methods is not new, analyzing the relationship further in the new defined definition of agility can provide deep insights into software development. In this paper a qualitative research method of multiple case-studies consisting of 3 releases of one product development team was selected. Data was collected using participant-observation method. Research findings have identified some useful insights that could provide researchers and practitioners to develop software development life-cycle that incorporates existing agile methods and uses diverse set of methods to resolve issues including organizational issues. Thereby the new software development life-cycle would not distinguish between agile and plan-driven development methods and could shape itself in the changing context.

Discussions on agile software development methodologies have a tendency to develop into an argument between proponents of agile methods and proponents of more traditional process-oriented methodologies. The terminology used in these debates is often unhelpful, and in many cases are inaccurate and biased representations. It needs to be accepted that there are no “silver bullets” providing universal solutions (Jeffries, 2001). Bearing this in mind, the decision to adopt a particular software development methodology is a difficult one, and the decision to choose an agile method is no exception. In theory, as in practice, definitions and descriptions of the various agile methods are presented, yet the factors considered in the decision to adopt, or not adopt, an agile method are not addressed. While agile methodologies try to avoid the excessive use of procedures or tools (Beck & Fowler, 2001), one agile methodology, dynamic systems development method (DSDM), does recommend the use of appropriate tools during the development process (Coesmans, 2003). However, it appears that none of the available agile methodologies suggest a tool to assist decision makers at the project initiation phase, therefore, the debate on agile suitability is usually a debate on agile versus traditional methods (DeMarco & Boehm, 2002), rather than an examination of the suitability of agile methods for a particular project. While the “agile debate” rages, individual projects are not adequately assessed prior to the adoption of a method.

Agile methods such as Dynamic Systems Development Method (DSDM), Extreme Programming (XP), SCRUM, Agile Modeling (AM) and Crystal Clear enable small teams to execute assigned task at their best. However, larger organizations aim at incorporating more Agile methods owing to the fact that its application is prevalently tailored for small teams. The scope in which large firms are interested will extend the original Agile methods to include larger teams, coordination, communication among teams and customers as well as oversight. Determining particular software method is always challenging for software companies especially when considering start-up, small to medium or large enterprises. Most of large organizations develop large-scale projects by teams of teams or teams of teams of teams. Therefore, most recognized Agile methods or first-generation methods such as XP and SCRUM need to be modified before they are employed in large organizations; which is not an easy task. Accomplishing said task would necessitate large organizations to pick and select from the scaling Agile methods in accommodating a single vision for large and multiple teams. Deciding the right choice requires wholesome understanding of the method including its strengths and weaknesses as well as when and how it makes sense. Therefore, the main aim of this paper is to review the existing literature of the utilized scaling Agile methods by defining, discussing and comparing them. In-depth reviews on the literature were performed to juxtapose the methods in impartial manner. In addition, the content analysis was used to analyse the resultant data. The result indicated that the DAD, LeSS, LeSS huge, SAFe, Spotify, Nexus and RAGE are the adopted scaling Agile methods at large organizations. They seem to be similar but there are discrepancies among them that take the form of team size, training and certification, methods and practices adopted, technical practices required and organizational type.

The use of commercial-off-the-shelf (COTS) products provides the Department of Defence with benefits such as reduced costs and time associated with the research and development of new military defence equipment. However, acquisition organizations face several challenges in the evaluation and selection process of the correct COTS products that comply with the requirements of a client such as the Department of Defence. The purpose of this research was to present a systematic customized framework for the evaluation and selection of COTS products for use as military defence equipment. The phases involved in the COTS evaluation and selection processes, challenges faced by the evaluators and mitigation to overcome the problem were identified through the reviewed literature and evidence collected from a case study. A framework for the selection of COTS products for use as military defence equipment is proposed with the aim to eliminate the lack of support by the acquisition organization to the client during the user requirements definition phase.

In recent years, agile software development methods have gained increasing popularity. Distributed software development have been becoming a common business reality also. Software development organizations are striving to blend agile development methods like Scrum and distributed development to reap the benefits of both. However, agile and distributed development approaches differ significantly in their key tenets. While agile methods mainly rely on informal processes to facilitate coordination, distributed development typically relies on formal mechanisms. This paper aims at implementing modular design of software products to identify feature clusters that can be implemented co-located to minimize the communication needs between distributed teams. Presented method is evaluated with simulations that demonstrate how this method can produce 1) lower-risk feasible plans, 2) balanced workload on teams, and 3) provide higher quality feature distributions. Finally, the paper analyzes benefits and issues from the use of this method.Keywordsdistributed software developmentagile release planning

The effectiveness of system analysis and design methodologies plays a pivotal role in the success of software development projects. This research conducts a comparative analysis of various methodologies, including the Waterfall Model, Spiral Model, Prototyping Model, Iterative Model, Unified Process, Object-Oriented Analysis and Design, Joint Application Design, Computer Aided Software Engineering Tools, Rapid Application Development / Rapid Systems Development, Feature- Driven Development, Extreme Programming, Agile Method, and DevOps, to explore their respective strengths and considerations. The study examines key aspects such as flexibility, documentation, risk management, complexity, and suitability across these methodologies. Findings reveal that each methodology offers unique advantages and challenges, influencing their applicability in different project contexts. The research underscores the importance of aligning methodology choices with project-specific requirements, organizational culture, and environmental factors to optimize software development outcomes. Moreover, it suggests that hybrid approaches, combining elements from multiple methodologies, may offer a balanced approach to address diverse project needs and maximize effectiveness. By providing insights into the comparative effectiveness of system analysis and design methodologies, this research contributes to informed decision- making and improved project success in software development endeavors.

Software organizations have typically de-emphasized the importance of software testing. In this paper, the results of a regional survey of software testing and software quality assurance techniques are described. Researchers conducted the study during the summer and fall of 2002 by surveying software organizations in the Province of Alberta. Results indicate that Alberta-based organizations tend to test less than their counterparts in the United States. The results also indicate that Alberta software organizations tend to train fewer personnel on testing-related topics. This practice has the potential for a two-fold impact: first, the ability to detect trends that lead to reduced quality and to identify the root causes of reductions in product quality may suffer from the lack of testing. This consequence is serious enough to warrant consideration, since overall quality may suffer from the reduced ability to detect and eliminate process or product defects. Second, the organization may have a more difficult time adopting methodologies such as extreme programming. This is significant because other industry studies have concluded that many software organizations have tried or will in the next few years try some form of agile method. Newer approaches to software development like extreme programming increase the extent to which teams rely on testing skills. Organizations should consider their testing skill level as a key indication of their readiness for adopting software development techniques such as test-driven development, extreme programming, agile modelling, or other agile methods.

<p>eXtreme programming (XP) is one of a new breed of methods, collectively known as the agile methods, that are challenging conventional wisdom regarding systems development processes and practices. Practitioners specifically designed the agile methods to meet the business problems and challenges we face building software today. As such, these methods are receiving significant attention in practitioner literature. In order to operate effectively in the world of vague and changing requirements, XP moves the emphasis away from document-centric processes into practices that enable people. The Customer is the primary organisational facing role in eXtreme Programming (XP). The Customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. This thesis presents a grounded theory of XP software development requirements elicitation, communication, and acceptance, which was guided by three major research questions. What is the experience of being an XP Customer? We found that teams agree that the on-site customer practice is a drastic improvement to the traditional document-centric approaches. Our results indicate, however, that the customers are consistently under pressure and commit long hours to the project in order to fulfil the customer role. So while this approach to requirements is achieving excellent results, it also appears to be unsustainable and thus constitutes a great risk to XP projects. Who is the XP Customer? The initial definition of XP resulted in many people interpreting the onsite customer to be a single person. This research has highlighted that a customer team always exists, and goes further to outline the ten different roles that were covered on the team, which range from the recognised "Acceptance Tester" role to the less recognised roles of "Political Advisor" and "Super-Secretary". What are the practices that support an XP Customer to perform their role effectively on a software development project? An additional eight customer-focused practices have been uncovered to supplement the existing XP practices. These customer-focused practices together enable customers to sustainably drive XP projects to successful completion. The practices range from those that specifically focus on interaction (both with the programmer team and the larger organisation) e.g. "Programmer On-site" and "Roadshows" to those that specifically look to the well-being and effectiveness of the customer (e.g. "Pair Customering") to those that highlight the key steps or activities that need to occur along the way (e.g. "Big Picture Up-Front" and "Recalibration").</p>