Throughout this thesis, we touched on some topics without going into details. Such topics include: SLA monitoring, real-time consistency checking, human-to-human interactions in software processes, mining software repositories and empirical eval-uations. Each of these topics can be investigated in-depth in separate studies. In this section, we highlight some potential future directions to complement the work presented in this thesis.
Tool support for the SDaaS architecture
Implementation of tool support is essential for the adoption of the SDaaS architecture.
The required tool support includes: tools for modelling and designing processes, full instantiation of the reference architecture supporting all types of process activities, and integration of more development tools. In addition, a tool discovery/catalogue service can be implemented to provide information about tools, guidance on how to use them and trade-offs between different tools.
Empirical studies
In this thesis, we evaluate the SDaaS architecture through a case study. While this validates the feasibility and applicability of the architecture, it does not evaluate the impact it would have on stakeholders (e.g., productivity and error rate) and projects (e.g., cost, quality and time). Therefore, an empirical study investigating those aspects is needed to analyse the impacts of using the SDaaS architecture in real software projects.
Another aspect that needs to be empirically studied is the usability and accessibility of the architecture and how it will impact collaboration between (and across) teams.
On demand Micro-Tools
Chapter 6: Conclusions
As Clark predicted in 1999 1, the world is becoming a network of services. Multiple development tools and environments already offer integration with other tools and platforms. In this thesis, we focus on modelling software processes as workflows and executing them in the cloud. The workflow building blocks (the activities) are either built-in beforehand or custom-made for a specific purpose. We demonstrated the creation of new activities in the case study presented in Chapter 5. Similarly, we believe tools could be built from aggregating Micro-Tools in a workflow which can then be executed in the cloud. Such Micro-Tools can be offered on demand and on a pay-as-you-go basis. This might even lead to a pay-per-feature-use model where you custom build your tool by choosing compatible Micro-Tools supporting a set of required features. We envision the granularity of Micro-Tools to be of atomic features (e.g., save a file, compile code, etc.) and that a Micro-Tools discovery/catalogue service can help choose the right Micro-Tools for building your custom tool.
Interaction patterns
As mentioned in Chapter 1, the increasing mobility of the Post-PC era has influenced the type of devices that are in use. Low specification, lightweight, mobile devices are becoming essential part in our everyday life. Projects such as TouchDevelop [21]
exploit such devices for software development. New software development interaction patterns should build on the capacities of mobile devices (e.g., voice recognition and touch screens). Another aspect of interaction which can be studied is how stakeholders interact with workflow activities and among themselves (offline).
Big data for software development
In the SDaaS architecture, the processes are modelled, the artefacts are maintained (with different versions), stakeholders actions are recorded and provenance data about the process execution is collected. This data can be used for real-time and historical analysis. Such data can be utilised for the components of the architecture (see Figure 2.3) that we did not explore in depth in this thesis. These areas are: SLA monitoring when two or more organisations are collaborating, and consistency checking, to raise an alarm when processes divert from certain standard processes or constraints.
1 http://www.nytimes.com/1999/04/18/business/economic-view-is-mr-gates-pouring-fuel-on-his-rivals-fire.html
6.2.1 Motivating Scenarios
In this subsection, we briefly describe two scenarios which show the impact of the SDaaS architecture and the potential of the future work directions suggested in the previous section.
6.2.1.1 Continuous delivery
Continuous Delivery [70] has become a trendy software development paradigm. It aims at automating the build-test-deploy-release cycle. The motivation is to achieve frequent releases, reduce conflicts and therefore, reduce cost. To achieve such automation, teams should follow certain practises and use supporting tools/platforms. Humble and Farley [70] set the principles and technical practises for successful implementation of Continuous Delivery. An example of a continuous delivery process is the Facebook deployment pipeline [49].
Discussion
Systems like Facebook are delivered through the Internet where changes and new features are continuously pushed to users transparently. Faster and frequent releases (as prescribed in Continuous Delivery) mean that developers will be committing and releasing code very often (sometimes on daily basis). The benefits of such frequency are evident. Small and frequent releases mean easier bug locating and fixing as bugs will be in the newly added code which is small in size [70]. In addition, the code base is always maintained to be bug-free after each release which leads to reducing the required integration effort. Automation and repeatability of the software build-test-deployment-release are a key enabling factor for Continuous Delivery [70]. To pick up the fruits of Continuous Delivery, the management aspect of the development process must be considered. For example, if developers do not commit their code regularly, the Continuous Delivery chain is broken. Therefore, there is a need for convergence and monitoring support to ensure certain processes and practises are followed. SDaaS uses process models which can prescribe the recommended practice. Provenance data and consistency checking can ensure the required convergence. The cloud infrastructure provides the required tools on demand and also supports the automation of parts of the process.
Chapter 6: Conclusions
6.2.1.2 Compliance and continuous certification
Small connected devices are being embedded everywhere from the human body to civil infrastructure and military applications. This means that more and more soft-ware systems are becoming safety-critical. Safety-critical systems must comply with certain regulatory standards and be certified by relevant authorities (as we discussed in Chapter 5).
Discussion
Many software components need to comply with certain domain-specific standards and regulations. This raises two important requirements for developing such compo-nents. First, the development team(s) must ensure their compliance with the adopted standard. Second, the development team must collect and retain evidence that they did so in order to build their case for certification. As Fuggetta and Di Nitto [53] state, the software community is challenged with the need to move from rigid compliance to smart convergence. This is especially important since in a human-centric process (like software development) it is impossible to force rigid processes and patterns. Im-plementing the SDaaS consistency checking component and defining consistency rules can help achieving such smart convergence with the help of the SDaaS provenance data and process models.