search

EvitaKnits / hitch-hound

Assessed Project Four for my Code Institute Diploma
0 stars 0 forks source link

readme

CI logo

Hitch Hound: a lightweight issue-tracker

'Hitch Hound' is built using Django, Python, Bootstrap, JavaScript and PostgreSQL. It is hosted on Heroku. Automated testing is done with Jest (JavaScript) and Unittest (Python).

(Add responsive screenshot here)

Table of Contents

  1. Purpose
  2. Requirement Gathering and Planning
    a. Brief Competitor Analysis and Target Demographic
    b. Data and Security features
    c. Epics and User Stories
    d. User Journeys
    e. User Permissions
  3. Data Design
    a. Database Schema
    b. Data Manipulation
    c. Data Validation
  4. User Interface Design
    a. Computer Wireframes
    b. Mobile Wireframes
    c. Colour Scheme
    d. Icons
  5. Testing
    a. Test Plan
    b. Automated Testing
    c. Manual Testing
    d. Browser Compatibility and Screen Size Responsiveness
    e. Key Responsiveness Differences
    f. Accessibility
  6. Bugs
  7. Deployment
  8. Agile Methodology
    a. Sprint One
    b. Sprint Two
    c. Sprint Three
  9. Credits

Purpose

The objective of this program is to streamline the process of tracking and communicating about issues and bugs arising in software development projects. It is lightweight and intuitive, providing ample functionality for small to medium enterprises who don't need an elevated level of auditing and oversight.

Requirement Gathering and Planning

Before starting the coding for this project, I created a detailed plan including my database schema, user journeys and wireframes.

Brief Competitor Analysis and Target Demographic

When considering competitors in the realm of issue and bug tracking software, it's helpful to look at some well-known options. Atlassian's Jira is widely recognised for its range of features and flexibility, making it a go-to choice for companies of all sizes. Another popular option is GitHub's issue tracking system, which seamlessly integrates with its version control platform, making it a convenient choice for teams already using GitHub. Additionally, tools like Trello are valued for their user-friendly interface and adaptability, though they do lack some of the specific features tailored for issue tracking. In this landscape, my program intends to stand out by focusing on simplicity and ease of use, making it ideal for small to medium enterprises (SMEs) looking for a straightforward solution without unnecessary complexity. The goal is to provide a practical and efficient tool for managing software development issues, offering a simpler alternative in a market dominated by larger, more complex platforms.

Data and Security Features

With this in mind, the data features chosen are clean and simple. Users can create issues that they associate with a particular project. This allows for a streamlined and intuitive user experience, enhancing productivity and facilitating effective project management.

The security features cover the essentials: authentication with a username and password, data validation and sanitisation, and keeping track of any changes made with an audit trail.

Epics and User Stories

My user stories can be seen in full in the associated GitHub Project on my repo. This is where all the details, including tasks and acceptance criteria can be seen. These user stories have been assigned to Epics.

Epic 1: User Management

Epic 2: Issue Management

Epic 3: Notifications and Error Messaging

Epic 4: Enhanced Issue Management

Epic 5: Project Management

Epic 6: Reporting

User Journeys

As a lightweight issue tracking program, my goal was to make each user journey as simple as possible with the fewest steps, whilst still providing value and flexibility of working method. There are ten core user journeys. The below is not an exhaustive list of all possible user journeys, just the most important ones:

  1. New User

    flowchart LR
A[Navigate to Hitch Hound] --> B[Enter details on Sign Up form]
B --> C[Click Sign Up button]
C --> D[Log in with email and password]

  2. Create an Issue

    flowchart LR
A[Log In] --> B[Click '+'\n button]
B --> |New Item \nPopup|C[Click 'Issue'\n button]
C --> D[Fill in New\n Issue form]
D --> E[Click 'Submit \nNew Issue' button]

  3. Browse Issues

    flowchart TD
A[Log In] --> B[Click 'Issues' in\n the navigation bar]
A --> C[Click 'Projects' in\n the navigation bar]
A --> D[Click 'Reports' in \nthe navigation bar]
A --> E[Click on User Profile\n in the navigation bar]
B --> F[Scroll through issues\nand click through pages]
C --> G[Click 'View All Issues'\nbutton next to the \ndesired project]
D --> H[Click on 'Issue Listing \nby Status' button]
H --> I[Select status in dropdown]
E --> J[Scroll through issues\n and click through pages]

  4. Edit an Issue

    flowchart LR
A[Log In] --> B[Navigate to an issue as per \n 'Browse Issues' user journey]
B --> C[Click\n 'Edit Issue']
C --> D[Amend details\n or add a comment]
D --> E[Click\n 'Save Issue']

  5. Close, Cancel or Delete an Issue

    flowchart LR
A[Log In] --> B[Navigate to an issue as per\n 'Browse Issues' user journey]
B --> C[Set status to 'Closed'\n or 'Cancelled']
B --> E[Click 'Delete Issue']
E --> F[Confirm deletion]
C --> D[Click 'Save Changes']

  6. Create a Project

    flowchart LR
A[Log In] --> B[Click '+'\n button]
B --> |New Item \nPopup|C[Click 'Project'\n button]
C --> D[Fill in New\n Project form]
D --> E[Click 'Create \nNew Project' button]

  7. Browse Projects

    flowchart LR
A[Log In] --> B[Click 'Projects' in\n the navigation bar]
B --> C[Scroll through projects\n and click through pages]

  8. Edit a Project

    flowchart LR
A[Log In] --> B[Navigate to a project as per\n 'Browse Projects' user journey]
B --> C[Click 'Edit\n Project' button]
C --> D[Amend\n details]
D --> E[Click\n 'Save Project']

  9. Delete a Project

    flowchart LR
A[Log In] --> B[Navigate to a project as per\n 'Browse Projects' user journey]
B --> C[Click 'Delete\n Project' button]
C --> D[Confirm deletion]

  10. Generate Reports

    flowchart LR
A[Log In] --> B[Click on 'Reports' in\nthe navigation bar]
B --> C[Click on one of the\n available report buttons]
C --> D[Adjust settings as needed\n with dropdowns provided]

User Permissions

There are four types of user, each with different permissions.

Type Can create issue? Can change status to Can close issue? Can access admin panel?
Role Based
--> Developer Yes In-Progress No No
--> Quality Assurance Yes Testing No No
--> Product Manager Yes Approved Yes No
Secondary
--> Superuser Yes Any Yes Yes

Each user must be assigned a role-based type and may also be assigned the superuser type additionally.

Data Design

Database Schema

The following Entity Relationship Diagram (ERD) illustrates the key entities and relationships in Hitch Hound. It defines the relationships between Issues and all other entities.

erd

*Added mid-development: A 'Project ID' to be the primary key for the Projects table. This was required because at the time of designing my database, I didn't realise that it is not possible to edit a primary key. Therefore the title could not be the primary key because the title needs to be editable by users.

Data Manipulation

Hitch Hound uses CRUD principles to guide all data manipulation.

Issues

Projects

Other Data

Data Validation

The following data validation rules ensure the accuracy and reliability of information stored in the system, ensuring all entries adhere to expected formats.

Users

Projects

Issues

Comments

Changes

User Interface Design

Computer Wireframes

The wireframes I created illustrate the core user interface and functionality of Hitch Hound from both a desktop/laptop perspective and a mobile/tablet perspective. These visual guides serve as a blueprint for the design and structure of the application, ensuring a cohesive and intuitive user experience.

Home: Sign Up

signup

Home: Log In

login

Home: Logged In

loggedin

Individual Issue

individualissue

Issue Change History

changehistory

New Issue

newissue

Projects

projects

Individual Project

individualproject

New Project

newproject

Edit Project

editproject

Reports

reports

User Profile

userprofile

Notification Modal

notificationmodal

404 Page

404page

Mobile Wireframes

Sign Up Log In
signupmobile loginmobile
All Issues Individual Issue
loggedinmobile individualissuemobile
Issue Change History New Issue
changehistorymobile newissuemobile
Projects Individual Projects
projectsmobile individualprojectmobile
New Project Edit Project
newprojectmobile editprojectmobile
Reports
reportsmobile
User Profile Notifications
userprofilemobile notificationmobile
404 Page
404pagemobile

Colour Scheme

I wanted to pick a muted palette to reflect the business nature of my program. I chose my base colour and then selected two lighter shades to implement as a gradient. I then desaturated my base colour by 90% to find a complementary charcoal grey. Finally, I lightened my colour by 95% to find a complementary cream colour.

colourscheme

Icons

As I had chosen the name 'Hitch Hound' for my program, I thought it would provide visual interest and be a fun twist, to include dog imagery in my logo and icons.

Logo

This dog in a shield was perfect for my logo:
shield

Other

There were also a few other options for use throughout the program:
dog paw bone

Testing

Test Plan

Continuous Testing I developed this program using the 'red, green, refactor' approach

Through a combination of automated testing written using Jest for JavaScript and Unittest for Python, and manual testing from the front-end, I achieved a good coverage of test cases. The code I wrote was also passed through validators/linters at the end to ensure adherance to coding standards and best practices, ultimately aiming for robust and maintainable code.

Automated Testing

Jest Testing:

Unittest Testing:

Manual Testing

My manual testing covered:

Browser Compatibility and Screen Size Responsiveness

I viewed the program on each of the three key screen sizes (mobile, tablet and computer), using devtools, on four of the most popular browsers. I also used the responsive setting to slide the width of the screen from narrow all the way through to wide to check the transition points.

Pixel references for each of the screen sizes:

Screen Pixels
Mobile - iPhone SE 375px
Tablet - iPad Mini 768px
Computer 1366px
Browser Screen Size Appearance Responsiveness
Chrome Mobile
Tablet
Computer
Transition Points
Firefox Mobile
Tablet
Computer
Transition Points
Safari Mobile
Tablet
Computer
Transition Points
Edge Mobile
Tablet
Computer
Transition Points

Key Responsiveness Differences

The

Code Validation

Language Validation Method Outcome
HTML W3C HTML Validator X errors. All resolved.
CSS W3C CSS Validator X errors. All resolved.
JavaScript JS Hint X errors. All resolved.
Python PEP8 Code Institute Python Linter X errors. All resolved.

Accessibility

Lighthouse To ensure the front end of my program was accessible I used Lighthouse.

Here are the results: (screenshot)

Colour Contrast I also checked the colour contrast using of my color palette combinations using Coolors

Alternative Text I ensured I had set alternative text for the only image on my site: the logo.

Bugs

Here is the list of bugs mostly found towards the end of development when I encountered functionality not working as intended that I had previously thought did. I don't believe I have left any unresolved bugs.

Bug One

Issue

About halfway through development, I tried to change the primary key of my 'Project' model from the 'Title' field to a new 'Project ID' field. This was because I had discovered that it is not possible to edit a primary key, so if a user wanted to change the title of their project, they would not be able to do so. Whilst making this change, I also found that Django automatically assigns an auto-incrementing ID to every model you create. I may have learnt this at some point, but because this auto-assignment is implicit and not actually visible in the files I was working on, I did not realise.

I had to delete the ID fields from all my models and recreate my database. The issue this ultimately created was that I had been working for quite some time on the original data models and they were intertwined throughout my functionality. Making this change broke a significant portion of my existing functionality.

Solution

The solution to this was going through systematically, encountering errors and resolving them until all references to IDs had either been removed or switched to the auto-assigned ones in Django.

Deployment

This project was deployed to Heroku: a hosting platform.

These are the steps I took to set up my infrastructure and deploy my app: 1. 2. 3. 4. 5. 6. 7.

  1. I created a new repository on my GitHub from the Code Institute template and named it 'hitch-hound'
  2. I opened this repo on my IDE and
  5. Next I clicked on the 'Deploy' tab and connected my github repository code to the Heroku app. I clicked 'Enable Automatic Deploys' and Heroku deployed the app for me. Once this was done, the link to the app appeared and could be clicked to go to the deployed app.

Agile Methodology

I set this project up in GitHub projects using agile methodology. This facilitated my prioritisation and time management. I added all the user stories as issues and then divided them into 'MVP'(Minimum Viable Product) and 'Future Enhancements' to signify what I intend to complete for my assessed project and what could come later. Those MVP stories were then stack-ranked. I added three one-week sprints to the project and filled my first sprint with my intended work according to the MoSCoW prioritisation system.

Sprint One: 05/06 to 11/06

Sprint One

Sprint Planning

Sprint planning involved taking the highest priority issues from the top of the stack and assigning them to the first sprint. I marked the first three as 'Must Have' for this sprint, the next one 'Should Have' and the last two 'Could Have'. This gave me a breakdown of 50% for must, 16.6% for should and 33.4% for could. If I achieve all of these user stories in the first sprint, I will have completed my first epic: User Management.

Sprint Retrospective

Sprint Overview: During my initial one-week sprint, I completed the user story for 'Create basic front-end'. This task involved laying much of the foundational work for my project.

Achievements:

Progress:

Challenges:

Action Items for Next Sprint:

Sprint Two: 12/06 to 18/06

Sprint Two

Sprint Planning

For the second sprint, I carried over the same stories I had planned for the first sprint but not finished. I did not include any more because experience has shown me that I am unlikely to get all these stories finished. Therefore only 40% of the stories are must have, 20% should have and 40% could have. With more time this sprint, I should be able to complete the must have stories at a minimum.

Sprint Retrospective

Achievements:

Progress:

Challenges:

Action Items for Next Sprint:

Sprint Three: 19/06 to 25/06

Sprint Three

Sprint Planning

For the third sprint, I carried over one story and put back another story, towards the bottom of the backlog as I realised I would not be able to sort out all the permissions until I had the bulk of the reset of the development complete. 50% of my stories for sprint 3 are must have, 25% should have and 25% could have. If I manage to complete these, I can always pull in some more stories.

Sprint Retrospective

I realised after the sprint had begun, that I needed a user story for creating the user profile page. I'd missed it when initially writing up my user stories. This has a list of issues assigned to the user on it however, so needs to be done later on in the project. I created it and put it further down the backlog.

I also picked up speed this sprint and completed all four of the planned user stories by the middle of the sprint. I pulled in four more, labelling two of them 'Should Have' and the other two 'Could Have' as I had already met my sprint commitments.

Sprint Four: 26/06 to 02/07

Sprint Four

Sprint Planning

For my fourth sprint, I carried over two of the four I pulled in half way through, and added five more stories for a total of 7. I've got 3 must haves, 2 should haves and 2 could haves. I do have quite a large issue to deal with first but I feel as though I am into the flow of how Django works and what my project should do to be able to work with this split.

Sprint Retrospective

Sprint Five: 03/07 to 09/07

Future Development

Likely to be, at a minimum:

Credits

APIs and Third Party Libraries

Sources

I referred back to the Code Institute set up videos to remind me how to set up the APIs, credentials and files before starting coding.

I also used the documentation of all the elements included in this project:

General Credit

As ever, I want to thank the open source community for the great resources that teach me so much and also remind me of what I learnt in my Code Institute lessons.

I believe I have specifically credited where I used specific items in the previous section but this is a general credit to the reference resources I looked through to teach me new elements as well as reminding me how things I'd already come across worked as I went along.

Every effort has been made to credit everything used, but if I find anything else specific later on that needs crediting, that I missed, I will be sure to add it.