This webpage has been created to provide an HTML tour of our product and all associated deliverables. The tour has been organised into multiple slides with one slide per topic, and you can navigate through these slides using the "next slide" button at the bottom of the page. In this tour you will find pages which explain what DocDuck is, what work we have achieved so far, and how we have worked as a team.
Additionally, you will see sections based on each of our deliverables that summarise key components of the documents as well as links and references to all our completed documents
About DocDuck
DocDuck is a maintenance engineering app designed to assist with documentation in the engineering workspace, From keeping track of calibration, audit and diagnostic dates to having a full virtual library of every breakdown ever worked on and every part ever used or purchased. DocDuck is capable of all these features and more.
Quality Assurance Manual
The Quality Assurance Manual is used to ensure quality is maintained suring the project. The document is designed as reference for employees, clients and stakeholders.
It is intended to ensure that high quality and consistent standards are adhered to throughout the company's activities. The document establishes the framework for each role and their
responsibilities, the deliverables and project management and development methodologies
Each member of the group completed the section for their primary role. This ensures that they are understand the level of quality expected in their contributions to the project.
Each member has generated a list of risk managements and quality assurance metrics related to their individual responsibilites. This was to ensure a specific and measurable metric of quality. The QA Manual drafts were sent to the client for review and feedback was integrated for each draft. The final version was reviewed by the whole group and was updated after release
The Project Management Methodology serves as an important reference for the design and programming components of the project. It clearly lays out the specific method to be used for successful
implementation of agile development. This is to ensure that the programming created by each programmer is compatible with each other
Below are links to draft and released versions of the document:
The Function Specification outlines the functionality and requirements for the software. It is designed to lay out, in easy to understand terms, the specifics of the
project. The Functional Specification acts as a blueprint for the developers and designers when creating the program. The document contains sections describing:
Product Overview
Product Scope
Solution Overview
Functional Specifications
System Configurations
Other system and none functional requirements
Integration Requirements
The requirements and use cases are used to facilitate the ease of use of object oriented programming and agile development. The Project Overview and Scope ensure that stakeholders can clearly and concisely see the scope of the project so that they can easily understand what they are investing in.
To ensure that the Functional Specification was completed to a high standard, the individual subsections were divided between the group members. Draft versions were sent to the client for feedback which was integrated into the next release. The document was reviewed by the whole group prior to release and continued to be updated after release.
Below are links to draft and released versions of the document:
The Financial Business Plan outlines the financial goals and objectives for potential investors. It provides a detailed overview of the product, the company that will create it as well as the financial plans and strategies that will ensure the project meets its financial targets. The plan is designed to convince an investor to invest in the product and to give them the confidence and vision to support it.
The Financial Business Plan was completed largely by the Financial Managers with assistance from some other members.
The Business Plan uses graphs and tables to lay out the required costs for completion of the project, breaking these down into week-by-week and cost-by-cost bases. This allows a potential investor to see an accurate and itemised vue of where and when costs are expected to occur.
Below are links to draft and released versions of the document:
Below are links to the Financial Reports, which document the financial progress of the project. They are used to track our spendings compared to our assigned budget.
This slide aims to introduce you to DocDucks marketing strategies.
DocDuck is a cost effective and user friendly software designed with customers at the heart -
streamlining the machine management process for engineering startups and small businesses.
We have created a Marketing Plan which includes a detailed product analysis, pricing proposals and various marketing strategies.
The document contains the following sections:
Market Research - An analysis of key competitors, including MaintainX and Asset Panda,
focusing on their features, pricing, strengths, and weaknesses.
Unique Selling Points (USPs) - These highlight DocDucks distinctive features such as our
comprehensive repair logging system, friendly UI and advanced security measures.
Target Audience - This defines the primary users of DocDuck, specifically engineering startups
as well as discussing their needs and challenges.
SWOT Analysis - A detailed examination of our strengths, weaknesses, opportunities and
threats.
Marketing Strategies and Distribution Channels - How we plan to advertise our product and deliver it to customers
Customer Segmentation - A breakdown of the customer segments, focusing on the B2B
Business to Business segment. This looks at engineering startups, including their goals,
frustrations and what problems DocDuck can solve for them.
Marketing Plan
Our Marketing Plan outlines our strategies and approaches for promoting our product.
This document contains the following sections:
Competitive Market Analysis
Pricing Proposal
Design Theory
The Marketing Plan is included below.
A marketing portfolio has been created which goes into further detail on what is discussed in the marketing plan. There is
a link to view it here, however it is also included below:
https://app.validatestartup.com/portfolio/docduck
A questionnaire has been designed with the intention of gathering the insight of our potential users
and their opinions of our app. The questionnaire is created with Google Forms, URL:
https://forms.gle/questionnaire Participants have been asked 13 questions about their:
Occupation
Company Size
Machine Habits (Operating System / No. of Machines)
Software Preferences/Expectations (if they already utilise a maintenance software, and/or what their expectations are)
Consumer behaviour (pricing)
Opinions (about the interface, or if they have any questions)
The feedback from this survey will enable us to compare the critical assumptions we have made about our potential users against the real-world market.
The survey and ethics form required to complete market testing has been attached below.
Our product analysis contains market research of our competitors, our Unique Selling Points (USPs), our target audience, and a SWOT analysis.
This document is essential for aligning our marketing strategies and the making of one coherent plan. It is still in its draft form, containing contributions from Noah, Hari, Luke, Jabez and Josh.
The Project Wide Standard provides guidelines and rules to describe the expected elements in the XML documents to be interpreted by the software. It will be used to verify each piece of item content in a document, to assure it adheres to the description of the element it is placed in.
The project wide standard ensures consistency, maintainability, and collaboration accross the project.
The Project Wide Standard format we have decided to choose, is an XSD Schema. This is the simplest and cleanest method for providing the rules for XML files to follow.
As part of the requirements to buy in at least two media handlers, 5 contracts have been agreed between DocDuck and
BookCook. DocDuck is buying from BookCook java librarries designed to diplay audio and video and selling them libraries to display graphics and text.
The contracts lay out what the buyer expects in terms of payment and delivery schedule as well as coding and functional specifications.
Links to the signed contracts have been provided below:
An ammendment has been agreed between DocDuck and BoocCook to the Text Handler Contract to clarify the requiremtnes for input format of the library outlined below:
An additional contract has also been agreed between DocDuck and BookCook after the initial contract period for the sale of an addition to the Text Library outside the bounds of the original contract:
Minutes are taken during meetings to document the discussions during, and actions to be undertaken after, each meeting. Meeting minutes are filled in during the meeting by a QA and Documentation Manager.
An agenda for each meeting is set before it by a Project Manager and available before each meeting for group members to familiarise themselves
Links to the minutes and agendas have been provided below:
To track individual progress, a weekly timesheet/report has been used. This contains information of which meetings the employee has attended, how long they have worked each week, and what work has been completed each week. The reports should be ratified by a QA and Documentation Manager each week.
UX Designs with Figma and GUI Demo Designs with JavaFX and Gradle: On the left is a interactive login page for DocDuck and on the right is a UX design of a home page with scrollable text.
HTML Mockup Examples of our software application, includes the original GUI Demo, Admin page, Machine information page, Machine status page and login page , Click the link and scroll on each side of design
In our project we have an organisation on GitHub with multiple Repositories where we all contribute to documents from Overleaf (Latex), Java and HTML. .
On the Left is an example of Commits and Branches within out HTML tour and on the right is our Repositories for our project so far.
Software Development
To plan out all the software and assign tasks, we created an actively updated Gantt chart which between the Software Manager and Project Manager
was kept up to date throughout Semester 2.
Additionally at the start of the software planning, to have a rough outline of the initial creation of software a TODO list with a priority assignment
was created. This was used in the first couple of weeks by the Software Manager to create a plan and organise the group.
Additional resources were written by the Software Manager for the rest of the group to refer to and reference as and when needed.
These are included below.
