In-house Software Development Research Articles

Reasons for the Failure of Most In-House Software Development in Tanzania: A Case Study of Selected Higher Learning Institutions (HLIs)

Since it has evolved into an essential part of today’s world, 90% of Tanzanian businesses have attempted to develop in-house software for their operations. However, a substantial fraction of these projects haven’t quite achieved what they set out to. The bulk of in-house software development projects in Tanzania have been unsuccessful. This article presents ideas for improving the success rate of in-house software development initiatives and explains why this is the case. As part of the qualitative research methodology, software developers, project managers, and other stakeholders took part in focus groups and interviews. The results show that there are several factors, such as a lack of qualified staff, an inadequate budget allocation, poor project management, a lack of precise project requirements, improper communication, an inadequate amount of resources, and a lack of user involvement, that significantly contribute to the failure of in-house software development projects in Tanzania. The study makes numerous recommendations for enhancing the success rate of in-house software development initiatives in Tanzania. Involving end users throughout the project life cycle, implementing strong project management practices, allocating enough time and resources for software testing, hiring experts to establish and gather precise project requirements, allocating adequate budgets, and setting up efficient communication channels are a few examples of these. Additionally, in-house software development must adhere to the SDLC’s standards by enhancing the model of the SDLC that best suits the nature of the development process.

In-house software development for software-defined vehicles: major changes ahead in automotive value chains

In-house software development for software-defined vehicles: major changes ahead in automotive value chains

Comparative study of SPI success factors in global and in-house environment for large-scale software companies

Background Software process improvement (SPI) is an indispensable phenomenon in the evolution of a software development company that adopts global software development (GSD) or in-house development. Several software development companies do not only adhere to in-house development but also go for the GSD paradigm. Both development approaches are of paramount significance because of their respective advantages. Many studies have been conducted to find the SPI success factors in the case of companies that opt for in-house development. Still, less attention has been paid to the SPI success factors in the case of the GSD environment for large-scale software companies. Factors that contribute to the SPI success of small as well as medium-sized companies have been identified, but large-scale companies have still been overlooked. The research aims to identify the success factors of SPI for both development approaches (GSD and in-house) in the case of large-scale software companies. Methods Two systematic literature reviews have been performed. An industrial survey has been conducted to detect additional SPI success factors for both development environments. In the subsequent step, a comparison has been made to find similar SPI success factors in both development environments. Lastly, another industrial survey is conducted to compare the common SPI success factors of GSD and in-house software development, in the case of large-scale companies, to divulge which SPI success factor carries more value in which development environment. For this reason, parametric (Pearson correlation) and non-parametric (Kendall’s Tau correlation and the Spearman correlation) tests have been performed. Results The 17 common SPI factors have been identified. The pinpointed common success factors expedite and contribute to SPI in both environments in the case of large-scale companies.

A convolution-superposition fluence model for the Siemens HD120 multi leaf collimator with application to a 3D VMAT dose engine

Purpose. To construct a fast-calculating fluence modelfor the Siemens HD120 multi leaf collimator (MLC) using convolution-superposition techniques, and to develop a 3D VMAT dose engine using this fluence model. This work offers analternative to time-consuming open-source Monte Carlo simulations for thosedeveloping in-house dose-calculating software for research or clinical needs.Methods. EPID-acquired images of sweeping-window and sweeping-checker field profiles were used to commission transmission, 2 Dinterleaf leakage, and tongue-and-groove maps specific to the HD120 MLC. These maps, along with a 2D head-scattermodel were incorporated into a convolution-superposition algorithm to provide a fluence model for the HD120 MLC. This fluence model was used to develop a 3D VMAT dose engine, where 3D pre-computed 6MV dose kernels (EGSnrc) and a 3D fluence curvature-correction map were incorporatedto calculate 3D VMAT doses in a 22 cm diameter cylindrical phantom. Four VMAT patient plans witha large range of PTV sizes (36 cc to 604 cc) were chosen to test the fluence model and dose engine. Results. Excellent agreement was observed between the simulated commissioning fields and measured EPID-responses. 2D 2%/2 mm gamma analysis yielded a 98.9% pass rate for 1 cm, 2 cm, and 4 cm sweeping-window fields. 2D 2%/2mm gamma analysis for outer/inner MLC leaves yielded 89.1%/77.0% and 95.2%/91.1% pass rates from 1 cm and 2 cm sweeping-checker fields. Mean 3%/3 mm gamma analysis showed excellent agreement between our dose engine and Eclipse (Acuros) regardless of PTV size: 98.7% pass rate, with 95.1% pass rate in the high-dose volume. Fluence calculation times were13.6 seconds per dynamic MLC field and 1.4 minutes/arc for 3D VMAT dose on a standard PC. Conclusions. A fast-calculating convolution-superposition fluence model has been commissioned for the Siemens HD120 MLC and incorporatedinto a 3D VMAT dose engine. This work can be used to facilitate the development of fast in-house dose-calculating software.

Enabling synthesis in fragment-based drug discovery (FBDD): microscale high-throughput optimisation of the medicinal chemist's toolbox reactions.

Miniaturised high-throughput experimentation (HTE) is widely employed in industrial and academic laboratories for rapid reaction optimisation using material-limited, multifactorial reaction condition screening. In fragment-based drug discovery (FBDD), common toolbox reactions such as the Suzuki-Miyaura and Buchwald-Hartwig cross couplings can be hampered by the fragment's intrinsic heteroatom-rich pharmacophore which is required for ligand-protein binding. At Astex, we are using microscale HTE to speed up reaction optimisation and prevent target down-prioritisation. By identifying catalyst/base/solvent combinations which tolerate unprotected heteroatoms we can rapidly optimise key cross-couplings and expedite route design by avoiding superfluous protecting group manipulations. However, HTE requires extensive upfront training, and this modern automated synthesis technique largely differs to the way organic chemists are traditionally trained. To make HTE accessible to all our synthetic chemists we have developed a semi-automated workflow enabled by pre-made 96-well screening kits, rapid analytical methods and in-house software development, which is empowering chemists at Astex to run HTE screens independently with minimal training.

Large-Scale Agile Transformations for Software Quality Assurance: An Empirical Case Study from Pakistan

Software quality plays an important role in the easy and quick adoption of a software product by the end users. Agile methods have proven to play an effective role in ensuring software quality; however, the public sector is hesitant in its adoption. This study evaluates the adoption of agile methods in the public sector in-house software development and capitalization of potential benefits. A quantitative approach is used with 28 survey questionnaires based on budget, time, quick debugging and correction, maintenance, easy testing, and installation as software quality components to assess the employability of agile methods. The questionnaire was served to 216 information technology (IT) professionals (project managers: 6%, developers: 61%, quality assurance (QA) leads: 8%, and testers: 25%) from the public sector companies having experience in software development using agile and waterfall methods. The quality components and hypotheses are evaluated using the T-test and chi-square test, respectively, with a 95% confidence interval. The results highlight the benefits of using agile methodologies for software quality components in the public sector. Additionally, the findings demonstrate how agile software development approaches significantly affect the quality of software products and successful delivery within budget and deadline.

Inventory and Analysis of Environmental Sustainability Education in the Degrees of the University of Alcalá (Spain)

In order to promote education in environmental sustainability at higher education institutions and establish action priorities, a detailed analysis of the initial situation is needed, both in terms of courses offered and teaching and assessment strategies implemented. This article presents a methodology that can be used to standardize the evaluation of teaching in environmental sustainability at different universities. We exemplify its application at the University of Alcalá, located in Central Spain. The inventory was conducted using in-house software development for the extraction of environmental sustainability concepts in the degree courses’ syllabi, completed with a survey to faculty members and a manual review to confirm its adjustment to environmental issues. Those finally selected were analyzed in depth. The main results indicate that currently, only a small part of the courses (5.5%) offered at the University explicitly include environmental sustainability content. The grades that concentrate most of the courses are those of Environmental Sciences, Biology, Economics, Tourism and Pharmacy, with very low occurrence in the grades of Education and Health Sciences. It is concluded that further institutional commitment is needed in the definition of medium-term strategies to guide the training and dissemination efforts in order to promote sound environmental education in university courses.

Recommendations for IVDR compliant in-house software development in clinical practice: a how-to paper with three use cases.

The In Vitro Diagnostics Regulation (IVDR) will be effective in May 2022 by which in-house developed tests need to apply to the general safety and performance requirements defined in Annex I of the IVDR ruling. Yet, article 16 from Annex I about software can be hard to interpret and implement, particularly as laboratories are unfamiliar with quality standards for software development. In this paper we provide recommendations on organizational structure, standards to use, and documentation, for IVDR compliant in-house software development. A practical insight is offered into novel standard operating procedures using three examples: an Excel file with a formula to calculate the pharmacokinetics of tacrolimus and to calculate the new dose, a rule for automated diagnosis of acute kidney injury and a bioinformatics pipeline for DNA variant calling. We recommend multidisciplinary development teams supported by higher management, use of ISO-15189 in synergy with IEC-62304, and concise documentation that includes intended purpose, classification, requirement management, risk management, verification and validation, configuration management and references to clinical or performance evidence.

KTLO & Brownfield: Overcoming Challenges when Modernizing Process Automation and Business Intelligence

An estimated 50-80% of an organisation's IT budget is said to be spent on "keeping the lights on" (KTLO), with the remaining resources being often constrained to brownfield development in which legacy software systems define the boundaries to modernisation and innovation. Prominent business systems such as e.g., SAP ERP or SAP HANA fail to address all business needs, hence inhouse software development remains unavoidable. This paper gives an overview of the development and successful implementation of a scalable in-house data aggregation and data provisioning system built to enable rapid responses to emerging process digitalisation and business intelligence needs. The architectural implications and considerations are discussed.

The Impact of In-House Software Development Practices on System Usability in the Social Security Funds in Tanzania

In-house software development is a critical phenomenon for the production of efficient and effective software in generating requisite job output. A few studies have devoted efforts towards establishing the impact of in-house software development on software. Therefore, this paper is an effort towards establishing the impact of in-house software development practices on system usability. In pursuit of this paper, a sample of a sample size of 169, at 95% confidence level, with margin error of 5% was drawn from bold software users, i.e. 300 employees who used the all software including those dealing with the main stream activities. A total of 102 respondents actually responded to the questionnaires. The Online Sample Calculator was used to draw the sample. Quantitative data were collected using semi-structured questionnaires and processed using the SPSS. Descriptive statistics were applied in the analysis. Findings of the study indicate that software development practices, specifically usability test and user involvement in software designing and development had an impact on determining software usability for in-house software. The paper concludes that software development practices shape the design of the software; hence influence usability of the software produced. Recommended is therefore that software usability test and user involvement in software designing and development be promoted for effective software production.

In-House Software Development for Data Visualization of Random Motion Configuration of Particles in Fluid

This study aims to develop in-house software for data visualization program using Python programming language. Implement a simple algorithm and use the matplotlib library for 2D plotting. The results of development of this program were tested using a dataset from random motion simulation results of many particles modeled by two-dimensional circle shape and the diameter size as D. Data visualization in the form of particles configuration then confirmed with the particles configuration of the simulation results. Based on the test, it is found that the particles configuration results of the visualization are same as the configuration of the simulated particles. This shows that the data visualization program that has been developed can be used to process other data stored in a predetermined data format.

In-House Software Development for Data Visualization of Random Motion Configuration of Particles in Fluid

This study aims to develop in-house software for data visualization program using Python programming language. Implement a simple algorithm and use the matplotlib library for 2D plotting. The results of development of this program were tested using a dataset from random motion simulation results of many particles modeled by two-dimensional circle shape and the diameter size as D. Data visualization in the form of particles configuration then confirmed with the particles configuration of the simulation results. Based on the test, it is found that the particles configuration results of the visualization are same as the configuration of the simulated particles. This shows that the data visualization program that has been developed can be used to process other data stored in a predetermined data format.

A Safe and Practical Cycle for Team-Based Development and Implementation of In-House Clinical Software

PurposeDue to a gap in published guidance, we describe our robust cycle of in-house clinical software development and implementation, which has been used for years to facilitate the safe treatment of all patients in our clinics. Methods and MaterialsOur software development and implementation cycle requires clarity in communication, clearly defined roles, thorough commissioning, and regular feedback. Cycle phases include design requirements and use cases, development, physics evaluation testing, clinical evaluation testing, and full clinical release. Software requirements, release notes, test suites, and a commissioning report are created and independently reviewed before clinical use. Software deemed to be high-risk, such as those that are writable to a database, incorporate the use of a formal, team-based hazard analysis. Incident learning is used to both guide initial development and improvements as well as to monitor the safe use of the software. ResultsOur standard process builds in transparency and establishes high expectations in the development and use of custom software to support patient care. Since moving to a commercial planning system platform in 2013, we have applied our team-based software release process to 16 programs related to scripting in the treatment planning system for the clinic. ConclusionsThe principles and methodology described here can be implemented in a range of practice settings regardless of whether or not dedicated resources are available for software development. In addition to teamwork with defined roles, documentation, and use of incident learning, we strongly recommend having a written policy on the process, using phased testing, and incorporating independent oversight and approval before use for patient care. This rigorous process ensures continuous monitoring for and mitigatation of any high risk hazards.

Software development and innovation: Exploring the software shift in innovation in Swedish firms

A number of scholars and industry professionals have claimed that there has been a ‘software-biased shift’ in the nature and direction of innovation, in that software development is a core part of innovation activities in firms across a wide array of industries. Empirical firm-level evidence of such a shift is still scant. In this paper, we employ new and unique firm-level survey data on the frequency and nature of software development among firms in Sweden, matched with the Community Innovation Survey (CIS). We find robust evidence supporting a software bias in innovation, in that software development is associated with a higher likelihood of introducing innovations, as well as higher innovation sales among firms in both manufacturing and service industries. Furthermore, this positive relationship is stronger for firms that employ in-house software developers than for those that only use external developers, suggesting that there is a hierarchy but possibly also a complementarity between in-house and external software development. We also find support for complementarity between software-based technology and human capital; the estimated marginal effect of software development on innovation is particularly strong for firms that combine in-house software development with a highly educated workforce in both STEM and other disciplines.

The Effects of Turnover on Expert Effort Estimation

Turnover of the personnel represents a serious issue for management of software projects. The buildup of competences and phasing in of the people into the project requires both time and effort. This paper presents a case study of a large in-house agile software development project. The research goal was to determine the effects that turnover has on the expert effort estimation. In order to do this, paper examines relations across empirical data on a studied project. Study findings are the following: a) it is necessary to distinguish types of turnover, b) the general and planned turnover do not necessarily have a negative effect on estimation accuracy, and c) the unplanned turnover can have a significant negative impact on the reliability of the estimates and therefore should be treated with special attention. Results suggest that these facts should be taken into account both by the management and human resources.

Software Development and Innovation – Exploring the Software Shift in Innovation in Swedish Firms

Several scholars as well as industry professionals have claimed that there is a “softwarebiased shift” in the nature and direction of innovation in that software development is a core part of innovation activities in firms across a wide array of industries. Empirical firm-level evidence of such a shift is still scant. We employ new and unique firm-level survey data on the frequency and nature of software development among firms in Sweden, matched with the Community Innovation Survey (CIS). We find robust evidence supporting a software-bias in innovation in that software development is associated with a higher likelihood of introducing innovations as well as higher innovation sales among firms in both manufacturing and services industries. Furthermore, this positive relationship is stronger for firms employing in-house software developers than for those that only use external developers, suggesting that there is a hierarchy but possibly also a complementarity between internal and external software development. We also find support for complementarity between software-based technology and human capital; the estimated marginal effect of software development on innovation is particularly strong for firms that combine in-house software development with a highly educated workforce in STEM as well as in other disciplines.

Component attributes and their importance in decisions and component selection

Component-based software engineering is a common approach in the development and evolution of contemporary software systems. Different component sourcing options are available, such as: (1) Software developed internally (in-house), (2) Software developed outsourced, (3) Commercial off-the-shelf software, and (4) Open-Source Software. However, there is little available research on what attributes of a component are the most important ones when selecting new components. The objective of this study is to investigate what matters the most to industry practitioners when they decide to select a component. We conducted a cross-domain anonymous survey with industry practitioners involved in component selection. First, the practitioners selected the most important attributes from a list. Next, they prioritized their selection using the Hundred-Dollar ($100) test. We analyzed the results using compositional data analysis. The results of this exploratory analysis showed that cost was clearly considered to be the most important attribute for component selection. Other important attributes for the practitioners were: support of the component, longevity prediction, and level of off-the-shelf fit to product. Moreover, several practitioners still consider in-house software development to be the sole option when adding or replacing a component. On the other hand, there is a trend to complement it with other component sourcing options and, apart from cost, different attributes factor into their decision. Furthermore, in our analysis, nonparametric tests and biplots were used to further investigate the practitioners’ inherent characteristics. It seems that smaller and larger organizations have different views on what attributes are the most important, and the most surprising finding is their contrasting views on the cost attribute: larger organizations with mature products are considerably more cost aware.

Team wisdom in software development projects and its impact on project performance

While the concept of wisdom, which refers to how people make right use of their knowledge through their practical actions, judgments, and ethical decisions, in general attracts researcher interest in a variety of disciplines, such as philosophy, psychology and management studies, little is known about how wisdom is conceptualized and then operationalized in the software development project team context. Based on the frameworks for philosophical, group and organizational wisdom, this paper identifies software development project team wisdom as a process for how team members best use the stock and flow of their knowledge through collective judgment, virtue-ethics, emotions/feelings, and effective decision-making during their project-related efforts. Adapting the efforts and functional similarities of both group and organizational wisdom practices, this effort determines that wisdom-related mechanisms (e.g., team diversity, networking with other teams and people, and their past experiences), joint epistemic actions (e.g., team reasoning, intuition, and aesthetic capacity), and team virtue and prudence become the different faces of the software development team wisdom process. We then propose how these different faces interrelate and how they also relate to project process effectiveness, such as team learning and speed-to-users, both of which have been rarely addressed empirically in the context of software development project teamwork.By examining 210 in-house software development project teams in a field study and using structural equation modeling analysis, our results empirically show the following: (a) software development wisdom-related mechanisms positively relate to software development team prudence and virtue and their joint epistemic actions, (b) software development team prudence and virtue are positively associated with software development team joint epistemic actions, and further (d) software development team joint epistemic actions are positively associated with software development project process effectiveness. We conclude by discussing our findings as they relate to the wisdom framework of software development project teams and suggest the key managerial implications for different types of software development projects.

Comparative Analysis of Requirement Change Management Challenges Between in-House and Global Software Development: Findings of Literature and Industry Survey

Requirement changes are inevitable, and Requirement Change Management (RCM) is a complex process in software development. In-house software development and Global Software Development (GSD) are two widely used development approaches and there is a need to explore the RCM commonalities and differences in the two development approaches. The primary objective of this study is to identify the challenges that influence RCM in both approaches. First, we have implemented Systematic Literature Review (SLR) and identified 9 challenges that impact the general RCM process and 3 more challenges related to RCM with GSD. Second, we have conducted a questionnaire survey based on SLR results and collected feedback from 69 industry practitioners. The survey result indicates that there are four out of nine challenges, namely impact analysis, requirement traceability, requirement dependency, and system instability having the same impact in both in-house and GSD approaches. On the other hand, cost/time estimation, artifacts documents management, user involvement, requirement consistency, and requirement prioritization need more attention while implemented in GSD paradigm. Furthermore, regarding two important project management structures in GSD, centralized project structure and distributed project structure, the survey results reveal that all challenges have same impact except user involvement and change control board management, which are more important in centralized project structure. Lastly, the result from t-test indicates that both data sets retrieved from SLR and survey are close to each other. This study distinguishes RCM challenges in in-house and GSD approaches and in the context of two prominent project management structures followed in GSD projects. It would assist researchers by providing potential research directions and industry professionals to understand and implement RCM in different context more efficiently.

In-house Software Development: Considerations for Implementation

In-house Software Development: Considerations for Implementation