Email:
Releasing a software product often is seen as the end point of the software development process: everything's implemented, time to earn some cash! Of course, quite the opposite is true, since 40 to 80% of software development costs are spent during software maintenance activities after release, i.e., to fix bugs, improve the user experience and add new functionality.
MCIS' mission is to help practitioners maintain their software systems. For example, which files should be tested or fixed first and by who? Which bug to fix first? Did the performance of our system degrade compared to the previous release? How can we improve the energy consumption of our system? Will this change have nasty consequences on other features?
By empirical research on software development process data stored in revision control systems (CVS, Subversion, Git, ...), mailing list archives, bug repositories (Bugzilla, Jira, ...), online documentation and manuals, MCIS tries to address the above questions, and many more! Typically, the outcome of our research are models developed using data mining, statistical analysis and manual analysis.
OK, so everyone is familiar with pre-release development activities like requirements gathering, analysis, design and implementation, and also (thanks to the above explanation) with post-release maintenance. However, what happens in between these activities, i.e., how does one actually make a release? How does one turn textual source code into an installable software product, ready to execute on the user's hardware platform?
MCIS' mission is to help practitioners release their products faster, but without sacrificing quality. To achieve this, one first needs insight into the release engineering process. For example, what is the health status of the build system (i.e., the infrastructure that co-ordinates compilers and configurators to transform source code into executables)? Does it become harder to modify over time? How are implementation changes by different development teams integrated and tested towards inclusion in the next release? How can we prepare our development process and software system for continuous delivery, i.e., instantaneously releasing new features or bug fixes to customers?
Using the same techniques as for software maintenance, we try to address the questions above. In addition, our lab has unique expertise and data sets on release engineering and software construction, and contacts with industry for access to "real-life" data.
Since (1) software maintenance activities need to be performed until very long after the release of a system, and (2) software construction is a less well-known area, both in practice and research, practitioners typically lack significant knowledge about and experience with the software system they are trying to maintain or construct. The original developers usually are no longer available, there is no documentation, yet there is a tight deadline to work against. So, what should practitioners do?
MCIS' mission is to help practitioners understand their software systems and construction infrastructure to facilitate maintenance, construction and other development activities. For example, how does the concrete architecture or design of this software component look like? What features and functionality has the development team been working on this week? Which open source contributors have been active the most, and which ones have delivered the best work? How does our release engineering infrastructure work?
Intelligence is a vague concept covering elements from reverse engineering, visualization, data mining, statistical analysis, chimps and (of course!) human reasoning. Given that knowledge is crucial in software development, software intelligence forms the heart of MCIS' research activities.
FERREIRA, I., CHENG, J. and ADAMS, B. (2021). The “Shut the f**k up” Phenomenon: Characterizing Incivility in Open Source Code Review Discussions, in Proceedings of the 24th ACM Conference on Computer-Supported Cooperative Work and Social Computing, CSCW (virtual), to appear. BibTeX
FOUNDJEM, A., EGHAN, E.E. and ADAMS, B. (2021). Onboarding vs. Diversity, Productivity and Quality -- Empirical Study of the OpenStack Ecosystem, in Proceedings of the 43rd International Conference on Software Engineering, ICSE (Madrid, Spain), to appear. (Acceptance ratio: 138/602=22.92%) BibTeX
BARRAK, A., EGHAN, E., ADAMS, B., and KHOMH, F. (2021). Why do Builds Fail? - A Conceptual Replication Study, Journal of Software and Systems (JSS), Elsevier, to appear. BibTeX
BARRAK, A., EGHAN, E.E. and ADAMS, B. (2021). On the Co-evolution of ML Pipelines and Source Code - Empirical Study of DVC Projects, in Proceedings of the 28th IEEE International Conference on Software Analysis, Evolution, and Reengineering, SANER (Hawaii, USA), to appear. (Acceptance ratio: 42/165=25%) BibTeX