Prior to this meeting I completed a rough storyboard of how the process of creating an account and logging a support request would work, with the car repair idea.
Unfortunately I was unable to attend the meeting as I was ill.
The team decided to go with the bike hire idea – not my first choice I must admit! It was decided that the car repair idea had too many potential flaws and the possibility of the scope of the idea expanding too large.
We submitted our project sheet to Chris on Tuesday
So far this week I have reviewed the lecture material, considered group project ideas and met up with my group for the first meeting of the week.
Before the meeting I looked at the ideas that we had come up with and tried to decide what were the best ones in my opinion. The way I did this was by considering is there a market for this kind of product, are there similar products and if so, how could we make it better and finally – is it technically feasible or too ambitious (too much scope). Some of my favorite ideas before the meeting were:
During the meeting we went through each individual idea, removing the many mobile application ideas that we came up with, in favour of a web based IT solution. We discussed the scope of what we could include with some of our favorite ideas, we ended up with two ideas to take forward to Tuesday’s meeting tomorrow:
Tom and Sam were tasked to look into Aber bike hire – by writing down the possibilities of what the site would include, also they were going to come up with some ideas of how the user would hire bikes or suggest events to be advertised.
Seb and I were tasked with looking into the car repair idea. I was tasked to come up with a basic storyboard, so that everyone could understand how the process of advertising a service request would work. This was suggested to get rid of ambiguity as everyone had different ideas of how it worked.
Ian was tasked with critical analysis of both ideas – picking potential holes and risks with these ideas.
The previous lecture was pretty packed (with information) – plenty to take in.
I learnt that deciding the scope of the system is very important, this should be done early by nailing down the right requirements. If this stage is not followed thoroughly at the start of the project then things could keep cropping up – an added feature here, an added feature there, a missing feature that some people thought would be included. This could lead to over-runs as the project gets more complex, or the development of a system that is not fit for purpose. A lot of the background to this was covered in 1st and 2nd year lectures, such as Software Engineering lifecycles.
Chris went through the various processes involved in deciding the scope of the system and deciding on all of the requirements, this included – Rich pictures, Scenarios / use-cases, Storyboards, user evaluation, DFDs and identifying risk.
One of the processes, Rich Pictures, sounds like a great way to visualize how people would interact with the product and can help you decide whether the product / service is a viable one. This is done by placing the product in the middle of a blank canvas, then add the various people, groups or organizations that may have some involvement in it. For example an app that advertises local businesses would have stakeholders such as:
If we did all of this small stages in the group project, documenting as we go along, we’ll end up with a section of documentation regarding the scope of the system.
Other than that, the lecture had a quick few minutes at the end regarding next year’s project – this is recommended to be web based, the core processes at the beginning will be the same as in this group project, however as it needs to be built there will probably need to be more analysis.
I booked my car into the garage this week, as there was a problem that needed to be diagnosed. When they were booking me in they asked when was convenient for me, I told them “Wednesday afternoon”, the person I was speaking to said “I’ll just take a look”. I then heard the ruffling of pages, I though to myself “why can I hear the sound of a diary?!”.
Therefore another idea is developing a database with at least an interface for the service provider, so that the garage can book cars in and place a date and time for it in the calendar. There would be scope for developing a web interface, so that clients could retrieve service progress details. Using this system, the garage could allocate resources to particular tasks if applicable, so that they know when staff are free. Instead of ruffling through the diary they could view the jobs in the calendar graphically, allowing more productive administration and more effective resource use.
One consideration would be – Outlook calendars (or other calendaring) is a basic and cheap solution to this problem, this system idea would have to offer additional functionality to appeal, such as offering more bespoke features for it’s purpose.
This week was ideas week! A fun start to the project where the group must gather a large amount of business ideas for our project.
We decided to hold a group meeting after the weekend – this gave us time to think about ideas individually and research some of them a little, before meeting up, brainstorming and sharing our ideas together to come up with a list.
I spent some time thinking about what applications or websites may interest me, did some research on whether these things existed yet and noted down anything that may have a market or an untapped market.
I came up with about 8 ideas before the meeting, here are four of them:
During the meeting we all exchanged ideas and had a bit of a laugh at some of the more rubbish ones that were suggested, baby name generator to name one. Here are the ideas that we came up with:
Meeting time: 2 hours. Personal time: 2 hours
I learnt about some previous projects and found it is important to consider whether a dedicated mobile app is really necessary, or whether a mobile version of a website is just as adequate or if not better. In many cases, a mobile website is preferable due to the reduced development time needed and it offers cross platform accessibility. Although mobile web development is getting better, the drawback can mean including less custom features, like using the operating system’s API to perform a task (e.g. take a picture).
I learnt that the BIT Group Project would involve coming up with a number of ideas, of what we could propose to implement. This initial list of ideas should be wide ranging without a huge amount of worry about the pros and cons, as these can be sorted out later and ideas whittled down.
We were instructed to organise ourselves into groups. I spoke to a few colleagues, so we got together into a group of 5 – covering a range of skills such as business, writing and technical skills. The combination of people should make a good team to work on the project.
I headed ofwer to WordPress to create a blog, I called the site jcj9 (my username) so that the URL is https://jcj9.wordpress.com. I will blog about what I’ve learnt this week and document the progress of what I have done this week and what we have done as a group.
Summary: Setting up and writing the initial blog posts, reviewing the lecture slides, organizing in teams and have been talking to my new group colleagues. Estimated time: 2 hours.
Andy went through the introductory lecture and showed us the slides that Chris Price had produced. This introduced us with a breakdown of the module and discussed the Group Project involved including how were would proceed (e.g. with deadlines).
Apart from the general breakdown of the course, I learnt that projects needed to make business sense, but also they must be technically sound.
An example given by Andy was an app someone suggested where you take a picture of the contents of your fridge, then the app would suggest what you can make out of the ingredients:
Web Based Major Project 