Calculated change weights

Calculated change weights

Source publication
Article
Full-text available
Software development is often affected by user/system requirements changes. To implement requirements changes, a system which is being developed needs to be reworked. However, the term ?Rework? has not been clearly defined in the literature. Depending on the complexity of the changes, the amount of rework required varies from some software module m...

Context in source publication

Context 1
... number of interactions for the DAAs was identified when calculating the IC value. CW CO is the total change weight for that option as shown in Table 8. ...

Similar publications

Article
Full-text available
This study aims to understand the concept of effectiveness in two work teams, one in each company, operating interdependently in running a project of software development. We attempted to identify the guiding factors of effectiveness over the time of the project by the perception of leaders and followers. The research has an exploratory qualitative...

Citations

... The market's demand for cutting-edge solutions intensifies the pressure on organizations, accelerating work pace and transmitting urgency to IT software development teams for delivering results within tighter deadlines, impacting the synergy between business strategy and technological platform evolution at PSECO [14]. As a result, some problems arise [15,16], such as: lack of time for complete requirements specifications; inaccurate time estimates; late projects; overspending due to rework on software artifacts; and prioritization of deadlines to the detriment of software quality. The result is a software project delivered with low quality, resulting in incidents in the organization's productive environment [17], as an example reported in 2013, when PayPal accidentally credited a man $92 quadrillion 2 . ...
Preprint
Full-text available
In the evolving landscape of Software Engineering, the paradigm of software ecosystems has emerged, giving rise to proprietary software ecosystems (PSECO), with their central organizations known as keystones. PSECO is characterized by the contribution of various technologies produced as private and protected by intellectual property and confidentiality agreements, centered on common technological platforms. Sustaining these PSECO technological platforms is vital, as any incident can have substantial repercussions. This work introduces a framework for incident management to support the organizations' management teams in the PSECO context, called IM Framework. The IM Framework was developed in close collaboration with practitioners across a large international organization. We grounded the IM Framework based on the results of a rapid review study that retrieved 293 studies, of which 23 were selected after applying review procedures. This framework comprises five core categories: organizational goals, practices, success factors, associated benefits, and prevalent barriers. The IM Framework offers practical guidance for the PSECO management team, focusing on real-world applications to enhance reliability and resilience in a complex and dynamic software environment. Our study also promises to fill the gap in incident management governance by supporting the PSECO organization's management team and maintaining robust technological platforms amidst evolving business demands and market pressures.
... Literature highlights that fixing/correcting software flaws consume half of the effort and resources of the project [1]. According to multiple studies, redoing increases cost, generate delays and require extra time [16,21] and directly impacts an organization's performance, productivity, and profit margins [38]. Most of the cost can approach or exceed 50 percent of the entire project cost [21]. ...
... According to multiple studies, redoing increases cost, generate delays and require extra time [16,21] and directly impacts an organization's performance, productivity, and profit margins [38]. Most of the cost can approach or exceed 50 percent of the entire project cost [21]. The cost of rework rises significantly in case of increased delay, relative to the development life cycle i.e., between the incidence of an issue and its remedy [38]. ...
Article
Full-text available
Global Software Development (GSD) involves multiple sites which comprise of different cultures and time zones apart from geographical locations. It is a common software development approach adopted to achieve competitiveness. However, due to multiple challenges it can result in misunderstandings and rework. Rework raises the chance of project failure by delaying the project and increasing the estimated budget. The aim of this study is to identify and categorize the rework causes to reduce its frequency in GSD. To identify the empirical literature related to causes of rework, we performed a Systematic Literature Review (SLR). A total of 23 studies are included as a result of final inclusion. The empirical literature from the year 2009 to 2020 is searched. The overall identified causes of rework in GSD are categorized into 6 major categories which are communication, Requirement Management (RM), roles of stakeholders, product development/integration issues, documentation issues, and differences among stakeholders. The most reported rework causes are related to the category of communication & coordination and RM. Moreover, an industrial survey is conducted to validate the identified rework causes and their mitigation practices from practitioners. This study will help practitioners and researchers in addressing the identified causes and therefore reduce the chances of rework.
Article
Quality of developed software totally relies upon three factors the time, effort and testing technique used for testing. Normally in large organizations, the development team allocates a high portion of estimated development time for software testing. Therefore, efficient algorithm needed for designing optimized test scenarios. Proposed approach can be apply on large and complex software. One of the most crucial and tedious task in SDLC is the generation of test scenario specially for large and complex problems. Generation as well as to execution of large number of test cases consumes high portion of effort and duration of total development effort and duration respectively. Therefore automatic testing has become the necessity of software industry specially large scale software development organization to reduce the testing cost to develop qualitative product. Also its very impractical to execute complete set of test case due to limited time and cost, the prioritization of test case is the solution to improve the software quality. Paper proposes a modelling based testing approach to generate test scenarios that uses UML activity diagram (AD). To prioritized the test cases average percentage fault detection (APFD) metrics is used. the proposed approach carries two phases, In the first phase specification information of AD is transferred into an arbitrary and testable graph called activity interaction graph using proposed parser. To execute the second phase a algorithm named TSPACO: the combination of DFS and BFS is proposed. In second phase TSPACO is applied to generate test scenarios with respect to decision and concurrent criteria to prioritize the test scenarios. The proposed model generates prioritized test scenarios according to strength values of different types of activity diagram which are- forks, joins and merge point’, developed by using the proposed TSPACO algorithm. Using the APFD metric, effectiveness of the generated test scenarios is computed. The experimental results shows that test cases generated by proposed approach have 14% more effectiveness than the other existing approaches.