Project plan - OwlNavi/Taskvatar GitHub Wiki

Project Plan

What we are going to build

We are going to build a task manager app designed for children with behavioural disabilities that require a strict routine and are unable to organize themselves. Our app will help children to manage their task progress and through completion of tasks, earn in-app cosmetic rewards for a customisable avatar. We plan to add management features for guardians who can manage the children's schedule, assign new tasks and view statistics of the children task completion.

How we are going to build this

We are going to be developing for Android systems using Android studio. We plan to develop our features into the project by assigning features to a person responsible for its implementation. We will be using Git to manage our code base and track our project. We will have biweekly meetings(Wednesday/Friday) to discuss our progress.

Platforms app is going to run on

We are developing a native app which operates on the Android system Marshmallow and above. Android has the greatest market share of the mobile phone market (1). Previous versions of Android are no longer supported by security patches and Nougat (the version above Marshmallow) is currently the most used version of Android (1). By developing the app for use on a Marshmallow Android device, we assume most Android devices can run our app. In terms of development, the APIs included in Marshmallow are useable on most of Android devices. Developing our app on a newer version of Android runs the risk of using APIs not supported by previous version and therefore a large proportion of devices may not be compatible with our app. It is our objective to supply our app to as many users as possible keeping in mind our target audience is likely to have older or expendable versions of their Android device. The app is being developed in mind for use on a smartphone and tablet. It is estimated that worldwide there are over 2 billion users of smartphone devices where 80% of the smartphones are running a version of Android (1). Tablets are becoming increasingly popular with estimates of over 1 billion users worldwide (1). Smartphones and tablets enable the user a great deal of freedom, their portability and affordability make them more likely to be used by our customers rather than other devices.

Android devices such as smart TVs and home appliances are currently not being considered as potential devices to run our app. These are likely to be stationary within a home which although may for some cover most of time the app is use, it does not generalise well with all. Most users are likely to spend time away from home for long periods of time at work or school. Not all home appliances run the Android operating system and it is more likely that users are in contact with either their phone or tablet device oppose to standing at a refrigerator. Possibly however, we would aim to allow users to run on these stationary devices to increase availability and convenience.

  1. https://www.statista.com/statistics/271774/share-of-android-platforms-on-mobile-devices-with-android-os/
  2. https://www.statista.com/topics/3778/mobile-operating-systems/

Who is going to build it

In terms of developing the app, all members of our group will be expected to contribute to the overall project. The contribution each member will make is based on our current area of expertise. Joshua April 4741712 Shaun Henderson 6484285 Craig Thomas 5528391

Contributions

Shaun’s family and friends as testers.

Oliva (Teacher Aid), through an interview gave us a current understanding of what conditions children are currently experiencing within a schooling environment. We intend to interact with Oliva and a child from school to further our understanding during the development of our app.

Sasha works with an ADHD individual over weekends where she socialises and engages in physical activities with an individual. By interviewing her we hope to be able to better our understanding of how ADHD affects home life so we may make adjustments to features list to support home life as well.

How long to build it

We have been assigned specific dates as deadlines where we intend to give deliverables or progress reports to our supervisor (refer to deadline list) . In terms of actual development of our app, multiple articles which describe the type of features we are suggesting of putting into our app estimate that time of delivery would be 5 to 6 months (1,2,3). We are not expecting to fully complete our list of features within the time of the 345 course however we intend to build a solid foundation whereby our feature list can be implemented with ease after the final deadline.

  1. https://www.startupgrind.com/blog/how-long-does-it-take-to-build-an-app/
  2. https://www.entrepreneur.com/article/230750
  3. https://savvyapps.com/blog/how-long-does-it-take-to-make-an-app

Deadlines

  • Proposal, due 16th April
  • Deliverable one, due 28th May
  • Deliverable two, due week 4, Semester 2
  • Final deliverable, due week 12, Semester 2

Software Development Plan

  • How and when the software will be developed
    • Our software development plan is using the agile methodology. We will aim to develop features in small one week chunks, and during our Friday meetings we will have a scrum meeting to discuss what we have completed that week and what we plan to complete next week.
    • Weekly meetings (Wednesday 1-2pm, Friday 12-3pm) as a group to discuss progress and work in an environment where we can communicate easily
    • Programming done by splitting up tasks and working individually with open communications/collaboration so everyone is familiar with all aspects of the code base
    • Git to manage codebase, log changes, manage backups and version control. We also have project information available on the project git wiki
    • Travis will be used to manage tests and ensure our code base is well tested and ready to use in any version
  • Foreseeable problems and solutions
    • Technological challenges with git, android studio. These are technologies we are currently not proficient with and could prove challenging to work with.
      • Tutorials, learning, seeking advice will be how we overcome these challenges. During out bi weekly meetings we have the opportunity to discuss The issues we have with the technology with each other to solve these issues.
    • Compatibility with other technologies such as mail, google calendar. If we want to add additional features to our app involving using external applications we will have to learn the API’s required for those technologies. This will require more time spent learning unfamiliar material, slowing down our development of the project.
  • Constituent parts of the software using MVC pattern
    • Display/View
      • User/Child view showing task list, avatar
      • Parent view showing administration settings, task scheduling
    • Backend Model written in Java using Android Studio.
      • SQLite free android database system
  • Prerequisites
    • Hardware dependencies
      • Android devices
        • Tablet, phone
    • Software dependencies
      • Android
        • Android version 6.0 Marshmallow API level 23
      • Java 8

Validation Plan

  • How can we be sure our app does what it says it does
    • Software Testing will be used to ensure our menus and backend logic function as intended
      • We will use Travis to manage and run our tests during development
      • JUnit to ensure methods work as expected
    • User testing will also be to see whether the application meets the needs and intentions of the project and to find unexpected bugs. We can also see how our application could be used in new, unforeseen ways that could provide new areas we could develop in.

Management Costing

  • Hardware
    • Computers for programming two laptops, owheo building computer access
    • Samsung Galaxy Tab S
    • Samsung Galaxy S7
  • Software
    • Android Studio
    • Additional features need google calendar, email notifications (not gmail exclusive)
  • Staff
    • Shaun, Craig, Josh
    • Testers (unpaid)
  • Consumables
    • Pen, paper for sketching ideas, prototypes

Maintenance Plan

  • Changing software after delivery
    • When the Android version we are using no longer receives security updates it would be a good idea to upgrade to a newer version of Android such as Nougat for security reasons
  • Additional features. After the core features have been implemented we have ideas for new features that could be added if desired, listed in detail under the Advanced Features section of this document.
    • New avatar unlocks
    • iOS port
    • Synchronise with Google calendars

Staff Development Plan

How staff skills will be used and developed * Shaun * Android App experience * Git experience * Markdown * Craig * Java experience * Unit testing experience * Technical hardware skills * Josh * Programming experience * Research * Java This project contains technologies that are new for us. Staff skills will be improved as we learn the new technologies required for the project.

Task assignment

  • Shaun
    • Programming
    • Research
  • Craig
    • Programming
    • Note taking
  • Josh
    • UI guy
    • Programming
    • Research

Project Tracking

We use the Git project tool to manage tasks and assign them to a person so they can be worked on. This is visible and accessible to all of us so we can keep track of our own progress and see what others are working on.

  • Delivery Date
    • Plan: April 16th
    • Alpha: May 28th
    • Beta: S2 W4
    • Final: S2 W12
  • Budget
    • Time constraints. We all have busy schedules so time is a valuable resource
      • Weekly meeting times
        • Programming meeting Fridays 12-2pm to discuss what we have completed this week, and what we aim to finish for the next week
        • Management meeting Wednesday 1-2pm to discuss our progress on this week’s sprint in case we encounter difficulties working on the project and need to consult each other.
      • Programming time. We will need to find time in our own schedules to work on completing the features.
    • Likely no additional monetary costs as we are using hardware we have already purchased.

Risk Analysis

  • Staff member absences could cause us to fall behind schedule. Likely reasons for absences are:
    • Holidays
      • Shaun away mid semester
      • All not available on weekends
    • Workload from other courses
      • Reschedule meetings, or have meetings without them
      • Keep up communication
        • Wiki to keep documentation up to date
        • Facebook messenger to arrange meeting times
        • Project change log online through git
        • Git project tool to manage individual tasks
        • Progress tracking
          • Gantt chart
    • If we are behind in our schedule we will have to reevaluate our current schedule to ensure we meet this deadlines. This could mean more work done in a week, or cutting features.
  • Staff members not completing assigned work is a possibility.
    • Clear plans and channels of communication help to keep us up to date
      • Asking for help so we can understand the code and learn new techniques
      • Reminders on what is due that week during the mid-week meetings
    • If a task is urgent it will be re-assigned if possible so someone else will complete that feature
    • Replan to account for the delay by changing our schedule, adding more development time or removing features
    • Sack ‘em if they drag the group down as last resort
  • Staff member leaving
    • Reassess workload for two people by removing features into a more reasonable workload for the reduced team size
    • Find a replacement member so we can continue to work with three people, although time may be lost as we get them up to speed
    • Join another project/Start a new project if we are unable to continue with the current project.
  • Hardware issues may occur if a laptop is lost, broken or stolen.
    • Get new hardware if possible (cost dependent)
    • Keep online copies, backup so that no permanent loss of files will occur if a physical laptop is lost, Our code will be kept online on Github so that even if all our laptops are lost our code is kept available.
    • Our documentation will be available online with the Git wiki
  • Software issues
    • If Git shuts down we will lose our online code repository, Should that happen we should have a local copy we could upload to another repository source.
    • If the internet shuts down we give up on our project
    • Can’t resolve programming/tech issues
      • Ask for help from someone who can give advice
      • Nick code if we can find some code previously written that can help us out, provided it is legal to do so and we make note of the source
      • Reassess what you are trying to do and see if it can be done in a different way to avoid the problem
  • Requirements changing is a likely possibility. We aim to create a minimum viable product consisting of only the core features required for the app (task management). This means that our future schedule is easy to reschedule to meet and changing requirements. By keeping features in small week-long chunks we are able to keep our project in a working state at all times and easily adapt to requirements changing. However, if requirements change in a way that can make our previously completed work invalid then we will have wasted development time and have to reschedule our future plans to adapt to the new requirements
    • Replan
    • Reassess
    • Make do with what you have
    • Lower the scope