Success Of Software Product Research Articles

The key factors contribute to time pressure in software development projects: A review

The success of software development projects is often hindered by time pressure (TP), leading to decreased productivity, compromised quality, and increased risk of failure. To address this issue, it is crucial to understand the key factors contributing to TP in software development projects. In line with the study's objectives, the review methodology followed the Kitchenham and Charters criteria, and a search strategy encompassed four primary digital databases, namely IEEE, ACM Digital Library, Science Direct, and Springers, resulting in 4,500 relevant sources. After applying inclusion and exclusion criteria, a total of 128 papers were selected for analysis. This paper offers a comprehensive overview of the factors contributing to TP in software development. This study synthesizes the findings from multiple studies to guide practitioners in improving their project management approaches and highlights the significance of enhancing various aspects of the development process. The findings highlight the importance of improving project management, estimation techniques, knowledge, and skills to effectively manage TP. Additionally, managing requirements volatility, setting clear goals and objectives, and reducing distractions and interruptions emerge as crucial strategies for mitigating TP and enhancing project success. Furthermore, selecting software developers based on their personality traits is recommended to foster a work environment conducive to reduced TP and improved software development outcomes. By understanding and addressing these factors, software development teams can alleviate TP and increase the likelihood of successful software products. Implementing these recommendations can contribute to reduced TP, improved project outcomes, and enhanced overall success in software development.

Generating large dataset for software requirements prioritization and selection under fuzzy environment

Requirements elicitation is a key sub-process of requirements engineering in which various types of software requirements such as functional and non-functional requirements, testing requirements etc., are identified according to the needs of the stakeholders. After the completion of the requirements elicitation process, there may be a large set of requirements and practically it is not possible to implement all requirements due to budget, time and other constraints of an organization. Under this situation, software developers select the highest ranked software requirements from the list of the elicited software requirements for different releases of software so that a successful software product can be developed. The selection of software requirements for different releases is a difficult task because it requires the participation of various stakeholders. In the field of science and engineering, datasets play an important role during experimental work. Based on our review, we found that in the literature of software engineering less attention is given on the generation of the datasets particularly in the domain of software requirements prioritization and selection (SRPS). Therefore, to address this issue, in this paper we present a four-step method for generating the dataset for SRPS research, i.e. (a) identification of stakeholders, (b) elicitation of software requirements using the goal-oriented concept, (c) formation of decision maker committee and (d) evaluation of the functional requirements and non-functional requirements by decision makers under fuzzy environment. The proposed method has been applied to generate the dataset for the requirements of an institute examination system.

Applying virtual reality to teach the software development process to novice software engineers

Software development is a complicated process that requires experienced human resources to produce successful software products. Although this process needs experience from the individuals, it is hard to provide this experience without encountering real incidents during the software development process. To fill this gap, this study proposes a Virtual Reality Based Software Development Framework (VR-SODEF), which provides an interactive virtual reality experience for individuals learning about the tasks of software development starting from requirement analysis through software testing. In the VR-SODEF, the participant takes on the role of a novice software developer being recruited into a virtual software development organisation who should work alongside five virtual characters, played by artificial intelligence. This exclusive viewpoint draws participants from the 2D separation of the classical experience and virtually into the world of the software development itself. Participants experience the intense dramatic elements created for simulation and confront the challenges of virtual software practitioners in a somewhat uncompromising virtual simulation environment. To examine the efficiency of the VR-SODEF, it was tested on 32 computing students, with results indicating that virtual reality can be an effective educational medium, especially for skills that might traditionally be acquired through experience rather than traditional classroom-based teaching.

A validated model for the scoping process of quality requirements: a multi-case study

Quality requirements are vital to developing successful software products. However, there exist evidence that quality requirements are managed mostly in an “ad hoc” manner and down-prioritized. This may result in insecure, unstable, slow products, and unhappy customers. We have developed a conceptual model for the scoping process of quality requirements – QREME – and an assessment model – Q-REPM – for companies to benchmark when evaluating and improving their quality requirements practices. Our model balances an upfront forward-loop with a data-driven feedback-loop. Furthermore, it addresses both strategic and operational decisions. We have evaluated the model in a multi-case study at two companies in Sweden and three companies in The Netherlands. We assessed the scoping process practices for quality requirements and provided improvement recommendations for which practices to improve. The study confirms the existence of the constructs underlying QREME. The companies perform, in the median, 24% of the suggested actions in Q-REPM. None of the companies work data-driven with their quality requirements, even though four out of five companies could technically do so. Furthermore, on the strategic level, quality requirements practices are not systematically performed by any of the companies. The conceptual model and assessment model capture a relevant view of the quality requirements practices and offer relevant improvement proposals. However, we believe there is a need for coupling quality requirements practices to internal and external success factors to motive companies to change their ways of working. We also see improvement potential in the area of business intelligence for QREME in selecting data sources and relevant stakeholders.

Analysis of the development of open GIS software and QGIS system

Abstract. Open source software could emerge thanks to the development of the Internet, development tools, and computer literacy in general. The most attractive parameter of open source GIS software is a free license. The rapid pace of development, attracting developers from all over the world and high modularity stimulate the innovative nature of open source software. Here, the introduction of new technologies does not meet with opposition, but rather welcomes. These circumstances, as well as elucidation of the functional capabilities of such GIS, become very important in the search for means of providing the educational process with modern GIS software, which is traditionally an expensive proprietary software. Goal: Analysis of up-to-date GIS software protection and visual accessibility of the QGIS system in the first place with studying geoinformation systems.Quantum GIS (QGIS) is an open source software (GIS) geographic information system (GIS). Open software is one of the most interesting technological phenomena of the present, owing to its rapid growth in the development of the Internet, development tools and computer literacy in general. The key role in the creation, development and support of open source software is played, as a rule, by the community of developers forming around individual software products: commercial companies, groups of enthusiasts or research organizations. The term open source was proposed by Bruce Perens, one of the key leaders in the Open Source and Free Software movement, cofounder with Eric Raymind in 1998 of the Open Source Initiative (OSI), an open source software development organization that promotes and provides technical open source support. This open source term is used by OSI to determine whether a software license complies with open source standards. The main features of open source software as defined include free distribution, accessible source code, permission to modify this source code. At the same time, even successful open source software products require companies on the market ready to provide technical support and advice on issues related to the selected products. However, the number of companies providing support services for open source GIS software is still relatively small.

An Interactive and Dynamic Search-Based Approach to Software Refactoring Recommendations

Successful software products evolve through a process of continual change. However, this process may weaken the design of the software and make it unnecessarily complex, leading to significantly reduced productivity and increased fault-proneness. Refactoring improves the software design while preserving overall functionality and behavior, and is an important technique in managing the growing complexity of software systems. Most of the existing work on software refactoring uses either an entirely manual or a fully automated approach. Manual refactoring is time-consuming, error-prone and unsuitable for large-scale, radical refactoring. On the other hand, fully automated refactoring yields a static list of refactorings which, when applied, leads to a new and often hard to comprehend design. Furthermore, it is difficult to merge these refactorings with other changes performed in parallel by developers. In this paper, we propose a refactoring recommendation approach that dynamically adapts and interactively suggests refactorings to developers and takes their feedback into consideration. Our approach uses NSGA-II to find a set of good refactoring solutions that improve software quality while minimizing the deviation from the initial design. These refactoring solutions are then analyzed to extract interesting common features between them such as the frequently occurring refactorings in the best non-dominated solutions. Based on this analysis, the refactorings are ranked and suggested to the developer in an interactive fashion as a sequence of transformations. The developer can approve, modify or reject each of the recommended refactorings, and this feedback is then used to update the proposed rankings of recommended refactorings. After a number of introduced code changes and interactions with the developer, the interactive NSGA-II algorithm is executed again on the new modified system to repair the set of refactoring solutions based on the new changes and the feedback received from the developer. We evaluated our approach on a set of eight open source systems and two industrial projects provided by an industrial partner. Statistical analysis of our experiments shows that our dynamic interactive refactoring approach performed significantly better than four existing search-based refactoring techniques and one fully-automated refactoring tool not based on heuristic search.

APPLICATION OF NEGATIVE SPECIAL SOFTWARE TESTING TECHNIQUE WITHIN TESTING SAMPLES OF WEAPONS AND MILITARY EQUIPMENT

The article reveals views on the purpose and direction of negative testing of special software. The research paper also provides an indicative list of questions recommended to be planned for testing using the technique of negative testing. The provisions of legal acts of Ukraine and practical experience in the field of software testing are also taken into account in the article.
 Negative testing is very relevant for testing special software products used in weapons. This is because the risks of error are very critical and sensitive.
 The main sources and causes of errors in the software are: user, input data, resources, procedures for output and storage of data, exchange with other programs or computers, operating conditions of the program, compatibility and coherence with other software.
 Negative testing is proposed to be used at the following stages of software use: installation, first run, authorization, data entry, software module startup, calculations, data conversion, data exchange with other systems, data storage, display information, data printing, saving settings software operation.
 The article states that the procedure for conducting negative testing should be carefully thought out. To do this, at the planning stage of software testing, specialists with experience in successful testing such software products are involved.
 It is assumed that when planning a negative test, a group of experts uses information about the program, their own testing experience and intuition of the tester. At the same time, the main efforts are aimed at creating such conditions under which the software may work incorrectly. Negative testing is planned to cause just that non-standard behavior of the program.
 The suggested approaches to perform negative testing are proposed to be taken into account when testing the special software that is installed at the workplaces of the Command Posts of the Armed Forces of Ukraine, as well as on weapons and military equipment.

Comparison of Machine Learning Techniques for Software Quality Prediction

Software quality prediction is one the most challenging tasks in the development and maintenance of software. Machine learning (ML) is widely being incorporated for the prediction of the quality of a final product in the early development stages of the software development life cycle (SDLC). An ML prediction model uses software metrics and faulty data from previous projects to detect high-risk modules for future projects, so that the testing efforts can be targeted to those specific ‘risky' modules. Hence, ML-based predictors contribute to the detection of development anomalies early and inexpensively and ensure the timely delivery of a successful, failure-free and supreme quality software product within budget. This article has a comparison of 30 software quality prediction models (5 technique * 6 dataset) built on five ML techniques: artificial neural network (ANN); support vector machine (SVMs); Decision Tree (DTs); k-Nearest Neighbor (KNN); and Naïve Bayes Classifiers (NBC), using six datasets: CM1, KC1, KC2, PC1, JM1, and a combined one. These models exploit the predictive power of static code metrics, McCabe complexity metrics, for quality prediction. All thirty predictors are compared using a receiver operator curve (ROC), area under the curve (AUC), and accuracy as performance evaluation criteria. The results show that the ANN technique for software quality prediction is promising for accurate quality prediction irrespective of the dataset used.

User Involvement in Continuous Experimentation

Software product and service companies need capabilities to evaluate their development decisions and customer and user value. Continuous experimentation, as an experiment-driven development approach, may reduce such development risks by iteratively testing product and service assumptions that are critical to the success of the software. Experimentdriven development is gaining increasing attention by the practitioners, yet it is a novel research area to be investigated. Involving users and customers in the software development process and understanding their needs and behaviors are essential aspects when building successful software products and services. Continuous experimentation approach in software development comprises user involvement by its nature, however, due to novelty of the concept, there is no clear understanding of the user involvement practices. My doctoral project aims to investigate how software development organizations can involve the users in continuous experimentation. The contributions of the research are to a) find out how involve users in software companies that begin to adopt continuous experimentation approach, b) identify the barriers hindering involving the users in the approach, and c) investigate what kinds of strategies have been used for experimentation with different software product and services.

Developers’ Views on Information Systems Quality and Success in Canadian Software Development Firms

For years software developers have struggled in their attempts to deliver high quality and successful software products. A survey was conducted in Canada to assess the main determinants of information systems (IS) quality and success. The survey confirmed the notion that developer skills and contribution had the greatest impact on information systems quality, over process maturity and the application of the latest technology. The survey also discovered that user perception had a greater impact on IS success in comparison to IS quality. In an attempt to gain deeper insights into the state of IS quality and success in Canada, interviews were conducted with Canadian software developers. The interviews revealed that organization climate such as top management support, the social interactions and dynamics among project team members and the structural analysis of the industry are other factors which can influence the quality and success of the delivered software product. These insights if applied during the development and delivery of information systems can enhance the likelihood of producing high quality and successful software products and increase the competitiveness of these firms.

Challenges and strategies for motivating software testing personnel

ContextSoftware testing is the key to ensuring a successful and reliable software product or service, yet testing is often considered uninteresting work compared to design or coding. As any human-based activity, the outcome of the final software product is dependent of human factors and an essential challenge for software development organizations is to find effective ways to enhance the motivation and job-satisfaction of their testers. ObjectiveOur study aims to cast light on how professional software testers can be motivated and we explore the policies and rules conceptualized and implemented inside software development projects. MethodThis paper presents the results of an empirical study that collected data through semi-structured and in-depth interviews with 36 practitioners from 12 companies in Norway. The data collection was performed over a two years period and investigates the strategies applied by the companies for stimulating their testers, while considering the motivational and de-motivational factors influencing the testing personnel. ResultsOur results provide a set of motivational and de-motivational factors for software testing personnel and present the strategies deployed by the companies for stimulating their testing staff. ConclusionsThe study shows that combining testing responsibilities with development and ensuring a variety of engaging, challenging tasks and products does increase the satisfaction of testing personnel. However, despite the systematic and sincere effort invested in recognizing the importance of testing and motivating the testers, heavy emphasis is laid on minimizing project costs and duration. The results could help the companies in organizing and managing processes and stimulate their testing personnel, which will lead to better job satisfaction and productivity.

Characteristics of Agile Teams– A Discussion on Technology and Culture

Agile methodologies offer an alternative to traditional software engineering processes for developing software products and systems. They focus on integrating behavioral and social factors into software development. The focus on people is a very important factor in the implementation of agile methodologies in the workplace. The focus on agile teams for developing software systems and products using agile software development methodologies predisposes the emphasis on the analysis of the key components of agile teams which are important to ensure that the characteristics of agile teams are factored appropriately in the organization so that the teams are having the pre-requisite environment setup for successfully developing software systems.This paper investigates the various components and social processes that contribute to the characteristics of agile. The paper aims at highlighting a framework made up of various components that focus on the critical attributes of an agile team and if these attributes are present in an agile team, then the probability for the team to work as a high performance agile team and deliver successful software products in the market place is increased considerably.

Managing Software's Impact

As a review of past articles in IEEE Software's Impact department shows, software economics largely determines a software product's success, and volume plays a key role.

Product Personification: Parag Model to Successful Software Product Development

The ubiquity and abundance of web, mobile, hybrid, and wearable software in today’s technology driven lifestyle is unmistakable in personal, social, and professional life highlighting the importance of software product development. With the growth of agile and lean approaches to product development, the responsibilities associated with many of the traditional roles have merged and new roles emerging. The impact of these new trends on software product development have led to misunderstandings leading to product owners bringing their own personal approaches to product development failing to focus on the actual product itself and the effect on the performing organization, clients, and end user. This paper focuses on a new paradigm shifting the focus from product owner to the software product itself by giving it a life and voice to echo the characteristics needed for its adoption, penetration, and sustenance.

Requirements Engineering in Software Houses of Pakistan

Requirement engineering is an essence of software development life cycle. The more time we spend on requirement engineering, higher the probability of success. Effective requirement engineering ensures and predicts successful software product. This paper presents the adaptation of requirement engineering practices in small and medium size companies of Pakistan. The study is conducted by questionnaires to show how much of requirement engineering models and practices are followed in Pakistan.

A method to optimize the scope of a software product platform based on end-user features

ContextDue to increased competition and the advent of mass customization, many software firms are utilizing product families – groups of related products derived from a product platform – to provide product variety in a cost-effective manner. The key to designing a successful software product family is the product platform, so it is important to determine the most appropriate product platform scope related to business objectives, for product line development. AimThis paper proposes a novel method to find the optimized scope of a software product platform based on end-user features. MethodThe proposed method, PPSMS (Product Platform Scoping Method for Software Product Lines), mathematically formulates the product platform scope selection as an optimization problem. The problem formulation targets identification of an optimized product platform scope that will maximize life cycle cost savings and the amount of commonality, while meeting the goals and needs of the envisioned customers’ segments. A simulated annealing based algorithm that can solve problems heuristically is then used to help the decision maker in selecting a scope for the product platform, by performing tradeoff analysis of the commonality and cost savings objectives. ResultsIn a case study, PPSMS helped in identifying 5 non-dominated solutions considered to be of highest preference for decision making, taking into account both cost savings and commonality objectives. A quantitative and qualitative analysis indicated that human experts perceived value in adopting the method in practice, and that it was effective in identifying appropriate product platform scope.

Using a Rule-based Method for Detecting Anomalies in Software Product Line

This study proposes a rule based method for detecting anomalies in SPL. By anomalies we mean false-optional features and wrong cardinality. Software Product Line (SPL) is an emerging methodology for software products development. Successful software product is highly dependent on the validity of a SPL. Therefore, validation is a significant process within SPL. Anomalies are well known problems in SPL. Anomiles in SPL means dead feature, redundancy, wrong-cardinality and false-option features. In the literature, the problem of false-option features and wrong cardinality did not take the signs of attentions as a dead feature and redundancy problems. The maturity of the SPL can be enhanced by detecting and removing the false-option features. Wrong cardinality can cause problems in developing software application by preventing configuration of variants from their variation points. The contributions of this study are First Order Logic (FOL) rules for deducing false-option features and wrong-cardinality. Moreover, we provide a new classification of the wrong cardinality. As a result, all cases of false-option features and wrong variability in the domain-engineering process are defined. Finally, experiments are conducted to prove the scalability of the proposed method.

Towards detecting redundancy in domain engineering process using first order logic rules

Software product line SPL is an emerging methodology for developing software products. SPL consists of two processes: domain-engineering and application-engineering. Successful software product is highly dependent on the validity of a domain engineering process. Therefore, validation is a significant process within the domain-engineering. Anomalies such as dead feature, redundancy, and wrong-cardinality are well-known problems in SPL. In the literature, redundancy did not take the signs of attentions as a dead feature and wrong-cardinality. The maturity of the SPL can be enhanced by detecting and removing the redundancy from the domain engineering. This paper proposes first order logic FOL rules for detecting the redundancy in domain-engineering process. Detecting redundancy in the domain engineering direct is our contribution. Our methodology comprised of three steps: 1 variability is modelled in the form of predicates as a prerequisite; 2 for each type of the redundancy, a general form is formulated to swathe all possible cases; 3 FOL rules are illustrated to implement each possibility based on deducing the results from predefined cases. As a result, all forms of redundancies in the domain-engineering process are amorphous. Finally, experiments are conducted to attest the scalability of our method.

Quality Requirements in Industrial Practice—An Extended Interview Study at Eleven Companies

In order to create a successful software product and assure its quality, it is not enough to fulfill the functional requirements, it is also crucial to find the right balance among competing quality requirements (QR). An extended, previously piloted, interview study was performed to identify specific challenges associated with the selection, tradeoff, and management of QR in industrial practice. Data were collected through semistructured interviews with 11 product managers and 11 project leaders from 11 software companies. The contribution of this study is fourfold: First, it compares how QR are handled in two cases, companies working in business-to-business markets and companies that are working in business-to-consumer markets. These two are also compared in terms of impact on the handling of QR. Second, it compares the perceptions and priorities of QR by product and project management, respectively. Third, it includes an examination of the interdependencies among quality requirements perceived as most important by the practitioners. Fourth, it characterizes the selection and management of QR in downstream development activities.

Are you biting off more than you can chew? A case study on causes and effects of overscoping in large-scale software engineering

ContextScope management is a core part of software release management and often a key factor in releasing successful software products to the market. In a market-driven case, when only a few requirements are known a priori, the risk of overscoping may increase. ObjectiveThis paper reports on findings from a case study aimed at understanding overscoping in large-scale, market-driven software development projects, and how agile requirements engineering practices may affect this situation. MethodBased on a hypothesis of which factors that may be involved in an overscoping situation, semi-structured interviews were performed with nine practitioners at a large, market-driven software company. The results from the interviews were validated by six (other) practitioners at the case company via a questionnaire. ResultsThe results provide a detailed picture of overscoping as a phenomenon including a number of causes, root causes and effects, and indicate that overscoping is mainly caused by operating in a fast-moving market-driven domain and how this ever-changing inflow of requirements is managed. Weak awareness of overall goals, in combination with low development involvement in early phases, may contribute to ‘biting off’ more than a project can ‘chew’. Furthermore, overscoping may lead to a number of potentially serious and expensive consequences, including quality issues, delays and failure to meet customer expectations. Finally, the study indicates that overscoping occurs also when applying agile requirements engineering practices, though the overload is more manageable and perceived to result in less wasted effort when applying a continuous scope prioritization, in combination with gradual requirements detailing and a close cooperation within cross-functional teams. ConclusionThe results provide an increased understanding of scoping as a complex and continuous activity, including an analysis of the causes, effects, and a discussion on possible impact of agile requirements engineering practices to the issue of overscoping. The results presented in this paper can be used to identify potential factors to address in order to achieve a more realistic project scope.