Features Implementation guidelines


Document	Features Implementation guidelines
Specification name	TukkoTrafficVisualizer
Author(s):	Muneeb Ali, Markus Suonio, Ashutosh Burman & Andreas Kjersheim
Version:	1.0
Date:	08.03.2024

Feature List

Every feature have an issue created and timed by the roadmap, as well as links to the user stories. Assignees are responsible to keep the feature-issue updated at all times!

Prepare documentation

Open the documentation for the given feature. Specify which team member is responsible for which concrete task, and communication + time schedule for the feature.

Make sure the user stories are correct and understood. Doublecheck the product owners userstory backlog to see if anything is missing or have been altered/corrected/specified. Start editing the feature documentation and add information you find valid and is important to have within it, as you move on with the planning.

Make sure all assignee's understanding of the feature and user stories are correct/aligned.

Create a concept/sketch of the issue either as a diagram of the user story, or a UI/UX quick-prototype/sketch to further visualize your common understanding.

Each feature have a pre-made issue. Are the issues currently added descriptive/concrete per action? Do we need to add more issues and divide the work per person to a new issue?

What kind of documents do we need for this feature? Is the current added documents within the product-requirement folder sufficient? Which specific documents do we need to create or use during the implementation and documentation of the feature?

Determine What needs to be setup locally

Tukko Front-end
Tukko Back-end

Read and understand the Tukko codebase, what is happening and see where the change must be implemented

Setup & branch rules

Create a branch from the master branch
Choose a Descriptive Branch Name: Start by selecting a meaningful name for your branch. For instance, if you’re working on the LAM station comparison feature, consider naming your branch something like feature/lam-station-comparison.
Then create sub-branch based on the number of developer's working on, refer this image

Implementation

Implementation, what would be required to start implementing the feature? Be specific, how should it be set up, for example do we copy the Tukko front-end or back-end projects locally and create new branches for those that start implementing changes? Do we have all info we need or do we need to add more? Are there certain frameworks we need to be more comfortable with and hence we need to familiarize with certain things?

Develop/ code your feature, use good semantics according to the guidelines set by WCAG 2.2 and comment the code so it is understandable by other.

Make sure to keep clean and up to date documentation during coding and make sure to keep track of your hours spent with the proper specificity e.g. familiarization, documentation, testing etc.

Peer-coding, we do not code or implement things alone. Some features may require coding and testing, so multiple people might be needed to work for different parts of the feature. Other features might be more of controlling enviroments and can be done by 1 person while reviewed and tested by another person.

Testing

Now the code/feature will be tested and if bugs found go back to Implementation.

Basic testing can be done by anyone and may be overlooked by niko but complex testing could be done by the tester role i.e niko or whoever steps up for the testing role.

Relevant test cases will be made to make sure the code works where it needs to and breaks where it needs to as well

Tester will document the testing/ cases.

Testing on the feature. Is the testing documents already added, and the folder structure surrounding it, good enough? Do we need additional documentation? Which documents in particular need to be created or made during the planning, implementation and testing of the feature?

Define how bugs will be reported and tracked.
Testing documentation will be stored in 50-Test management in gitlab
There are templates for the testing documentation in gitlab we will follow that format

Double-check!

Re-check and make sure all documentation is up to date and everything works as intended.
Make a checklist using the opf DoD and make sure all the elements listed in the DoD are completed

Communication

Have a meeting with the maintainer and get feedback and create a pull request.
Encourage developers to be open to suggestions

Release

Congrats! pull request accepted Enjoy!!

NOTE

as per the estimation the average workforce required per issue will be 2 developers and 1 tester.
if you feel the workload getting more than expected we can ask for more people
documentation for WCAG guidelines will be added.
total estimation hours may be found from the featurepricesynergy, this is just an estimate there can be hours.

Preliminary implementation and testing table:

Feature	Implementing Team	Testing Responsible	Comments
FEA407 Control Access to the Server	Noora	Ali, Markus	Sprint3
FEA112 Change Branding to Team/JAMK	Markus, Ali, Andreas	Niko, Ashutosh	Sprint4, same time as FEA106
FEA106 Improve Dark Mode Colors	Markus, Ali, Andreas	Ashutosh, Niko	Sprint4, same time as FEA112
FEA405 Implement Automated Security Testing Pipeline	Noora, Ashutosh, Niko	Ashutosh, Ali	Sprint4, same time as FEA403
FEA403 Regularily Scan for Known Security Vulnerabilities	Noora, Ashutosh, Niko	Ashutosh, Noora	Sprint4, same time as FEA405
FEA110 Enhance Color Contrast for Blindness	Ashutosh, Markus, Niko	Andreas, Ali, Noora	Sprint4 week 2
FEA101 Compare Different LAM Stations side by side	Ashutosh, Andreas, Ali	Niko, Markus	Sprint4 week 2
FEA409 Protect Application with Web Application Firewall	Noora, Niko, Andreas	Ali, Noora	Sprint05 week1
FEA406 Harden all the Containers	Noora, Niko, Andreas	Ali, Noora	Sprint05 week1
FEA105 Implement Web App Accessibility Measures	Markus, Ashutosh, Ali	Niko, Andreas	Sprint05 week1
FEA404 Enforce Secure Coding Practices	Noora, Niko, Ali	Ali, Noora	Sprint05, week2
FEA305 Localization for Norwegian	Andreas, Markus	Ashutosh, Niko, Markus	Sprint05, week2
FEA304 Localization for Swedish	Markus, Andreas	Ashutosh, Niko, Andreas	Sprint05, week2

Name	# Implements	# Tests
Andreas	7	3
Noora	6	5
Niko	6	5
Markus	6	4
Ali	5	6
Ashutosh	5	6