Reasons for Discontinuing Active Surveillance : Assessment of 21 Centres in 12 Countries in the Movember GAP3 Consortium

Background: Careful assessment of the reasons for discontinuation of active surveillance (AS) is required for men with prostate cancer (PCa). Objective: Using Movember's Global Action Plan Prostate Cancer Active Surveillance initiative (GAP3) database, we report on reasons for AS discontinuation. Design, setting, and participants: We compared data from 10 296 men on AS from 21 centres across 12 countries. Outcome measurements and statistical analysis: Cumulative incidence methods were used to estimate the cumulative incidence rates of AS discontinuation. Results and limitations: During 5-yr follow-up, 27.5% (95% confidence interval [CI]: 26.4-28.6%) men showed signs of disease progression, 12.8% (95% CI: 12.0-13.6%) converted to active treatment without evidence of progression, 1.7% (95% CI: 1.5-2.0%) continued to watchful waiting, and 1.7% (95% CI: 1.4-2.1%) died from other causes. Of the 7049 men who remained on AS, 2339 had follow-up for >5 yr, 4561 had follow-up for Conclusions: Our descriptive analyses of current AS practices worldwide showed that 43.6% of men drop out of AS during 5-yr follow-up, mainly due to signs of disease progression. Improvements in selection tools for AS are thus needed to correctly allocate men with PCa to AS, which will also reduce discontinuation due to conversion to active treatment without evidence of disease progression. Patient summary: Our assessment of a worldwide database of men with prostate cancer (PCa) on active surveillance (AS) shows that 43.6% drop out of AS within 5 yr, mainly due to signs of disease progression. Better tools are needed to select and monitor men with PCa as part of AS. (C) 2018 European Association of Urology. Published by Elsevier B.V. All rights reserved.Peer reviewe

Generalizing a Model of Software Architecture Design from Five Industrial Approaches

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the 5 approaches have a lot in common and match more or less the “ideal” pattern we introduced

Activities and costs of re-engineering cloned variants into an integrated platform

Many software systems need to exist in multiple variants. Organizations typically develop variants using clone & own-copying and adapting systems towards new requirements. However, while clone & own is a simple and readily available strategy, it does not scale with the number of variants, and then requires a costly re-engineering of the cloned variants into a configurable software platform (a.k.a., software product line). Ideally, organizations could rely on decision models or at least on substantial empirical data to assess the costs and benefits of such a re-engineering. Unfortunately, despite decades of research on product lines and platforms, such data is scarce, not least because obtaining it from industrial re-engineering efforts is challenging. We address this gap with a study on re-engineering two cases of cloned variants of open-source Android and Java games. Student developers re-engineered the clones into software product lines, logging their activities and costs. They performed the types of activities typically associated with re-engineering, but the activities were intertwined and done iteratively. The costs were relatively similar among both cases, but the used variability mechanism had a substantial impact. Interestingly, beyond a common diffing tool, no dedicated re-engineering tool was particularly useful. We hope that our results support researchers working on re-engineering techniques and decision models, as well as practitioners trying to assess the costs and activities involved in re-engineering a software platform

H.: Software product family evaluation

Abstract. This paper proposes a four-dimensional evaluation framework for software product family engineering. The four dimensions relate to the software engineering concerns of business, architecture, organisation, and process. The evaluation framework is intended for use within software developing organisations to determine the status of their own software product family engineering and the priorities for improving. The results of the evaluation can be used for benchmarking, roadmapping, and developing improvement plans. An initial evaluation of a real industrial case is presented to show the validity of the framework

Generalizing a model of software architecture design from five industrial approaches. In:

Abstract We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the five approaches have a lot in common and match more or less the ''ideal'' pattern we introduced. From the ideal pattern we derive an evaluation grid that can be used for further method comparisons

Preface

anniversary in the year 2000. The workshop will be held in conjunction with ICS

Software Product Family Evaluation

Abstract. This paper proposes a 4-dimensional software product family engineering evaluation framework. The four dimensions relate to the software engineering concerns of business, architecture, organisation and process. The evaluation framework is intended for use within software developing organisations to determine the status of their own software product family engineering and the priorities for improving. The results of the evaluation can be used for benchmarking, road mapping and developing improvement plans. An initial evaluation of a real industrial case is presented to show the validity of the framework