INTRODUCTION:
This report outlines the problem statement, background study, existing as well as prospective solutions, software engineering practices that the team followed, important architectural decisions and some of the implementation challenges that our team faced during the course of this project.
Our team had comprehended the knowledge gained through this ‘MSc Software Engineering’ programme and followed the various aspects of software engineering discipline throughout the course of this project to build a high quality software product. We adhered to scrum project management and standard software engineering practices while working on this project.
Internet of Things:
“The Internet may already be huge, but it’s about to get a lot bigger.” (Intel Corporation
2011)
The internet has grown rapidly above all our expectations and has been evolving ever since it began as ARPANET in 1969 (Abbate 1994). Intel Corporation (2011) suggests that today internet has around 15 billion devices connected to it and estimates show that it is expected to have 31 billion devices by 2020. Internet of Things is a new evolution of the Internet and underpinning its development is the ever increasing proliferation of networked ‘smart’ objects to the Internet.
Challenges of Internet of Things:
Although IOT promises new business models, and reduce cost and risk; a lot of technical challenges have to be solved in realising that dream.
Related Work and Existing Systems:
As it was discussed in the previous section, in order to understand the difficulties of IoT in real world scenarios, we studied some of the existing systems that provide IoT based services. We tried to learn from these systems and designed our system in such a way to complement the existing systems and also tried to address some of the outstanding issues with these systems. For this purpose, we have chosen three different systems to discuss in this section, which provide different kind of IoT Services.
PROJECT REQUIREMENTS
Project Initiation:
Project in itiation is the initial and an important step in a project’s lifecycle.
It was conducted during the sprint 0 to define the project’s vision and to study about
the project’s viability. This section discusses the different activities performed during
project initiation.
Project Stakeholders.
Hardware and Software developers are the main users of the system:
Hardware Developers: They use the Gadgeteer library to speed up their prototyping process for Gadgeteer platform. For other hardware platforms they can use the API directly to log data to the cloud.
Software Developers: They use the API to retrieve the data generated from devices to create applications.
Requirements Elicitation:
General Requirements
- An abstract API should be created which can work with devices from different hardware manufacturers
- Users’ privacy of data should be considered.
- The API should not only transmit raw data. But, it should perform some processing on the data
- A lightweight Gadgeteer library should be created to help the hardware developers with their implementation.
- Provide data visualisation by using third-party libraries.
- Provide a continuous stream of data by buffering the data locally when there is no internet connection.
- Use Cases
- Use Case 1: High school students in a biology class logging temperature
and humidity. - Use Case 2: Specified by Dr Dean Mohamedally (using Gadgeteer)
- Use Case 3: SDK Example use case of swapping to another prototyping platform (Engduino).
ARCHITECTURE AND DESIGN
Architecture Overview:
Having done Advanced Analysis and Design as a core course in our master degree the team has developed a deep understanding regarding the importance and the benefits of having extensible and robust software architecture.
Architecture and design decisions form an important aspect of any product development since they affect the success and acceptance of the end product. In this section we describe the architecture of our solution and discuss some of the important architectural decisions that have been taken and the reasons for making those decisions in order to address the challenges.
Enterprise Architecture View.
IMPLEMENTATION AND TESTING
Brief Description of Components:
In this section, we will discuss about the key components of our system. Since this project is split into different decoupled layers, it is necessary to focus on all of the layers and the components it consists of. The three important layers of this project include the website, web service and the Gadgeteer library.
Use Case Scenarios:
Common Walkthrough
Having briefly described the main components of the system in the above section, we would like to present a walkthrough of how these components are interacting with each other. To utilise the offered services, developers need to first login as valid users at the web site. Once logged in, at the device management page, developers can perform different actions such as addition, updating and deletion.
Walkthrough of the User Registration and Device Addition.
Software Measurement:
Because of our intention to develop software with high quality in terms of reusability and maintainability, along with implementation, we have been measuring the existing code to gain an insight into the current state of the project. Among various code metrics, according to the user guide (Microsoft Developer Network, 2012) focusing on the code metric tool embedded in VS 2012.
Testing Overview:
Strategy
Every project should have a proper test strategy outlining about how and which artefacts will be tested along with test criteria and attributes. Since we followed Scrum project management methodology, all our testing efforts were aligned with values of agile manifesto. In Sprint 0, we laid out a master plan about how testing activities has to be carried out and the work flow to be followed.
White Box Testing:
Unit Testing
All path testing with k=1 has been used as the main approach to perform unit testing for data access layer. As it was described by Schligloffm and Roggenbach (2007), this type of testing is a white box structural testing that aims to find all the possible executable pathswithin the code.
Integration Testing
Integration testing is usually done by combining individual modules; test cases are executed on the integrated module. Although integration testing is generally black box, we have performed a white box testing to obtain code coverage.
Black Box Testing:
System and Functional Testing
It is obvious that our API could be invoked by any third-party application. Due to this fact, a functional testing which is classified as a black -box testing was the only option available to exercise our APIs in a third -party application. Our system, apart from the API also consists of a website which contains components that can be seen as implementation of the a fore mentioned third -party applications. Therefore, the website has been tested using automated tests through the user interface (UI) also known as Code d UI Tests by taking into consideration the acceptance criteria for all the user stories.
FURTHER WORK
Having in mind the time allocated to this project, undoubtedly there are improvements that can be considered in extending and enhancing its functionalities. As an immediate work, this project will be used by the next academic year students under Dean Mohamendally’s supervision.
In general, the idea is to create a hierarchy of hardware devices and manage them through the Gadgeteer API along with the implementation of some business use cases With regards to long term improvements we have considered ideas such as including Machine Learning models in our APIs to enable data prediction and creating libraries for other hardware platforms especially for Arduino which is popular and more mature. The former could be used to keep the models learning about the gathered data through the API .
By harnessing the knowledge gained from the models the device discovery feature could be enhanced by predicting the future data . The latter idea can speed up the development process for other platforms as the Gadgeteer library does. By doing so, it adds extra value to the project and establishes Gadgeteer IoT API as a universal platform that can be integrated with any hardware device platform.
CONCLUSION
Gadgeteer Internet of Things API is the result of 3-month pains taking work by four bright
software engineers, proved to be useful in different areas such as education and safer neighbourhoods. Microsoft Research can publish it in their website and integrate it with their existing systems.
Within the time and budget constraint, the team has managed to meet all the requirements proposed by the stakeholders, achieve great client satisfaction and deliver a completely – working system which will be extended by the students from UCL in the following years . Every team member has fully participated in the development with great passion and equally contributed to the outcome of this project.
Given this opportunity, by strictly following the discipline of software engineering, team members have been able to critically assess and actually apply what they have learnt through the master programme, from development techniques to project management methodologies, from requirements engineering and advanced design to implementation and testing. Considering that the majority of the team had not implemented API – based systems in .NET, we have enhanced the skills and gained rich experience from this project. More importantly, we have the chances to attend workshops and access to cutting – edge technologies , such as Internet of Things, Windows Azure and MongoDB, which has considerably broadened our vision and kept us in pace with the current technology trends.
Source: Microsoft Research
Author: Pejman Aghili | Marios Constantinides | Sampath A Ramamuniappa | Zheng Gao
>> Top IoT Projects using Arduino for Engineering Students
>> 200+ IoT Led Projects for Final Year Students
>> IoT Software Projects for Final Year Students