Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Yan Lucas

dblp:133/6863 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
0since 2021 · last 2014
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Artificial intelligence and machine learning · 1Software engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Empirical software engineering · 100%

Topics — the 1 heaviest of 2, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering › collaborative software development
inner source
0.212014
Key factors for adopting inner source · ACM Trans. Softw. Eng. Methodol. 2014

Methods — techniques the papers use, named apart from their topics

framework · 0.2case study · 0.2
YearPublicationVenuePosition
2014 Key factors for adopting inner source
abstract
A number of organizations have adopted Open Source Software (OSS) development practices to support or augment their software development processes, a phenomenon frequently referred to as Inner Source . However the adoption of Inner Source is not a straightforward issue. Many organizations are struggling with the question of whether Inner Source is an appropriate approach to software development for them in the first place. This article presents a framework derived from the literature on Inner Source, which identifies nine important factors that need to be considered when implementing Inner Source. The framework can be used as a probing instrument to assess an organization on these nine factors so as to gain an understanding of whether or not Inner Source is suitable. We applied the framework in three case studies at Philips Healthcare, Neopost Technologies, and Rolls-Royce, which are all large organizations that have either adopted Inner Source or were planning to do so. Based on the results presented in this article, we outline directions for future research.
Klaas-Jan Stol, Paris Avgeriou, Muhammad Ali Babar 0001, Yan Lucas, Brian Fitzgerald 0001
ACM Trans. Softw. Eng. Methodol.4
2013 Reusing knowledge in embedded systems modelling
abstract
Abstract Model‐based design is a promising technique to improve the quality of software and the efficiency of the software development process. We are investigating how to efficiently model embedded software and its environment to verify the requirements for the system controlled by the software. The software environment consists of mechanical, electrical and other parts; modelling it involves learning how these parts work, deciding what is relevant to model and how to model it. It is not possible to fully automate these steps. There are general guidelines, but given that every modelling problem differs, much is left to the modeller's own preference, background and experience. Still, when the next generation of a system is designed, the new system will have common elements with its previous version. Therefore, lessons learned from the current model could inform future models. We propose a framework for identifying the non‐formal elements of knowledge, insights and a model itself, which can support modelling of the next system generation. We will present the application of our framework on an action research case – modelling mechanical parts of a paper‐inserting machine.
Jelena Marincic, Angelika Mader, Roel J. Wieringa, Yan Lucas
Expert Syst. J. Knowl. Eng.4