Team 42 - FYP Portal

Research

Possible Solutions

One crude way to build a solution for our project may be to code it using a combination of HTML, Javascript, and CSS, whilst using an SQL database. However, this would be time consuming for such a complication project specification.

Luckily, a much easier and cleaner option was open to us. Our client for the project was Microsoft. As such, our project was particularly suited to using Microsoft products to increase the speed of our development.

After researching Microsoft development products, we decided to research Microsoft Power Apps. To do so, we both read through the official documentation, and discussed this service at length with our clients representing Microsoft (Lee Stott, Ayca Bas), and a consultant representing the Ashton Court Group (Chris Seely), who acted as a mentor for us during this project.

Following these discussions and our research, it was determined that we would use the Microsoft Power Platform to develop our project. The reasons for this are as follows:

• Dataverse Integration [1]

  The Dataverse acts as a centralised location to store tables of data. It is also designed to be integrated into Power Apps projects; one may directly access the Dataverse through Power Apps. Data may be easily retrieved, modified, deleted, or created, in the Dataverse from Power Apps using cloud flows.

  Through cloud flows, developers can also automate several interactions with the data relevant to a certain project. This is useful for many purposes within our project. For instance, within our project it is expected that we may display a page of information about supervisors to students. Using cloud flows, this page may be updated whenever there is a new response.

  Therefore, we predicted that the seamless integration between the Dataverse and Power Apps would prove useful throughout our project, as almost all of the requirements of our project concern the manipulation of data.

• Rapid Code Deployment [2]

  One of the primary purposes of using Power Apps is for rapid project development. Time would largely be the limiting factor of the development of this project. Power Apps lends itself to this purpose - if required, one can deploy a website with zero code. While we will use code to perform more advanced functions, using Power Apps we were able to create a host a website immediately.

  For instance, the Power Apps Canvas may be used to create components quickly without needing to write any html, Power Automate may be used to perform logical processes to data, and website organisation is already set up, allowing one to tweak website settings or structure at will.

• Multiple Platform Types [2]

  For our app, we have three main user types, as detailed in the requirements section. Each of these user types have different needs and access levels. Within Power Apps, there are several types of platform a developer may create, each with different capabilities and use cases. Of these, there are three platforms which may be suited to our project - Canvas Apps, Portals, and Model-Driven Apps.

  Canvas Apps [3]

  A Canvas App is useful for creating a very simple space for a user to view and interact with data. Canvas Apps are incredibly quick to create - for instance, within a few clicks and zero lines of code one may create a Canvas App to display a table imported from a CSV file stored in the cloud. The drawback of a Canvas App is its simplicity - a developer is not afforded much customisation, and fewer opportunities are present for complex interaction between a users and the data.

  Portals [4]

  A Portal, like a Canvas App, allows a developer to create a space for users to view and interact with data. However, a Portal is useful for giving a user for complex ways to interact with said data. For example, a developer has greater control over the view and layout of a deployment, or for instance can enable a developer to create more advanced forms for the user to fill out. In a Portal, a user still remains somewhat limited in what they have access to - a user is not naturally given permission and an easy way to interact with data. Therefore, a Portal is great for a middle-ground, when a user will need to make more complex interactions with the project, but only requires limited access to the database and needs a straightforward layout to perform a few specific procedures without being swamped with a complicated page of information.

  Model-Driven Apps [6]

  A Model-Driven App affords the user with a high degree of visibility and control over tables in the database. Through a PowerBI dashboard [7], they may also see more complicated insights in the data, visualised. The drawback to this is that a user may not always need such close interaction with the database. Additionally, there is limited room to control the user interface of a Model-Driven App - it has fewer options to be as attractive and simple as a Portal or Canvas App. Therefore, it is suited to a situation where the user needs a high degree of interaction with a large portion of the database, and will be have some pre-requisite knowledge of how to navigate and use it.

To reflect on our user types; Firstly, we have an administrator who needs a large amount of control over the data stored in the solution and can be easily familiarised with the project. Secondly, students and professors - who need a high amount of controlled interaction with the data, but will not necessarily all be familiar with how to use the project.

As a result, it appears the appropriate platforms to build our project with would be a model-driven app for the administrator, and a portal for the students and academics.

Project Operations [5]

A Power Apps solution may be extended using Project Operations. As described in Microsoft Official Documentation, Project Operations can be used for "easy resource workload distribution" and "skillset matching to meet demands" [5]. This fits our requirements well, as we need to match the skillsets of students and academics as closely as possible to find the optimal project for both. This would eliminate the need to manually develop a matching algorithms ourselves - development would be significantly sped up as Project Operations would generate this algorithms for us

There are, however, drawbacks to using Project Operations. These are:

• Limited Control - while a built in allocation algorithm would speep up development, naturally there would be a more limited amount of control in its implementation. For instance, micro-parameters may not be available for a developer to tweak, and a developer is not give so much control of the algorithms itself which is used in allocation.

• Licence Fees - to use Project Operations, one must pay a licence fee in addition to the Power Apps fee [8]. For a basic plan, this is £90.50 per user. If the matching algorithm can be coded by hand, the amount of money saved would be immense in the long run - especially when considering there would likely be several users to pay for.

• Longevity - linked to the above point on limited control, using Project Operations makes the matching algorithm entirely tied to and reliant on Project Operations. The world of technology moves quickly, and it is not unlikely that at some point in the future, Project Operations could become obselete, or be changed in a way which affects our project.

• Project Specialisation - using an out-of-the-box algorithm from Project Operations makes it more difficult to specialise and optimise this algorithm to suit our project. For example, it is difficult to specify if we would want to use an algorithm which prioritises the quality of matches compared to one which prioritises making sure each academic has at least one match.

• Reproducibility - the Project Operations allocation algorithm is reproducible in the sense that it is straightforward, and so the process for using it in two different projects is simple. However, for projects with more nuances, the stripped-down interaction with the algorithm means one will struggle to apply more complicated aspects to similar projects. For instance, take an example of a similar project such as allocating teaching assistants to modules. If an allocation algorithm were manually coded, one could read the previous for help, or code it in a more general way which allows the algorithm to be applied to a range of things whilst maintaining the ability to cater to nuances. If Project Operations is used, a developer would simply need to build the solution from square one again, and may again struggle to deal with specific issues within a particular project.

As a result of this research, we decided that it would be more beneficial to use a bespoke matching algorithm. Our decision was based on the following 3 reasons:

• Unlike Project Operations, which is maintained independently of our solution by a third party, our algorithm is future-proof, and will not spontaneously change with regular updates. This reduces the cost of maintenance of the solution.

• Project Operations requires a costly license. This cost may be affordable at the time of adoption but may become burdensome with time and budgetary changes. As we are not utilizing the bulk of Project Operations’ features, we decided to avoid the extra cost and build a limited-capability algorithm which is sufficient for our scope.

• Our solution can be reproduced for other purposes or by other institutions. As such, we have built a system that other parties can use free of the additional cost, making our solution more distributable.