Delirium is an acute neuropsychiatric syndrome characterized by altered levels of attention and awareness with cognitive deficits. It is most prevalent in elderly hospitalized patients and related to poor outcomes. Predisposing risk factors, such as older age, determine the baseline vulnerability for delirium, while precipitating factors, such as use of sedatives, trigger the syndrome. Risk factors are heterogeneous and the underlying biological mechanisms leading to vulnerability for delirium are poorly understood. We tested the hypothesis that delirium and its risk factors are associated with consistent brain network changes. We performed a systematic review and qualitative meta-analysis and included 126 brain network publications on delirium and its risk factors. Findings were evaluated after an assessment of methodological quality, providing N=99 studies of good or excellent quality on predisposing risk factors, N=10 on precipitation risk factors and N=7 on delirium. Delirium was consistently associated with functional network disruptions, including lower EEG connectivity strength and decreased fMRI network integration. Risk factors for delirium were associated with lower structural connectivity strength and less efficient structural network organization. Decreased connectivity strength and efficiency appear to characterize structural brain networks of patients at risk for delirium, possibly impairing the functional network, while functional network disintegration seems to be a final common pathway for the syndrome.

Automated testing is an essential component of Continuous Integration (CI) and Delivery (CD), such as scheduling automated test sessions on overnight builds. That allows stakeholders to execute entire test suites and achieve exhaustive test coverage, since running all tests is often infeasible during work hours, i.e., in parallel to development activities. On the other hand, developers also need test feedback from CI servers when pushing changes, even if not all test cases are executed. In this paper we evaluate similarity-based test case selection (SBTCS) on integration-level tests executed on continuous integration pipelines of two companies. We select test cases that maximise diversity of test coverage and reduce feedback time to developers. Our results confirm existing evidence that SBTCS is a strong candidate for test optimisation, by reducing feedback time (up to 92% faster in our case studies) while achieving full test coverage using only information from test artefacts themselves.

No abstract

Several operations, ranging from regular code updates to compiling, building, testing, and distribution to customers, are consolidated in continuous integration and delivery. Professionals seek additional information to complete the mission at hand during these tasks. Developers who devote a large amount of time and effort to finding such information may become distracted from their work. We will better understand the processes, procedures, and resources used to deliver a quality product on time by defining the types of information that software professionals seek. A deeper understanding of software practitioners' information needs has many advantages, including remaining competitive, growing knowledge of issues that can stymie a timely update, and creating a visualisation tool to assist practitioners in addressing their information needs. This is an extension of a previous work done by the authors. The authors conducted a multiple-case holistic study with six different companies (38 unique participants) to identify information needs in continuous integration and delivery. This study attempts to capture the importance, frequency, required effort (e.g. sequence of actions required to collect information), current approach to handling, and associated stakeholders with respect to identified needs. 27 information needs associated with different stakeholders (i.e. developers, testers, project managers, release team, and compliance authority) were identified. The identified needs were categorised as testing, code & commit, confidence, bug, and artefacts. Apart from identifying information needs, practitioners face several challenges in developing visualisation tools. Thus, 8 challenges that were faced by the practitioners to develop/maintain visualisation tools for the software team were identified. The recommendations from practitioners who are experts in developing, maintaining, and providing visualisation services to the software team were listed.This is an open access article under the terms of the Creative Commons Attribution-NonCommercial License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited and is not used for commercial purposes.

Identifying the root causes of test flakiness is one of the challenges faced by practitioners during software testing. In other words, the testing of the software is hampered by test flakiness. Since the research about test flakiness in large-scale software engineering is scarce, the need for an empirical case-study where we can build a common and grounded understanding of the problem as well as relevant remedies that can later be evaluated in a large-scale context is a necessity. This study reports the findings from a multiple-case study. The authors conducted an online survey to investigate and catalogue the root causes of test flakiness and mitigation strategies. We attempted to understand how practitioners perceive test flakiness in closed-source development, such as how they define test flakiness and what practitioners perceive can affect test flakiness. The perceptions of practitioners were compared with the available literature. We investigated whether practitioners' perceptions are reflected in the test artefacts such as what is the relationship between the perceived factors and properties of test artefacts. This study reported 19 factors that are perceived by professionals to affect test flakiness. These perceived factors are categorized as test code, system under test, CI/test infrastructure, and organization-related. The authors concluded that some of the perceived factors in test flakiness in closed-source development are directly related to non-determinism, whereas other perceived factors concern different aspects, for example, lack of good properties of a test case, deviations from the established processes, and ad hoc decisions. Given a data set from investigated cases, the authors concluded that two of the perceived factors (i.e., test case size and test case simplicity) have a strong effect on test flakiness.flaky tests, non-deterministic tests, practitioners' perceptions, software testing, test smells | INTRODUCTIONRegression testing, automatic or manual, is intended to ensure that changes made in any part of the system do not break existing functionality. Developers submit code changes with the expectation that test failures will be associated with the code modifications. Unfortunately, rather than being the result of changes to the code, some test failures occur due to flaky tests. In the literature, the most common definition of a flaky test is: a test that exhibits both passing and failing outcomes when no changes are introduced into the code base [1]. King et al. extend this definition [2]: "flaky tests exhibit both passing and failing results when neither the code nor test has changed". Flaky tests are defined as "unreliable tests whose outcome is not deterministic."

BackgroundDuring the second wave of the COVID-19 pandemic in India, the Ministry of Ayush conducted a community study to provide therapeutic care to patients with asymptomatic, mild, and moderate COVID-19 in home isolation based on the empirical evidence generated on the efficacy of AYUSH-64 in COVID-19.ObjectiveTo document disease characteristics, care-seeking behavior, and outcomes in patients with asymptomatic, mild, or moderate COVID-19 in home isolation who used AYUSH-64 for COVID-19.MethodsCross-sectional analysis of the data generated through a community study conducted in India from 08 May to 31 August 2021 was performed to study the disease characteristics, care-seeking behavior during home isolation, clinical outcomes, adverse events, and the association between various risk factors and clinical recovery during the study period. The data were collected through semi-structured questionnaires, available in electronic data collection format at the baseline, 7, 14, and 21 days. A logistic regression was performed to explore the relationship between relevant variables and clinical recovery.ResultsData from 64,642 participants were analyzed for baseline assessment, and final analysis was done for 49,770 participants. The mean age of the enrolled participants was 38.8 ± 11.7 years, and 8.4% had co-morbidities. AYUSH-64 was utilized as an add-on to the standard care by 58.3% of participants. Comparable clinical outcomes were observed in participants utilizing AYUSH-64 either as a standalone or as an add-on to standard care, in terms of clinical recovery, disease progression, the requirement for oxygen supplementation, hospitalization, ICU admission, and need for ventilator support. Younger age, having no co-morbidities or substance abuse, and having been vaccinated were associated with early clinical recovery than those who were older and not vaccinated.ConclusionsThe study findings suggest that AYUSH-64 use, either standalone or as an adjunct to standard care, in asymptomatic, mild, or moderate COVID-19 is associated with good clinical outcomes. Ayush services and interventions can be effectively integrated into the mainstream public health architecture to serve public health goals.

No abstract

Requirements engineering activities act as a backbone of software development. The more efforts devoted during requirements engineering activities guarantee a better software product. Appropriate selection of requirements has been a challenge for software industry. This selection will increase the probability of success of the software product. Each year many cases are registered against companies for not fulfilling product requirements appropriately. The product failure mostly depends on, either by missing important requirements or capturing irrelevant requirements. SDLC consists of stages where software starts from scratch to a refined product. Requirements Development Life cycle (RDLC) consists of stages where requirements gets initiated, raised, refined, forcefully changed, implemented and validated. The processes to capture requirements vary industry to industry. This paper presents several requirements engineering processes used during the development of requirements, in industry. These processes will identify appropriate requirements and develop a quality product within budget on time. These practices are captured within the Pakistan software industry. This paper also explains the motivations for selecting particular methods, within company, during requirements development and the results associated with it. The processes captured in this paper, from different companies, can be an education for software industry.