Skip to content

Course Report

Jump to bottom
Casper Kristiansson edited this page Jun 4, 2022 · 2 revisions

What is a good project method for small IT-projects?

In the course II1302 "Project and project methods at KTH EECS Kista in the spring 2022 we will try to answer the question.

Philip Hägg, Casper Kristiansson, Fredrik Janetzky, Ville Vik, Daniel Chouster, Fredrik Lundström

EECS, Royal Institute of Technology, Isafjordsgatan 22, 154 40 Kista, Sweden

Abstract

(Fredrik J) When starting this course we aimed to find a answer to the question "What is a good project method for a small IT-project?". Throughout the course have the group tried out different types of project methods to see if we can find an answer to the question. This document is going through our study, both literature to get the knowledge about different project methods but also how it all went when we tried to achieve the answer.

Keywords: Machine learning, Weather prediction, Internet of Things, project methods, agile

About this document and the research behind it

(Daniel and Ville) The purpose of this document is to examine different kinds of project methods while working on an IT project as part of a team consisting of six developers. In addition to that, this document also aims to train the students to write scientific reports which will be useful for the upcoming bachelor thesis. The readers of this document will mainly be the course responsible for the course II1302 "Project and project methods".

The concepts discussed in this document are all based on the course literature for this course which makes this report reliable. The group followed standardized project methodology which also contributes to a reliable report. For further reading, please refer to references in the reference list. Additionally the project group’s own input on the concepts are discussed throughout the text. Taking all of this in to account the methods resulted in a functioning product validating the methods used in the project.

Chapter II introduces the project and the course that it is part of. The purpose of the project and the strategy to approach it is discussed. Then, in chapter III, the literature that was used as a source for the project and the engineering practices that were used are explained. Chapter IV explains in detail how project methods have been examined.

Chapter V discusses how engineering practices are implemented in the actual project by each role in the team. The results of the implementation are then covered in the result section in chapter VI, which refers to how well the project method worked for the team and what practices that turned out to work well for the project. Chapter VII contains a description of some improvements that could be made for future projects. In chapter VIII an overall discussion regarding the project is found with further discussions on the methods used and their results. The report ends with concluding remarks in chapter IX.

Introduction

Background

(Philip) This study is made by the group of students as final examination in the course Project and Project methods. The group have been studying different kind of projects methods and tried them in practice in the frame of this course. In this document the study will be compare the experience gathered from practicing these methods, with the recommended literature from the examinators of the course

Problem Formulation

(Philip) The task is to create an IoT device that could be controlled through a web based interface. The IoT device and the software solution should fulfill these criterias:

  • Maintainability

  • Dependability and security

  • Efficiency

  • Acceptability

With maintainability the software should be written in such a way that it can evolve to meet the changing needs of customers. While the software is dependable it should not cause physical or economic damage in the event of system failure and the security makes sure that malicious users can not access or damage the system. The efficiency means that the system should not be wasteful with the system resources, such as memory and processor cycles. Finally the system should be acceptable to the type of user in which it is designed for. this means that it must be understandable, usable and compatible with other systems that they use [1].

Investigation strategy / solution strategy

(Fredrik J) The group came to an conclusion of trying out different but already known strategies as an approach to the issues that we would face. By testing out different strategies we would come up with a good answer to the question "What is a good project-method for a small IT-project". Every member of the group would be responsible for a certain area inside the project, this would help us go deeper in different solutions to the problems and get a better answer to the big question.

Related works

(Philip) No related work was found

Boundaries

(Philip) The study is made for smaller IT-projects, hence the conclusions made in the end of the project is related to small IT-projects. The conclusions should therefore not be compared with large IT-projects.

Theory and engineering practice

(Philip) This chapter will list and to some extent describe theories and engineering praxis that have been used in the research. There are two sub chapters, literature-study and pre-study.

Literature study

(Philip) Around the 1980s and early 1990s, the standard way to create large IT-projects followed a plan-based methodology. Which was founded by the software engineering community that was responsible for developing large, long lived software systems. these were developed by large teams working for different companies.These plan driven approaches involves a significant overhead in planning, designing and documenting the system. This overhead is justified when the work of multiple development teams has to be coordinated.

However when the plan-driven approach is applied to small and medium size projects the overhead involved is so large that it dominates the development process. Which means that more time is spent on designing the system, than actually developing and testing it [2]. The small/medium sized projects are more suitable to run a agile software development method, as XP or Scrum. In Scrum the product is broken down into a set of manageable and understandable chunks, which are developed short and rapid iterations. The whole team has visibility of everything and therefore the team communication is improved. The customers can see on time delivery of increments and gain feedback on how the product works. The agile methods is designed as an incremental development method that focus on rapid development with frequent releases of the software, reducing overhead and producing high-quality code. Where the customer is involved directly in the development process[3].

Overall sources

  • Project health and status [Essence – Kernel and Language for Software Engineering Methods v1.2]

  • Scrum [Scrum and XP from the Trenches]

  • Phase division

  • Project bases [Sven Eklund, Arbeta i projekt - individen, gruppen, ledaren]

  • Person and group dynamics [Sven Eklund, Arbeta i projekt - individen, gruppen, ledaren]

Customer representative - Competence According To [Essence 1.0]

  • Vision

  • Requirements specification

    • "Stories

    • "UseCase"

Architecture - Competence According To [Sommerville - Software Engineering 9th edition]

  • Architecture (Kruchten, 1995)

Developer - Competence According To [Sommerville - Software Engineering 9th edition]

  • Design plan

Tester - Competence According To [Sommerville - Software Engineering 9th edition and Test och Kvalitetssäkring av IT-System]

  • Test plan (Test och Kvalitetssäkring av IT-System)

Management and control Competence According To [Sommerville - Software Engineering 9th edition and Scrum and XP from the Trenches]

  • Project planning

    • The project definition

Environment, sustainable development, ethics and gender equality

Work environment

Preliminary study

(Fredrik J) The approach for this research contains a study where a small IT - projects is implemented and the project group study, analyse, and reflects around project methods. The research is done during a limited time frame, therefore it’s important to set boundaries regarding the literature study and the research questions. The IT-sector contains different project methods and philosophies. Due to the limited time frame the group would not have time to test all of them in a qualitative manner.

When doing different studies, experience in the certain area is an important factor that can determine the outcome if it will be bad or good. Nearly all of the members in the group was fairly new to working in project groups developing small IT-projects. This made it crucial to use the experience and knowledge from external peoples knowledge in the area. One of the benefits of working in a group is that the research is done by more than one person. This will lead that different perspectives are seen which will provide an additional dimension for discussion on the subject.

Considering the research is done with boundaries mentioned above, theoretical studies about the subject but also practical testing of different project methods do the members of the group think that there are good opportunities to achieve the goal of the research and create an good understanding of how small IT-projects can be operated and organized.

Examination methods

This chapter explains in detail of what methods have been used for examining potential project methods. There are a number of questions that will be matched with corresponding methods that suits and satisfies the question in the best possible way.

Questions to answer in the survey

  1. How does one judge if a sub-project method or practise is optimal?

  2. How does one categorize, choose and name project methods (practices) so that the discussion is conceptually consistent to engineers throughout the IT-industry?

  3. What responsibility roles should be used as an approach in the project?

  4. What a project consists of and which methods / practices are to be used, examined, and assessed? What approach should be taken?

Method description & examination method

(Casper K) During a software development process, the methodology that is being used plays an extremely big part on the end product. This means that picking and examining which methodologies and practices to use in a project becomes crucial. But even so, how could a methodology be examining or categorized? Which approach should a team be using when picking the methodology? There exist hundreds if not thousands of different methodologies that are being used daily and picking the correct one could become extremely hard.

Therefore, there exists a several factors which plays an important part when picking a methodology. These are: examination methods, concepts, methodology categorization, responsibility roles, and approaches for picking the best methodology and practices. Each of these aspects will be discussed in detail in this section.

Method 1: Examination Method for Project/Sub-Projects Methodologies

(Fredrik L) Figure 1 describes how a team could examine different project methodologies to find the most suitable one. The yellow fields are the activities that relates directly to the examination of project methodologies. The first activity for the team is to understand the task/problem. This is the time where the project team needs to understand the problem so that it can lead to an examination method. With the suitable examination method the team needs to gather experience of project methodologies so that they can compare them to one another. The team can construct a result table of all suitable project methodologies and describe them with details and then rate them by how optimal they really are. This should then lead to a better project methodology the project team can use. This whole process is done in multiple iterations so that the team can gather more experience and improve the project methodology more. When all of this is done the project team should discuss the results and this would hopefully lead to the best project methodology for their project.

Examination method for "What is a good project methodology in smaller IT-projects?"[4]

A sub-project is part of a bigger project. Dividing the project into sub-project are done when it is considered easier to divide the larger project into smaller parts to reduce risk and set up deadlines. For example a larger project can be divided into smaller projects where each small project is a component of the larger project[5]. Another example is dividing a larger project into smaller projects by phases, i.e product functions and features. There are several factors to take into account when choosing a suitable sub-project methodology. To find an optimal sub-project methodology for a project one need first to know what type of sub-project it is. Customer and stakeholder involvement is important when finding a suitable sub-project methodology. If there is such involvement the customer and stakeholder might change the needs and requirements during the project. Number of people working on a sub-project is also important. Sometimes it is easier to split the whole project team into smaller teams that tackle smaller problems. There are also the complexity of completing different tasks to take into account when choosing a suitable sub-project methodology[6]. For example when working with software development sometimes the design phase might require more effort than the development phase and sometimes there are more complex programs take require more effort during the development phase. Sub-project sizing is also important. By estimating a size of a sub-project one does not only explore the sub-project time estimation, sub-project budget and team size but also estimate how many tasks there will be. This indicates a risk that the team might not have enough effort and time to complete all of the tasks especially if the project complexity is high[7].

Method 2: Concepts

(Fredrik L) It is important that concepts in project management remains intact. It is almost like creating a universal conceptual language so that engineers can communicate in project management terms without any misunderstanding. Project methodologies are named after a method layered architecture[8]. Methods are composed of practises which are described using kernel elements that is then defined in terms of language. The methods and kernel are defined by the Essence language. It is a language that is domain specific language and allows a definition of kernels, methods and other features for easy usage and adaptation. The Essence language design has two objectives: one for making all of the methods and practises visible for developers but also making them useful. The second objective is to make a semantics of a guide so that the team knows how the method works and what they are supposed to do[9]. Because of this there are very many well-known methods but this way of creating a universal methodology concept language allows project teams and companies to create their own methodology and share it with others in a understandable and adaptive way.

Concepts

Method 3: Methodology Categorization

(Casper K) As we know and have learnt, there exist hundreds if not thousands of different methodologies for software development. Each year new methodologies gets invented which suggests that their method improves the overall structure of a project. Many of these methodologies due in fact get improved and therefore replace industry standards. But even so, the different approaches to software development in most cases will be situation dependent. Meaning, certain teams and project will use a particular methodology which works best for them and in other situation other methodologies will fit better. Because of this there will never be a specific mythology which magically will be best for all teams and projects. If a software developer will be switching methodologies from project to project, it is important that the different approaches are consistent throughout the IT-industry. If they methodologies would not be consistent, it would result in that switching or trying out new approaches would require a lot of time and effort.

As mentioned above many methodologies are consistent with each other which means that those approaches could be categorized. The different approaches could be grouped into four distinct categories, predictive, incremental, adaptive, and iterative[10]. These different classifications are divided based whenever the project team knows exactly what the product should be. In some cases, the team will have a slight idea what the product should be while in other projects the result could be clear as day.

The first methodology categorization is predictive. Predictive approaches are in most cases associated with projects where the requirement of the product is established. Because the requirements are already known the team is able to concentrate on planning and evaluating the projects risks. Example of predictive methodologies are the waterfall method. Specifications of the predictive approach often contains that the project has a “strict” completion date. This means that if something in the project would go wrong it becomes fairly difficult to change the direction of the project.

The strategy uses milestones along the timeline to control the complete process. Because all the requirements have already been established in the project a big goal becomes to finish it as fast as possible. Because of this the predictive methodologies are not suited for projects that requires flexibility[11].

The second methodology categorization is adaptive. As in the name the adaptive approach builds on the fundamentality that the project scope and product could swiftly change. Methodologies that build upon the adaptive approach often uses shorter sprints with overall shorter goals. Therefore, the general structure builds upon that the team develops the product in iterations which later receives feedback. With the feedback the developers will change and update the product which will shape the result. Example of situations when this approach could really be beneficial would be for example when a client’s needs and requirements change frequently.

The incremental development process is usually used when the constraint of the product is somewhat known. But compared to predictive methodologies the development procedure is divided into iterations rather than that the project is develop in one swoop. But because the approach is divided into the iterations, the team is able to make changes later on in the process. Meaning, the project is divided into small segments which is much more manageable.

Each iteration the team will go through a development life cycle. Each period consists of four phases, requirements, design, implementation, and testing. This means that each iteration incrementally builds on the project from the past iteration. Often, it is recommended that a first version of the program should already be develop during iteration one. After that, the program will be improved based on the feedback from the previous iteration and as well as new features added[12].

The last methodology categorization is iterative. The iterative approach is remarkably similar to the incremental methodology. The only substantial difference is that often when iterative methodologies are used when the team does not have an unclouded vision what the requirements and the product should be. Meaning all the requirements and goals have already been established for the project[13].

A way to solve both questions mentioned above is to have a general classification of comprehensive definitions and descriptions for all methodologies. The company Object Management Group, Inc. (OMG), which is a non-profit organization, aims provide this type of definitions and descriptions for software engineering methodologies[14]. The document describes in its scope that, “The Kernel provides the common ground for defining software development practices” page 1, paragraph 2. The scope later describes that the document provides the essential elements for most part which a software developer will come across when studying and using different type of methodologies.

Using a practice like this will help methodologies to use an industry standard rather than coming up new terms each time a new approach is develop. This will help the engineers to swiftly learn and move between different methodology categories. But having a main source for the industry standards could result in a couple of shortcomings. Using an industry specification like Essence would result in that the entire industry becomes reliant on that company / companies. But in theory, if all the classifications of definitions and descriptions come from one company the industry could build upon them. This mean that every methodology will have the same base but each of them will have extended concepts and definitions.

Method 4: Responsibility Roles

(Fredrik L) There is not only a formal structure needed for the project itself but also for the project team. The project team members can be assigned different roles and responsibilities to reduce risk. There are many different roles to be assigned but which ones are the most crucial? The project manager, also known as project leader, has a key role during all of the phases and processes. The project manager is responsible for the completion of the project. Not only a completion but a successful one. The project manager is also responsible for making sure that the successful project is completed at a certain time and does not exceed any time limits and also keeping the budget for the project [15]. The responsibility roles depends on each individual project and there is room to make your own responsibility roles that suits a certain responsibility that might not exist in every project. It is always good to have as many individuals that have a responsibility as possible since it eliminates risk and in some cases improve the quality of the product.

Method 5: Approach For Picking a Methodology or Practice

(Casper K) Which approaches should a team be using when picking which methodology and practices to use in a project to develop a product in the most efficient way? As discussed in “Method 3: Methodology Categorization” all practices and methodologies that are being used in the industry is in most cases situation determined. Based on that, the initial step is to choose which methodology category a certain type of project lands on.

But even so, there exists a lot of different type of elements in a project which influences the type of methodology category the project lands on. In method three it is discussed that one of the most crucial factors in the methodology categorization is whenever the requirement in the project is already predefined. If the development team knows exactly what the end product should look like certain types of methodologies will work a lot better than others. Another major factor is if the project has a strict deadline, which than results in that picking a methodology from the category predictive would be the best approach.

Other key factors in choosing the category of methodology are the team. The first factor would be the size of the project. If the end product should be in a considerably larger size, there is an extremely high possibility that the requirements of the project could change during the development of it. Because of these methodologies that builds on the predictive approach would not be a good option.

As mentioned, the team plays a crucial role when choosing a methodology. If the team has worked together before on other projects, it might be a promising idea to use an approach that has already been used. Because the team is already familiar with it, they will be able to quickly understand what parts of the methodology works and which parts does not. But even though a development team is used to a strategy it might also be a good idea to test new approaches. This way they might discover other methodologies which might work considerably better for them in certain situations. It is important that if the team does try a new strategy that the product still fulfills the requirements, so the test of a new approach does not affect the result.

If the team has already used a specific methodology that works another idea could be trying to combine specific parts of that approach with others. This way if the group already knows what works and does not in the methodology, those specific functionalities could be switched. Doing this will certainly help the efficiency of the development of a product.

But if a team should be testing different approaches for development, how could they asses if the strategy is working? How could multiple methodologies be compared to each other? As discussed, a lot of methodologies cannot be compared because they are situation dependent. But a team could always evaluate which parts of the methodology or practice that worked. That is why it is particularly important throughout the project to evaluate and assess what in the project is working and what is not. When a team has finished a project or product it is valuable to discuss through the project timeline what could have been improved. Even though if the group will not be working with each other in future endeavors each member will be learning lessons and key factors of what worked.

Implementation

Project Leader

(Casper K) The project leader is responsible in the project to plan, organize and lead. In order to fulfills all these requirements, it is important to make decisions so that the team will work in the best and efficient way. This means that the leader roll in a project needs to put in a lot of work to understand what each member of the team wants out of the project.

The general base for the approach of the project was scrum. The group used scrum activities and rotation to constantly keep up to date on what needed to be done and the current state of the project. The exists four common activities in scrum which are sprint planning meeting, daily scrum, sprint review and retrospective. Figure 3 visualizes what each iteration of the project consisted of (one period of scrum).

After each iteration, the group had a retrospective where they discussed what have been great and terrible during this iteration. By doing this the team was able to discover the weaknesses in the project structure and was able to improve upon those weaknesses.

Scrum activities[16]

The general project methodology that was used for the project is unified process [17]. The approach builds upon four separate phases: inception, elaboration, construction, and transition. The methodology requires the team to be risk-focused which leads to that the group is able to identify crucial risk factors at the beginning of the project.

The project leader was responsible for creating the project plan for each iteration. This means that the leader, with input from the other team members, made decision regarding allocating the different tasks for the iteration. At the end of each iteration the team has a retrospective where the project leader was able to get input on what was working well and what did not. This means that each iteration that passed the group become better to navigate the project in a flawless manner.

The leader was also accountable for picking the best methods and procedures. For example, the group noticed that during a couple of occasions the team would end up working on the same material. Having six team members working on the same thing typically leads to inefficient work due to not everyone knowing what do to. To deal with allocation of tasks, the project leader held a small meeting (5-10 minutes) before the group started to work to make sure that each member knows exactly what to work on. This helped the group to understand what each member should be working on. It also resulted in that the group got a status update on the project.

In the middle of iteration three the group noticed that they were much more efficiently solving the tasks when they were working two and two (pair programming). At the beginning of the project the group had the understanding that the best way to work on tasks would be alone. But because the group did the retrospective after each iteration, they were able to fix this and change the overall structure of the development phase.

To uphold the roll as project leader it is important that the project remains with the timeline. This means that if certain tasks of the product because behind schedule, that the project timetable gets updated. Meaning that project structure gets updated so that all tasks get developed before the deadline. For example, in many cases when people work on technologies that they have never worked with often result in that the estimation of time could be wrong. This means that the task could take a lot more time than anticipated which means that the product becomes behind schedule.

Stakeholder representation

The stakeholder representative has the responsibility that the requirements by the stakeholders are met for the product. It is very important that the communication is clear so that the stakeholder representative can give the team a clear frame to work around from the very start.

Additionally, to just having a bunch of requirements written down, each requirement should be discussed regarding its priority, importance and further details with the stakeholders. In our case the stakeholders are very close to the project which removes the complications of having the stakeholders and the developers at different places [18]. This also means that during developing the requirements can be clarified if any confusion occurs and the team can inform the product owner if some functionality is not possible to develop in the time frame for example. An example of this in this project is when the developing began, and the group were looking at the functionality of choosing location. The requirement was low priority and would take too long time to finish, which led to the requirement being removed from the final product. This specific requirement did not have any other requirement or component depending on it being there.

The scrum method is a great fit for a project when you are dealing with a product that can be divided into different requirements. The requirements are translated to use cases and user stories which then each has an acceptance criterion that can be seen as a goal to meet at the end of a sprint [19].

Furthermore, the group implemented the essence practices. The use cases and user stories were created following the Use-Case 2.0 practice [20]. A use case covers the ways of using a system to achieve a particular goal for a consumer. When all use cases are combined it shows all the useful ways to use the system, and illustrates the value that it will provide. Use-case 2.0 is a scalable agile practice that takes the use cases in to account to capture the requirements and drive the incremental development of the system to fulfill these requirements.

Testing

(Philip) Testing can be done in many different forms and it’s more than just unit tests. We started out early with testing a lot of our work, as early as iteration one. We thought that it was a good idea to split the group and work in sub-groups when writing the initial documentation and designs of the work. When the documentation was finished, one group could review the work of the other group which we believe gave a better result because the reviewing group had input almost every time.

The testing followed the V-model, which was a good way for the team to get a good strategy for not only building the application but also how to deliver a complete working product. During the verification phase the team could work without the need to test all parts of the project, until we entered the coding phase. During this phase the group could focus on Test Driven Development (TDD) and figure out how to test the code before they wrote it. This worked fine in some implementations however, not all of them. Some of the testing was written in programming languages most members of the group were unfamiliar with and this made it more difficult to implement. They group decided to write big parts of the code base before and wrote the tests later.

The hardware did require manual testing because we didn’t find any way to test it in any other way. For testing the components, we simply checked if data was read and printed out to the display and checked if it would change if we added heat or cold. We also checked with another thermometer if we got the same results. Other parts of the hardware were more obvious, when connecting the internet and if the hardware booted and so on.

While the group started to integrate all the different components the testing came naturally. Some of the components we’re tested and working, but there was some manual testing that needed to be done. If the expected information from the front-end is showing up in the front end and if our hardware is outputting to the database and so on. This phase worked out very smoothly because all the components were very well tested before the integration started.

For system testing the group looked at the finished prototype and tested it manually that everything worked as expected. Because the server and the API was created manually, we did some performance testing and opened multiple sessions and tested the functionalities. We made some UI testing on friends and family that commented on the design and the usability of the website, which resulted in valuable input. The predictions made from the ML component was tricky to test however, in this part of the project we noted the predictions and compared it to other weather prediction services. This looked quite bad; however, these weather services constantly change their predictions which we didn’t. After taking notes of the prediction and waited for the outcome, it looked a lot better.

For the acceptance testing we checked that the product was matching the business needs.

Sustainability

(Daniel) The sustainability minister was responsible for making sure that all relevant sustainability measures were taken during the project. This included sustainability aspects from social, technical and economic perspectives and also making sure that the working environment was good and that everyone contributed to a sustainable development.

It was important to make a plan for sustainability so that sustainable measures were taken from the very start of the project. With this approach, everyone knew what to do in regards to their roles and how to contribute. To follow this approach, the sustainability minister assigned tasks involving sustainable measures to everyone based on their roles. The sustainability minister was then making sure that everyone did their duties and pointed out flaws whenever someone did not follow the sustainability plan or whenever something could be done differently.

The technical sustainability aspects that needed to be respected were mainly making sure that the software is reusable and can be easily modified and that the hardware is environmental friendly. Issues regarding non-sustainable implementations of the system architecture, code smell and redundant code had to be addressed when they were noticed (usually by the sustainability minister), mainly by rewriting the code in a more sustainable way so that it would follow the architecture model and the sustainability plan. The group also made the decision to work with as many used products as possible when building the hardware in order to build the weather station in an environmental friendly way. The station was built using an old raspberry pie and most of the cables were used second-hand. This also helped the economic sustainability since the group managed to stay within the budget because so much of the material was second-hand.

Some measures had to taken for social sustainability. This included planning the tasks thoroughly so that no one would have too much to do but also reflecting on the social cohesion during the retrospects. This enabled the group to divide the tasks between the team members evenly and help each other whenever someone admitted to having issues with a certain task or not feeling well about the workload. This strategy made sure that no one was left out of the group and that everyone could contribute to the project in a fair and equal way.

Architecture

(Fredrik J) Having a good architecture plan is efficient to make an project work out smoothly and according to plan with all the different components but also a great overlook how the entire system is gonna work out.

The main thing when designing an architecture for an It-project like in our case is to have a good communication with the rest of the members of the development team but also the the stakeholders that are gonna use the product. When coming up with the first architecture it was important to see the whole picture and not just focusing on the small parts that the project consisted of, we needed to get a good overview over the entire project. As a group we gathered all the developers and discussed what kind of functions/components we needed and what was the most sufficient functionalities that would make the project work. The first architecture we came up with was implementation-agnostic. The meaning of this is that we are not reliant to a certain programming language, it was mainly done in pseudo code.

It was really important that we would come up with an good software architecture over the project considering this would affect the performance, robustness but also the maintainability of the system. When the overview over the system was done was it time to discuss and come up with all the components and sub-systems that was needed to make the functionalities work as planned. Now when the architecture was growing bigger and bigger we made the choice of implementing "Krutchen’s 4+1 view model".

Krutchen’s 4+1 model is used to explain an architecture of an software system by showing different concurrent views. This would help the developers, end users, project managers and also the system engineers to look on the project from their perspective. The logical view is for the end-user. It would show all the functionalities of the system. For this we made a good overview diagram that shows the key abstractions in the system as objects. The second view is the process view. This view gives us a closer illustration of the running software and explain the system processes and how they communicate.

Then there are the development view, it will describe the different components inside the project. The last and fourth diagram is the physical view. The physical view portrays the system from the perspective of a system engineer. It is describing the topology of the software components as well as the physical connections between these components. In our case it will show the deployment diagram.

Design & Development

(Fredrik L) The development of a product is a constant process, not only during the creation but also after the product has been released and need maintenance. Therefore software code needs to have some sort of maintainability, dependability, security and efficiency. Although our product does not need the maintainability it is always good practise to write maintainable code. This requires engineering discipline where engineers apply their knowledge and tools where it is needed to write code that fills these criteria. This is specially important when working in larger projects together with other engineers.

The individual responsible for development in this project made sure that all of the development aspects met these criteria of software development standards. Together with an architectural description, a development plan was created so that it was clear of how to meet the criteria. The development plan was created on the project GitHub Repository Wiki[21] so it would be easy for all project group members to access the development plan at any time. Plan-Driven development usually consists of setting up requirements for the product, a schedule describing software component deadlines and who is responsible for what. Another crucial part of the development plan described the risks and weaknesses. The project groups development plan therefore made sure that the project definition was a useful document so that the engineers of the project understood the goals of the product and when it was supposed to be done[22]. The development plan also went through a lot of other specifications like programming language and frameworks but also design patterns.

As an example of the development plan, the whole architecture of the product system was divided into two major parts. One back-end and one front-end module. The back-end module consisted of many sub-modules. For example, a REST API was created in Java for fetching data for the front-end application (made with React) which was divided into a controller and a model. This followed the Model-View-Controller[23] design pattern (view is the front-end application) and all of this was specified from the start of the project in the development plan. As a development plan tool the project group used a platform called Trello[24]. This tool was used to simplify the scheduling and responsibility process of the plan-driven development. For example in Trello a card, which is a task, can be assigned a deadline but also to a specific group member or several group members.

The project has gone through somewhat of an incremental development process where we have reviewed the product ourselves through different stages. Always when we think we have completed a module we have seen it as a version that can perhaps be improved in some way. This is done until the project group has been satisfied with the result of the development. For example when developing the Machine Learning module we started of with some results that was not satisfying and the responsible for the Machine Learning development changed to a better model that got much better results, i.e the first version of the Machine Learning module was not satisfying and was changed to a better version. The project group chose to practise incremental development since it made most sense to the group.

Result

(Ville and Daniel) Below is a table with responsibilities which the group discussed during the retrospectives of the iterations.
Resopons- Working method Judgement Alternative
ibility practice/pattern Pros and
cons
Project- Unified Process Easy to make Waterfall-
overall changes in plan method
Identify risks in
the beginning
Project- Iterative Keeping track of Incremental
management goals and
responsibilities
Stakeholder Storytelling Translation to Customer
-responsible code talks
Can be vague directly
descriptions to team
Product Sprint demo Product owner Customer
owner can see talks
communi- progress directly
cation Short demo to team
Testing V-model Test is done Testing
before code existing code
Developement Pair Effective Solo
programming Working from programming
a distance

"KEEP - PROBLEMS - TRY"

KEEP

  1. Keep: Virtual Workboards

    Motivation: Using virtual workboards such as Trello and Lucidcharts made it easier to plan the project since a lot of time was spent working on the project remotely. It also made it easier to make changes whenever the group came up with an idea instead of waiting to access the workboard in the physical location.

    Improvements: Use the virtual workboard less during physical meetings and instead use the physical one. This would make it easier to brainstorm and discuss new ideas together instead of having everyone staring at their own screen.

  2. Keep: Meetings over voice call

    Motivation: The team agreed that working from home was a more effective way for the project to reach its end goal. It is easier to share screen with modern software rather than moving around in person to then go back to your own computer to do research alone. Having all the planning and documents digital the team saw no benefit in meeting person more than about once a week.

    Improvements: With having the requirement to have meetings in person the team could have spent less time on meetings online so that there were tasks left to do at the in person meetings.

    References: None

  3. Keep: Git

    Motivation: Git worked great for the group as a version control system. Projects with a high level of collective code ownership have proven to be very robust. If one key person is sick the sprint does not die because of it.

    Improvements: Create a branch for each member or component and be more considerate when merging on the main main branch. This was mostly a problem during the beginning of the development phase when the group was quite inexperienced with pull requests.

    References: [25]

  4. Keep: Assigning tasks to everyone during iteration planning

    Motivation: At the start of each iteration, the group planned the following two weeks and assigned tasks to everyone. This made sure everyone had something to work on.

    Improvements: Assign different types of tasks to everyone each iteration so that all team members would get familiar with every aspect of the project and not just the parts that each individual worked on. This would also make the group less reliable on certain people.

    References: None

"PROBLEMS- Try"

  1. Problem: Understanding difficulty and time of tasks

    Try what?: Giving each task a little bit extra time more than what you think and doing calculations.

    Motivation: When planning the tasks and the time estimated for completing them the time estimation was quite optimistic. This could be solved by planning more time for each task at the cost of removing some low priority task that there was not time for anyway. According to the literature there are two ways of planning what tasks to do in each sprint: gut feel and velocity calculations. The team relied way more on gut feel than the other which led to wrongful calculations of time.

    References: [26]

  2. Problem: Unclear stories

    Try what?: Clarify the stories during the meetings to make sure that everyone understands the purpose of each story. If necessary, break them down into smaller ones.

    Motivation: A story could mean something to one person and another thing to someone else. During some meetings some team members were confused about the stories which implies that they were not clear enough or they they could be interpreted in different ways which forced us to modify them. This led us to spend more time than necessary on the stories.

    References: [27]

"PROBLEMS- Skip"

  1. Problem: Useless time spent in person

    Skip or replace, why?: Remove the 8 hour time in person requirement

    Motivation: The team agreed that the in person common time often led to less work done compared to working over voice call without distractions around the team as there were three other groups in close proximity. This 8 hour requirement was later reduced to 6 hours, but still led to time where the team worked with low efficiency compared to the pair programming from home.

    References: None

  2. Problem: Focus on building new stuff rather than getting old stuff into production

    Skip or replace, why?: Replace with a strategy that prioritizes getting old stuff done.

    Motivation: As you implement more features without finishing the ones that are already in progress, the almost-ready-to-release code gets heavier and heavier, slowing everything down. During each iteration you can expect to spend some time fixing bugs from the previous iteration, but when you do not finish the old features they will start to add up in the end and make it harder for the group to follow the iteration plan .

    References: [28]

  3. Problem: Book meetings a day in advance

    Skip or replace, why?: Book all meetings on the first working day of the week.

    Motivation: The probability that one or several team members are available for a meeting increases if you book it several days in advance. Occasionally, during the project, the team booked a meeting for the next day which a few times led the group to have meetings without some team members.

    References: None

Analyze/ Improvement suggestions

(Daniel and Ville) Going into the project a goal was to try different project methods and evaluate the results of each one. The group had time to try a few and the results above point out that the group found most of them quite useful for our project although different ones might be implemented if a similar project was to be done again.

Some of the practices that the team was not as happy with as others might have been a result of not having enough time to study each practice to the fullest. The time frame that the group worked in did not allow the group to fully study each and everyone of the methods and practices that the group wanted to try during the project. On the other hand some of the methods felt really natural for the team and were not hard to understand which led to great results and great progression on the final product.

There is a consensus in the group that the sustainability plan that was required for this course was unnecessary. This project is way too small to require a plan and a report since the time limit to finish the project itself (excluding the final report) is just eight weeks.

Discussion

Intro

(Casper K) Throughout this report it has been discussed the process of selecting and evaluating methodologies. But even so, what is the final decision to the question of the report. What is a good project methodology for a smaller IT-project? The authors of this report took the matter to a test. Together in a team of six people developed a technical IT-solution where they discovered, picked, and assessed methodologies.

In the upcoming two subsections the question will be discussed and evaluated. It will be stated which methodologies and practices that was used during the development of the project. Nevertheless, as mentioned in this report, a single methodology or practice will not be the best approach for every situation and therefore adapting, learning and using multiple methodologies is always the best solution.

Method discussion

(Fredrik L) As discussed before this project used the unified process as a general project structure. This project methodology worked out great since the project structure needed the ability to handle abrupt changes in the plan or requirements of the product. Since we did not have a lot of time to build a plan for this project and the project group was the clients themselves, there was a lot of changes that would come up. The unified process was a good project methodology because of being able to handle many changes unlike for example the waterfall method. The waterfall method would be a good choice if the project plan is rock solid and the clients have a clear picture of the product and does not want any changes. One downside to the unified process is that is is a little bit harder to identify the risks in the beginning but this turned out not to be a problem for the project group. The project group made a risk analysis in the beginning of the project in the project description document. In the vision document there was also a analysis of competitors and competition on the market which eliminated some risks of the products market success. The working practise for the project management was a iterative pattern. The most positive benefit of using this practise is the ability of keeping track of the project goals but also the responsibilities. This is because the whole team is part of the iterative planning so everyone knows what needs to be done and by who. The iterative project management practise was also a reason why the project group handles changes so well. The stakeholder practise was storytelling. By setting up stories the project team got a clear picture of how the product was supposed to work but also how it was supposed to be used like. The stakeholder stories worked out to be very easy to translate into code directly. One downside with using this stakeholder practise is that the stories could be misinterpreted and there could be potential flaws in the final product. Another downside could be that the stakeholder stories could have vague descriptions. An alternative method to storytelling is that the stakeholder communicates directly to the team. The product owner communication was made through sprint demos. After each iteration a sprint demo was made so that the team could demonstrate the product and in what stage it was in. This is a really good product owner communication method since the product owner can see the progress directly after each iteration/sprint. One downside to this method is that the product owner only get to see the product in the end of each sprint. The alternative method could be that the customer communicates directly with the team. The working method for testing was V-model. In this kind of testing practise the tests are made before the code is written. This ensures that the developers know what the functionality they are developing is supposed to work like. The alternative for this model is testing existing code but this method could make it harder to write a flawless functionality on the first attempt. The development method that was the most suitable and felt the best for the developers was the pair programming method. This method turned out to be very effective for writing the code. Also when two team members was working together there would be a lot more ideas of improvement that would come up unlike if working with solo programming. The team chose to work from a distance a lot of times. This turned out to be a little downside for the pair programming method but by sitting together in a voice call and sharing the screens, this problem was solved. As mentioned before the alternative to the pair programming method is the solo programming method. This method works a little bit easier when working on distance but it does not provide the effectiveness of the pair programming method.

Result discussion

(Casper K) During this experiment that the team went through, they came up with a lot of conclusions on what truly makes a methodology great. The key factors that were used when deciding if a methodology really was a good fit is how well it suited for the project requirements, how well it adapt to change and how well it fits the team. Those are the general and most crucial factors of the methodology but of course there exists a lot of other considerations that plays a big part.

For the overall project structure, the team used the unified software development process. The approach uses an iterative and incremental development phase (iterations). Figure 4 visualizes the unified process life cycle. The overall process contains four separate phases, inception, elaboration, construction, and transition. After each iteration is finished the process goes through a cycle of feedback which is improved in the following iteration. This way the system becomes incrementally better from the previous version.

The Unified Process lifecycle [29]

The first phase, inception, is usually the shortest phase of the project. The period is used to establish the project idea by creating a business case, discovering risks, and constructing a development plan. This phase is crucial for the project otherwise the project is likely to fail due to unexplored risks, lack of overall goal, and lack of planning.

The second phase, elaboration, goal is for the team to discover the product major requirements and to perform a more in-depth risk analysis. This period will help the team to get a better understanding on exactly what the product should be, and which requirements should be met. The team will also be able to eliminate potential risks before they could happen during the project.

The third phase, construction, as in the name is the part of the project where the actual product is developed. This phase in most cases ends up being the longest. Because of the unified process approach each iteration within the construction phase will consist of cycles of feedback. This means that the team is able to consistently improve the product throughout the timeline.

The last phase, transition, often consists of tasks like delivering the product, finalizing documents and user training. In particular cases, the transition phase could result in that the team goes back to the construction phase depending on feedback received from the release of the product[30].

As stated above the project used an iterative and incremental practice for the project management part. This means that the project was divided into iterations which each spanned for two weeks. Each iteration consisted of planning, working and a retrospective. This means that the product was developed incrementally where the team tried to produce a first draft of the product during the first iteration. The product was than incrementally improved based on feedback and new features added.

During each iteration, the team had a sprint demo. The goal of the sprint demo is to get input from the project stakeholders and ideally receive specific feedback. This will help the project team to reach and improve the establish requirements of the project. The discussions will also contribute to more stories being added to the project which in turn results in a longer construction phase.

During the construction phase the team spend a lot of time trying different approaches and practices for writing code. Because the team was working with technologies that they have not used before, resulted in that they often had to help each other rather than working alone. This means that the team favored pair programming. Therefore, in the upcoming iterations the team planned so that multiple people were working on the same component. Doing this also resulted that the product had more of an incremental progress where each iteration demo, the application had new features to show.

Throughout the construction phase the team noticed that a few tasks took a lot of additional time than anticipated because they were working with unfamiliar technologies. But because the team had strictly followed the timeline up to this point and was prepared with a flexible plan. Doing this meant that they were able to move around tasks to deal with the assignments that did not get completed in time.

Using all these strategies lead to that the team developed the product in an efficient way. But throughout the project the team was constantly finding things in the methodologies and practices which could be improved. But the working method, practices and patterns stated above is the best and most effective way the team found for developing a smaller IT-project.

Contributions to science, engineering experience (student experience?)

(Fredrik L) This project led to a lot of extra engineering experience for all of the team members. The project gave a taste of what future work in the software engineering field might be like and what to expect. The project gave a lot of experience in how a project is planned and executed in a suitable way. There are a lot of project methodologies to choose from as well as many sub-project methodologies and this project gave a lot of insight in how to choose one of these. But there was not only engineering experience in the field of project methodologies that were gained. Also how to work when developing a product made of components and also how communication with other team members is key to get the best product as possible.

Concluding remarks

(Daniel and Ville) The final product that was delivered consisted mainly of an IoT device for weather data acquisition and a web application for displaying results, all of which took eight weeks to plan, design and construct. The project gave the group an opportunity to explore a different field that was previously unknown to the team – machine learning.

In addition to that, the group learned to work as an organized team using well-structured project methodology which is the intended learning outcome of the course II1302.

References

WeatherBrain @2022

Clone this wiki locally