Skip to content

Sustainability Development Description

Casper Kristiansson edited this page May 26, 2022 · 1 revision
Sustainability Development Description
WeatherBrain Version <1.0>

Weather Brain Project Sustainability Development Description

Abstract

This document describes the sustainable development used in the WeatherBrain project.

Version History

Date Version Author Description
25-05-2022 <1.0> Daniel
  1. 1 Sustainable development process and practice
    1. Sustainability roles and responsibilities

The project leader shall:

  • Keep track of economic sustainability. This includes making sure that the money spent on the project does not exceed the budget and that the components that are ordered are not redundant.
  • Make sure the schedule and the deadlines are respected.

The sustainability leader shall:

  • Clean up the code in the application to make sure that it is easy to understand, does not have redundant code lines and is easily reusable in case someone else needs to use it.
  • Be responsible for the sustainable development description.
  • Ensure that all team members incorporate sustainability measures into their respective code and encourage them to write it properly. The sustainability leader will then from time to time during meetings point out what code needs correction in order to always strive to achieve better sustainability.
  • Be responsible for social sustainability which includes making sure that everyone is included in the project and can contribute and that every team member is treated fairly.

The test leader shall:

  • Make sure the tests are sustainable. This includes writing the tests so that minor changes in the code that is used in the actual application has little or no effect on the unit tests. This will enable the programmers to make certain additions to the code without having to completely rewrite the unit tests.
  • Make sure the tests are actually useful and that they verify that the different functions work as intended. This will contribute to a sustainable software.

The development leader shall:

  • Choose services that are sustainable and follow some sort of sustainability plan. The companies that provide services should have reasonable sustainability reports that show that they take sustainable development seriously.

The architect shall:

  • Make sure the architecture of the application is easily managed. This includes connecting different components and structures in a way that makes it easy for the rest of the team members to incorporate their own components into the program.
  • Ensure that the MVC model and other architectures that the group agreed upon are respected by the other team members.

The stakeholder shall:

  • Ensure that we have a sustainable pace when we work. Which will ensure better health and quality of the work [1,p 111].
  • Design the use case models so that they are easy to incorporate into the application. Making sure that they are designed in a sustainable way.
    1. Working culture and conditions

The project leader proposes a schedule at the start of each iteration. Then the entire team discusses it and proposes changes if needed. This is a measure to ensure that everyone agrees on the schedule and that each iteration is thoroughly planned.

The group discusses the progress each week to check whether or not we are on schedule. If someone is stuck on a certain task, the group assigns someone to help that person. This ensures that everyone is included in the project and that no one is left alone with tasks that are difficult to solve without teamwork.

  1. Equality, diversity, and inclusion

During the iteration planning there is a discussion to get to know each other’s strengths and weaknesses and the project leader tries to assign tasks to everyone that requires roughly the same amount of time and effort. If someone is not happy with a task or feels like it is too difficult or unfair, the project leader rearranges the responsibilities to try to satisfy everyone. This ensures that everyone feels included and has a voice.

  1. Physical work environment

There is a consensus in the group that as much work as possible should be done remotely. Because of this, the group has spent a lot of time working from home and communicating via Discord. Nonetheless, it is a course requirement to work at least eight hours (later changed to six) per week at a specific location in school.

Generally, the working environment at school has been pleasant. The facility is clean and safe, although there is one downside with the location. There are other groups sitting at our facility that sometimes can be noisy and have loud verbal fights between each other. This has been annoying and the group has not been able to focus on the project as planned during some periods. However, most of the time the other groups have been relatively quiet and the group has been able to work effectively on most days.

  1. Sustainable product and service
    1. Hardware product and service

The group chose to work with as many used products as possible for environmental reasons. A large part of the hardware, including the raspberry pie and the cables, is made up of used material.

The IoT device is reusable for other projects. Since the group used Microsoft Azure, other developers can change the connection string and easily use the hardware and connect to the same service. This will make development and extensibility easier for future projects.

Since the raspberry pie is the main technology that the physical device consists of, the entire device is energy efficient and cheaper compared to most weather stations that you can order. This is primarily because it is only used to gather weather data and connect it to WiFi. There are no additional functions that make the device unnecessarily complex (e.g. sound effects, light effects, alarms) that you find in a lot of similar products for marketing reasons. The Weather Brain IoT device offers just what you need in order to collect weather data and nothing else which contributes to a sustainable, cheap and energy efficient device.

  1. Software product and service

One of the main goals of the group was to create a sustainable software. To do this, it is crucial to have a working system architecture [1, p 131]. The group chose the MVC architecture model. This allows easy modification since adding or removing new types of views can be done securely as each section is independent of other sections and thus it never affects other layers of the application [2, p 53].

The code is also easy to understand since there is a component file for each component and a view file for each view. Because of this simplicity and the flexible architecture, the application can easily be reused and modified by other people who intend to use our product.

Methods for testing and comparing the result that the software generates to weather forecasts from SMHI provides a solid basis for extensibility.

  1. Potential impact

With our open API we can share our current weather data but also the forecast prediction weather data. This could be used by researchers and scientists for their projects that require weather data. In addition to that, Weather Brain offers weather predictions at a very distinct location (e.g. your garden) unlike weather forecasts such as SMHI and AccuWeather which are more focused on entire cities or regions.

Appendix A - References

[1] H. Kniberg, “Scrum and XP From The Trenches” in How we do Scrum 2nd edition

[2] L. Lindbäck, “A First Course in Object Oriented Development”

WeatherBrain @2022

Clone this wiki locally