Over the last years, the concept of API economy has fostered the creation of an ecosystem of public APIs used as business elements. These APIs include various pricing plans, which allow developers to consume an API for a specific price and under certain conditions. These conditions include capacity limits, a.k.a. limitations, that limit the usage of the API. Additionally, modern web applications are usually based on a microservices architecture (MSA), in which multiple services communicate with each other through public APIs using a standardized paradigm, commonly RESTful. When an MSA consumes external APIs with limitations, it is necessary to analyse the impact of these limitations in its capacity. These MSAs are known as Limitation-Aware Microservices Architecture (LAMA). This PhD dissertation aims to provide an automated framework to analyse the capacity of a LAMA given the formal description of its internal topology and the external pricing plans. This framework would be used to solve analysis operations, which deal with the extraction of useful information that helps developers build their LAMAs.

Automated capacity analysis of limitation-aware microservices architectures

Software project data holds knowledge of the development process enacted in teams. However, it is rarely used for process improvement approaches as part of agile retrospective meetings. We argue that this integration shows promise: Project data is evidence of what occurred in the last development iteration(s). It complements the perceptions of individuals that are usually exclusively relied upon in retrospectives. In this paper, we present the results of semi-structured interviews with agile practitioners, which revealed missing knowledge of the capabilities, implementation, and application of project data analyses as a key reason for the lack of usage. Looking forward, we provide an initial look at a structured approach to the usage of software project data in agile retrospectives.

Student Research Abstract: Why and Where Software Developers are (not) using Project Data in Agile Retrospectives

Teaming is a key aspect of most professional software engineering positions, and consequently, team-based learning (TBL) features heavily in many undergraduate computer science (CS) and software engineering programs. However, while TBL offers many pedagogical benefits, it is not without challenges. One such challenge is assessment, as the course teaching staff must be able to accurately identify individual students’ contributions to both encourage and reward participation. In this paper, we study improvements to grading practises in the context of a CS1.5 introductory software engineering course, where assessing individual students’ contributions to weekly lab assignments is done manually by teaching assistants (TAs). We explore the impact of presenting TAs with automated summaries of individual student contributions to their team’s GitHub repository. To do so, we propose a novel algorithm, and implement a tool based off of it, AutoVCS. We measure the impact on grading metrics in terms of grading speed, grading consistency, and TA satisfaction. We evaluate our algorithm, as implemented in AutoVCS, in a controlled experimental study on Java-based lab assignments from a recent offering of NC State University’s CS1.5 course. We find our automated summaries help TAs grade more consistently and provides students with more actionable feedback. Although TAs grade no faster using automated summaries, they nonetheless strongly prefer grading with the support of them than without. We conclude with recommendations for future work to explore improving consistency in contribution grading for student software engineering teams.

Improving Grading Outcomes in Software Engineering Projects Through Automated Contributions Summaries

Agile software teams are expected to follow a number of specific Team Practices (TPs) during each iteration, such as estimating the effort ("points") required to complete user stories and coordinating the management of the codebase with the delivery of features. For software engineering instructors trying to teach such TPs to student teams, manually auditing teams if teams are following the TPs and improving over time is tedious, time-consuming and error-prone. It is even more difficult when those TPs involve two or more tools. For example, starting work on a feature in a project-management tool such as Pivotal Tracker should usually be followed relatively quickly by the creation of a feature branch on GitHub. Merging a feature branch on GitHub should usually be followed relatively quickly by deploying the new feature to a staging server for customer feedback. Few systems are designed specifically to audit such TPs, and existing ones, as far as we know, are limited to a single specific tool. We present Bluejay, an open-source extensible platform that uses the APIs of multiple tools to collect raw data, synthesize it into TP measurements, and present dashboards to audit the TPs. A key insight in Bluejay's design is that TPs can be expressed in terminology similar to that used for modeling and auditing Service Level Agreement (SLA) compliance. Bluejay therefore builds on mature tools used in that ecosystem and adapts them for describing, auditing, and reporting on TPs. Bluejay currently consumes data from five different widely-used development tools, and can be customized by connecting it to any service with a REST API. Video showcase available at governify.io/showcase/bluejay

Bluejay: A Cross-Tooling Audit Framework For Agile Software Teams

Agile software teams are expected to follow a number of specific Team Practices (TPs) during each iteration, such as estimating the effort ("points") required to complete user stories and coordinating the management of the codebase with the delivery of features. For software engineering instructors trying to teach such TPs to student teams, manually auditing teams if teams are following the TPs and improving over time is tedious, time-consuming and error-prone. It is even more difficult when those TPs involve two or more tools. For example, starting work on a feature in a project-management tool such as Pivotal Tracker should usually be followed relatively quickly by the creation of a feature branch on GitHub. Merging a feature branch on GitHub should usually be followed relatively quickly by deploying the new feature to a staging server for customer feedback. Few systems are designed specifically to audit such TPs, and existing ones, as far as we know, are limited to a single specific tool. 
We present Bluejay, an open-source extensible platform that uses the APIs of multiple tools to collect raw data, synthesize it into TP measurements, and present dashboards to audit the TPs. A key insight in Bluejay's design is that TPs can be expressed in terminology similar to that used for modeling and auditing Service Level Agreement (SLA) compliance. Bluejay therefore builds on mature tools used in that ecosystem and adapts them for describing, auditing, and reporting on TPs. Bluejay currently consumes data from five different widely-used development tools, and can be customized by connecting it to any service with a REST API. Video showcase available at this http URL

Cesar Garcia

Papers

Bluejay: A Cross-Tooling Audit Framework For Agile Software Teams

Bluejay: A Cross-Tooling Audit Framework For Agile Software Teams