The Timeline/Schedule for the deliverables

[Edward-Nivison]

I have begun a basic outline of the schedule/timeline that we could expect in the coming weeks. Nothing is really set in stone there but it is a start to it. I reckon if you would like to add your own thoughts to what you think you could achieve feasibly in the coming weeks to the schedule that would be good. Because at the moment we have a lot of theoretical so we need to start getting into the backend and frontend of the solution. And since we have a fairly large team we should be able to have a split working team to do both the frontend and backend simultaneously. But we need to be on top of team meetings and communication between the two development areas to have a product that will work together. (e.g., Backend needs an interface to talk with the frontend and vice versa). At the beginning, we will likely be working all together to get things started but as we understand the vision of the product and the structure of the code, we can work a bit more on the deliverables we need to achieve.

Let me know your thoughts and I will have below what is also in the Statement of Work (as a draft, maybe we should get it formalised into a Gantt chart, or GitHub Project).

Week 1: Team Formation Week 2: Client Meetings, Statement of Work drawn up, Landing page, GitHub, assignment of roles. Week 3: Audit 1, Backend leader will decide on a codebase to use, Frontend leader will begin researching frontend solutions (more than already skimmed). Week 4: Structure will have a basic layout, a plan of action for what needs to be completed first will be drafted, and likely a new Statement of Work drafted as well. Week 5: Developers will work on getting deliverables and milestones completed efficiently.

[Edward-Nivison]

@alexdboxall @matthewcawley02 @sineeha-Kodwani @mazfil @RachelCaoCC @Hexuan-Meng

[alexdboxall]

That looks good to me - once we get the project going we formalise it a bit more using tools/charts, etc.

And do we have a specified end date for the project (for when we want the whole thing done), or is it too early to tell? I'm looking at writing the success criteria, and something about the timeframe we expect to deliver the solution in would be good to have.

[Edward-Nivison]

And do we have a specified end date for the project (for when we want the whole thing done), or is it too early to tell?

I reckon that we could ask the Tutor that question and also possibly bring it up in the next client meeting we organize. It is likely mention in the Program Dates about when the general project should be finalised (at least for the semester, as it could continue next semester or be cancelled or have new members, etc).

[Edward-Nivison]

Anything that we can think of that is a feature in the program and necessary element to the program. For example, the algorithm is a good one, the ui, the backend, the front end, etc. But then for each of the major deliverables we have to also split them up into more manageable deliverables (i.e, meaning that they can be feasibly completed in a small amount of time). So you could split things into their functions, and basic use case (so for the ui, which is the only thing I can visualise at the moment, would be things such as the input fields, the output display, the security (logins,etc.) ) anything you can think of in that regard. It can be a wider scope at the beginning but in future iterations of the SoW we should more closely define what we are planning to achieve.

I am just recording this that I sent to the Teams chat in response to a question from Filip about the deliverables.

Further discussions of deliverables are also found in Issues #12 , #3 , #14