Archive for category Structure and Story
Determning a Project Methodology
Posted by Po Ting Tse in Contextual Factors and Research, Design, Structure and Story on 13/03/2015
Introduction
The group are currently using Scrum (Schwaber,1997) for the software development process. This post is going to explain the group’s choice among existing methodologies, the advantages, and the possible issues the group may have with this approach. Determining a methodology that a group should follow is a vital part of producing a project that will fulfill the success criteria. This is due to the project requiring many steps and many contributions from different members. This means that in order for this to occur to a high standard the group must all follow the same method, understand that method, and be able to work as a group to achieve the same goals. Therefore choosing a methodology that suits both the group, the project, and the success criteria is important.
Traditional waterfall model
Traditionally Software Development Life Cycle, or commonly known as the waterfall model, has been adopted in software development. It is well known of its cascading development stages, in which the stages are be followed in sequential order, as shown in Figure 1 below. These include feasibility study, systems investigation, analysis, design, development, implementation, and maintenance ( E. Avison & Fitzgerald, 2003).
Figure 1 The waterfall lifecycle for software development (Vidgen, 2002).
Before starting the next phase previous phases have to be completed (hence the term waterfall), and each phase has a set of defined outputs or deliverables to be produced before it could be deemed complete ( E. Avison & Fitzgerald, 2003). As the world became fast-paced and technological requirements changed frequently, people soon discovered the weaknesses of this approach and start to embrace the agile methodology.
Weaknesses of the Waterfall model
Firstly, the waterfall model fails to meet the real needs of the business world (Avison & Fitzgerald, 2003) as the technological efficiency improvements are at the operational level, detracting from the business needs. Consequently the project sponsors also focus on the project investment, as well as the return and benefits through the system.
Secondly, over conservative systems design is an apparent limitation ( E. Avison & Fitzgerald, 2003). Since the model emphasises the existing system as a basis of the new system, there is limited creativity for developers to implement the new one. Thirdly, instability is apparent as the modeling of processes could be unstable due to changing businesses and markets. Subsequently it is difficult to develop a suitable and stable model. It becomes a burden for developer to implement the program as the modeling is varied.
In addition, inflexibility of the model, the inability to change requirements, leads to further limitation (Vidgen, 2002). The methodology makes a number of simplifying yet invalid assumptions (such as a stable environment, a well-documented business strategy, users knowledgeable about their own requirements, or that a consensus of requirements can be achieved). However, such conditions rarely exist in practice.
Next, user dissatisfaction ( E. Avison & Fitzgerald, 2003). According to problems with computer-oriented documentation, users are not allowed to browse the prototype of the system before it is completed. The user involvement is limited and they may feel uncertain since nothing could be seen when the system is incomplete. In addition to this the problems with documentation produce further limitations ( E. Avison & Fitzgerald, 2003) since the document is full of information, developers have to assume they understand what they need, instead of referring users’ needs.
Finally, application backlog is a tangible limitation ( E. Avison & Fitzgerald, 2003) as the maintenance workload can be large. As a result attempts are made to change the system in order to reflect the change of user needs. The above weaknesses raise the urge of methodology evolution. In order to fit in the fast paced environment, the group decides to adopt the agile methodology. The next paragraph will explain why the group choose agile for software development.
Agile’s advantages and limitation (Cohen, et al., 2003)
Unlike traditional waterfall model, agile software development is known as its rapid and iterative approach (Highsmith & Cockburn, 2002). It highlights the most important parts, which the crucial parts will be accomplished first. This can gain confidence to the team, and project sponsor will be easily satisfied with the project in the early stage.
A strength of agile is embracing change and continuous development. As customers are the essential part in the team, they can come up with their ideas and thoughts immediately to the team. There is no communication lag between developers and customers. Time is saved and a prompt responded development can be performed. Next, agile software development enables the team to work effectively as a cohesive unit, which can improve productivity by several times. Team work is highlighted as cooperation enables greater productivity. Team members show their various expertise, understanding of the schedules and work cohesively, so the burden or difficulties can be solved together quickly..
Agile software development is a simple, elegant and correct solution found by true domain expertise and experience. Under this aspect, software can be maintained efficiently,as everything is simple and intuitive. The new comer can easily come up with ideas of the development, which we think is better for maintenance than the waterfall model.
Why the group will use Scrum for the project
Among popular agile approaches, the group decided to use Scrum due to its substantial benefits in comparison to other methodologies. Scrum is an incremental, time-based development (Rising & Janoff, 2002) with frequent meetings (i.e. Sprint). It embraces requirement changes, and is suitable for small team that working individually. This methodology works the best for the group as group members prefer to discuss and contribute ideas and research, rather than one person focusing on a large part. The group will have one to two meetings each week. In each week, the group will decide the next parts and corresponding job division, similar to the basic questions required in every Scrum meeting. The group meetings will last between 30 and 45 minutes each, one of which the mentor will join the group.
Conclusion
After a comparison of different methodologies the group has adopted the Scrum methodology because of its advantages. Since the application is user-oriented, user involvement in the whole development process is crucial. The group hope the project can achieve success with Scrum.
This post represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding how best the group works towards a joint goal. These are based on a literature review which explains why the outcome was chosen and how the group will implement it. There is evidence that the methodology has been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
It is also evident that based upon the Contextual Considerations, literature review and analysis that appropriate Design steps for the product have been chosen intelligently. This is shown by the conclusion of picking a suitable methodology for the group and explaining its choice and how it will shape product development. This choice further represents the Structure and Story of the portfolio by dictating the methodology used.
References
Avison, D. & Fitzgerald, G., 2003. Information systems development: methodologies, techniques and tools. 3rd ed. s.l.:McGraw Hill.
Cohen, D., Lindvall, M. & Costa, P., 2003. Agile software development. DACS SOAR Report, Issue 11.
E. Avison, D. & Fitzgerald, G., 2003. Where now for development methodologies?. Communications of the ACM, 46(1), pp. 78-82.
Highsmith, J. & Cockburn, A., 2002. Agile Software Development:The Business of Innovation. Computer, 34(9), pp. 120-127.
Rising, L. & Janoff, N. S., 2002. The Scrum software development process for small teams. IEEE software, Volume 17, pp. 26-32.
Schwaber, Ken. “Scrum development process.” Business Object Design and Implementation. Springer London, 1997. 117-134.
Vidgen, R., 2002. Developing Web Information Systems: From Strategy to Implementation. s.l.:Butterworth-Heinemann.
By Po Ting Tse
Meeting Summary 12/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 12/03/2015
Meeting Summary 12/03/2015
During this meeting the group discussed the progress that had been made with researching specific app features that would contribute to the product. Progress was evident, and the group extended the deadline for these tasks due to other module assignments occurring in parallel.
For the next meeting
For the next meeting the group will have posted individual posts regarding the specific features, with each containing a summary of how this may be utilised for the product. This may include differences in technical requirements or types of data that may need to be used. As a result the group has concluded that research into types of dataset that correspond to a free app should be conducted in order to allow the product to fit in with the market analysis.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Meeting Summary 09/03/2015
Posted by Briony Gray in Meeting Summary, Structure and Story on 09/03/2015
Meeting Summary 09/03/2015
During this meeting the group discussed the research that had been conducted in the previous weeks, and how that fit into the time scale decided by the planning posts. The group then discussed the short-list for app features based upon market research. It was decided that expert opinions should be asked in order to help determine which features may be more useful than others, and that group members should identify individuals that they feel were particularly relevant to our project and were willing to answer some questions. These individuals should be recorded communally, and made clear that consent would be required in order for the group to publish any feedback to the portfolio.
For the next meeting
It was decided that based upon the expert opinions, group discussion and literature review that each member should select a specific app feature and research this in more detail to further ascertain whether it would make a valuable contribution to the product, and would meet the success criteria. The short-list was narrowed down to five areas which were highlighted by existing market analysis to be important. These are:
– Safest Route Generator
– Safety/Reliability rating of area
– Travel updates information
– Location/safety tips
– Downloadable pack for offline use
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony.
Shortlist for App Features
Posted by Briony Gray in Design, Engineering, Structure and Story on 07/03/2015
The group is now in position where a wide range of background research has been conducted. This takes the form of Similar Applications, Market Research and Literature reviews for specific features. Consequently, determining a short-list of features which the TravelSafe app will utilise is the next design and engineering step of the project. As the project has the final objective of producing a fully researched and designed idea which is then ready to be subjected to qualitative and quantitative testing (which will require more funding and time than a group project is able to), we have enlisted the help of individuals who are considered experts in their field. In order to objectively evaluate the short-list of app features we have used purposive sampling to select a number of experts from ranging backgrounds. These include Engineering, Web Applications and Solutions, Web Master, and Senior Technical Advisor. This is a guidance solution regarding how we should structure and decide on the features of the TravelSafe app without breaching extensive qualitative and quantitative testing.
The experts were identified as being useful or relevant to our project interests, and then were contacted via email. This provided an easy medium for conversation without being formal. Initial contact with the expert explained our project scenario and requested that, if they were willing, should read the short-list of TravelSafe feature apps and answer 4 short questions regarding these. In addition we strongly encouraged any other thoughts or guidance throughout. Each expert gave permission to use their name, job title, expertise and answers in our portfolio. The feedback received can be found in the Expert Opinions post.
The short-list which the experts were presented can be found below:
1. Safest Route Generator – This generates three safest routes from point to point in real-time
2. Area Information Safety Rating – This is used for areas using open data crime statistics and social media
3. Local Travel Information Updates – This provides local bus and train times, locations of these, and weather information Weather updates.
4. Safety Information – This is generated from locational based RSS feeds from embassies, social media and news feeds.
5. Emergency Contact Information – This is done through user input which an individual stores travel information such as flight numbers, travel insurance, credit card numbers, and emergency contact details.
6. Downloadable Resource Pack – This allows the user to choose a location and download above features (such as travel information or safety information) which can be accessed while offline. This combats roaming charges while travelling.
7. Blogging Features – e.g. photo and video with GPS location – Links to social media e.g. photo and video
post uploads, blog posts.
8. Family Alerts – This features a danger button to send location to designated contacts, and/or emergency services or the police.
9. Flight Information – This provides information from airport/airlines with notifications for specified Pack offline.
This post also represents that the group has chosen appropriate design and engineering choices that directly link to the marking criteria, which are vital to understanding which features that the product will have. These are based on Contextual Factors such as market analysis, evaluation of existing products, and identification of app features. There is evidence that the design and engineering steps (app features) have been chosen intelligently (by reference to literature and analysis) to produce a conclusion of professional quality, leading to a successful product.
In addition there is evidence of Structure and Story, as the post explains why these were chosen, how they were chosen, and that these will shape the development of the project.
Written by Briony.
Meeting Summary 05/03/15
Posted by Taekyun Kim in Meeting Summary, Structure and Story on 05/03/2015
Meeting Summary 05/03/2015
During this meeting the group met and discussed the project with mentor Rob Blair for the first time. This included showing the progression the group had made since the initial meeting and the next steps which had been decided. Based on Rob’s feedback the group came to the conclusion that a number of planning and research posts would be useful in the development of the project.
1. Create planning layout for the project. This could include other media such as a gannt chart. It should also allow an extra line underneath the predicted time so we can record the accurate timings, compared to the times we set for each task. This requires planning out each of the tasks step by step before making the chart. This is important for the project as time management and the identification of tasks is vital for the completion of tasks in the time scale that the group has set.
2. A blog post about methodology we are going to use for meetings and producing work (for example, agile/scrum/life cycle). This should explain that we have looked at these and have selected one according to our task and how best we work as a group. We are currently using an agile methodology as we all discuss and contribute ideas/research rather than one person focusing on a large part. This is an important consideration as it may dictate the success of our project depending on how best group members work, therefore it should be identified early on in the project.
3. A blog post about the target audience, identifying specific types of people who would find it the most useful (for example, tourists/students/people new to an area). Using literature and market research the post should identify which types of people would be willing to pay for it a safety travel app and why. It should also consider whether every user has the same needs from the map/other features. It should conclude that based on the market our app should be free. This is an important contribution to the research as the success of the product may be depended on understanding what the target audience may want from our product which isn’t already on the market.
4. A blog post defining our success criteria. This should be a list of our goals and objectives based on the marking criteria. For example we aim to produce a project that should take X amount of time. This is important to the planning stages of the project as it will provide continual structure to the narrative and will ensure that the work out-put answers the marking criteria.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony Gray
Project Requirements
Posted by Emily Pearce in Contextual Factors and Research, Design, Structure and Story on 04/03/2015
Requirements Gathering
As the group has undertaken the research and design aspects of this project first, with the aim of completing market research and expert opinions before implementation, requirements gathering was undertaken in group meetings by developing ideas about the potential users of our application and the functionality that would be included in the TravelSafe application. Due to the way that this project has been undertaken, these requirements are to provide an idea of the functionality and limitations of our application and may change during the market research stages. This has been influenced by background research that includes the evaluation of Similar Applications. This lead the group to conclude the most important functional and non-functional requirements for the project, which are stated below.
Functional Requirements
The system shall be able to:
- allow a user to search and select a location based on GPS data
- allow a user to select a location from a list of saved locations
- For each location, it must be able to:
- generate three point to point safe routes using area safety ratings
- provide a safety rating of a user’s surrounding area based on publicly available crime data
- provide travel information from publicly available times and map
- provide safety tips using open data from Government and police service
- provide an updated news feed from RSS feeds of news source
- download a pack of the above data that can be accessed and used offline from on-device storage
- allow users to access and search through a list of Frequently Asked Questions (FAQs)
- provide translation functionality through use of Google Translate API
- have a section dedicated to user-input information as free text
Non-Functional Requirements
The system should:
- be a web-based application
- provide a comprehensive list of help and instructions for use
- use a consistent style, layout and colour scheme throughout the application
- take all reasonable steps to improve accessibility
- be intuitive for use
- be compatible with Internet Explorer, Google Chrome, Mozilla Firefox and Apple Safari to ensure compatibility with mobile browsers
Constraints
The application will be limited by/not be able to:
- the accuracy of the GPS hardware within a mobile device
- provide external backup of data
This set of finalised criteria were chosen from the extensive discussion of the merits and drawbacks of the potential features, combined with the research into similar applications as well as project constraints such as the time available and the skillsets of the developers within the group. The group feels that the finalised requirement are representative of the type of application that is being suggested, with the quantity of features providing the unique selling point to allow the group to target a niche in the market identified during research utilising both development and time management skills of the group as a whole.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
This post also represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have. There is evidence that these have been chosen intelligently (by reference to literature and analysis) to produce a specification of professional quality, leading to a successful product.
In addition design considerations for the project have been addressed in this post. This is evident through the layout of steps that the project should include, how these have been decided, and how this will be implemented to solve a problem.
Written by Emily.
Project Planning
Posted by Ayoub Elgassier in Design, Media Use, Structure and Story on 03/03/2015
Project management tools are vital for a successful project (Bakouros, Dr. Yannis, 2000). Likelihood of proportion of occurrence of mistakes would be reduced by implementation of these tools (Bakouros, Dr. Yannis, 2000). The project environment has a high chance that unexpected conditions might occur. For example, unpredictable results might be found. These might be a reason for failing the project, or it might reduce the quality of the project. Therefore, utilizing the techniques and tools of project management could be a key to overcoming these issues. Advantageously, the former offers a project team the chance to identify uncontrollable tasks as well as controllable ones (Bakouros, Dr. Yannis, 2000). Consequently, The One Percent team decided to choose a Gantt Chart as a suitable project management tool, as it provides features (discussed later) in addition to ease of usability.
The Gantt chart is a “project planning tool” offering chance of tracking tasks and activities of the project(Durfee, 2008). The reason behind chosen this tool is the simplicity of construct the tasks and tracking tasks and sub-tasks (Durfee, 2008). Gantt chart can be used to order and schedule tasks and activities of a project, each of which is pictured in horizontal bar over time (Durfee, 2008). each task takes a place in a row where Date takes a place in a column (Durfee, 2008). Start date as well as end date are recorded in order to compare whether goal is achieved or in a risk. To implement Gantt Chart, the online Smartsheet application is used. This smartsheet offers features as follows:
- Simplicity of use in terms of tackling icons, drop and drag, and also import and expert features. In addition, it can be incorporated with google sheet.
- It allows you to have a cooperation with other participants. It provides, for example, alert feature which it can send over an email to them for reminding.
- Completion feature, which is calculate the proportion of accomplishments out of 100 and also number of days that have been spent, is useful.
- It can be also set a rule in order to specify each member’s tasks with using a certain color.
There are three main phases in TravelSafe project plan, each of has sub tasks assigned to a team member. The phases are:
- Planning phase consists of six task each of which has sub-tasks.
- Design phase consists of six task as well.
- The final phase is future works which are survey, focus group and testing the application.
The following pictures illustrate a part of planning stage of our project using Gantt chart. To read full plan online visit the following link: (Full project plan) and to download PDF version click on Full Project Plan PDF.
In conclusion, this blog aims to show the importance of project management tools to improve project time management. Therefore, this project lists the Smart sheet named Gantt chart which is being used in The One Percent project.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
In addition this post represents Media Use by incorporating a gantt chart as a method for time and resource management.
This post also represents that the group has chosen appropriate project steps that directly link to the marking criteria. The project steps were chosen intelligently to produce a project of professional quality, leading to a successful product.
References
Bakouros, Dr. Yannis, D. V. K. (2000). Project Management, 0–32.
W. Durfee, Oct 2008, Project Planning and Gantt Chart
Success Criteria for our Project
Posted by Briony Gray in Design, Structure and Story on 01/03/2015
An important aspect to take into consideration for this project is that we will not actually make a final functioning product that will be distributed to the public. As this project is a group coursework that is part of an assignment we must instead set out some parameters for success that are dictated by the assignment specification, and do not end in the commercial distribution of a product. To ensure that our project is on course and will fulfil the assignment criteria we have written out some ‘success criteria’ that we will aim to complete by the end of the assignment. These are taken directly from the marking scheme, and also our specifications of our project. Our portfolio will address these issues throughout:
- To have submitted a project brief (approx 200 words) that summarise our project and how we will go about organising its different stages.
- To have kept a running blog (portfolio) of our activities as a group throughout the assignment process, on which each member will post work and research associated with the project.
- To have evidence of participating in meetings with their appointed project mentors, and with other members of the group throughout the assignment process. These can be found throughout the blog entitled ‘Meeting Summary’.
- To have submitted a reflective summary by each member of the project team at the end of the project.
- To present a summary of our project followed by a Q&A session at the end of the assignment.
- To have a project that uses design appropriate social network solutions and interface or extend the designs of existing social network infrastructures.
- To have written evidence of being able to identify and analyse social network characteristics in the portfolio.
- To have written evidence of being able to identify and interpret domain and societal requirements for the deployment of social network solutions in the portfolio.
- To have evidence of group work and group organisation throughout the entirety of the project.
- To have evidence of clear stages of planning and research throughout the project, with equal contributions from all members in a number of topic areas that may include design, research, graphics, and technical issues.
- To produce a finalised description of our project at the end of its course, which includes explanations of its different features, the methodology used to select these features, and a realistic prediction of how this product may be used by the target audience.
- To have clear evidence of market and user research which have been used to underpin the design and technological choices of the project.
- To have clear evidence of tailoring our project based on research undertaken, literature reviews and expert opinions.
- To have submitted a portfolio that demonstrates a social networking solution to a gap in the market which has been undertaken in a professional and well organised manner, and in an original way.
- To have a product that has been developed to the point of needing further testing and qualitative research (which requires funding more than our means, and more time). This means that the product, at its completion, will have extensive background research, design stages, and engineering designs and may only be improved through further testing to the wider public which we ourselves are unable to do. This is a realistic goal for our project as it demonstrates an ability to produce and work on a product to a high standard, but also realistic time management as this product has a limited time and is run alongside other courses and coursework.
These success criteria will be revisited at the end of the project, entitled Success Criteria Revisited, and an analysis matrix will be added to show which criteria have been met. This will provide a clear indication of the aspects we will aim to provide throughout the assignment process, and will help to guide our planning, research, and final product.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
This post also represents that the group has chosen appropriate criteria for the success criteria that directly links to the marking criteria, and subsequently shapes the steps and outcome of the product. The success criteria were chosen intelligently and realistically to produce a project of professional quality, leading to a successful product.
Written by Briony.
Choosing an Idea with an Analysis matrix
Posted by Briony Gray in Innovation and Creativity (Idea), Structure and Story on 28/02/2015
After our initial meeting we decided to go away and individually research a possible idea for our group project. We wrote out 15 criteria that these would be marked against by using the assessment criteria listed in the module’s resource specification. In the next meeting we pitched each idea to the rest of the group, and discussed our thoughts and considerations on a number of topics. For instance, if there was a limitation to someone’s idea we discussed a way in which it could be improved or changed to better meet our deciding criteria before deciding on a project. Once each idea had been pitched and discussed we wrote an analysis matrix, plotting each of the ideas against the criteria and one another. This allowed us to clearly identify stronger ideas based on the assessment criteria, and is shown in the table below. Taking each score into account we also held a group vote so that each member’s concerns and preferences could be taken into account. The list of our 6 ideas are explained below:
- Meeting scheduler
The number of back and forth emails that have to be sent to decide on a convenient date for both people, with tools and technologies available to us, planning a meeting should be a lot easier than it is. Existing technologies like Google, Apple and Microsoft calendars haven’t made this easy on a large scale, however smaller versions and applications exist. Therefore I propose a single page app that that allows users manage and schedule meetings; including meeting places and times. The main Technologies is will use are HTML 5 geolocation, Email API, Google MAP and Places API, and a Calendar. Useful features may include the use of common types of meeting Templates, frequently used days, time and places, meeting with multiple people, a Mobile app version and a possible business case. It would benefit members of a business, friends, family, and institutional staff.
- StudnetLinks
Although this idea is widely known and fairly popular it still poses a problem for students. This idea addresses the limitations in the article “Can social network improve project management”, and can be tailored specifically for group coursework for university students. The key areas it addresses are students complain that “group coursework” assessment is not fair sometime, despite of distribution of marks, and international students facing social and communication problems because of originating from a different education system. The focus therefore is workgroup assignments and final projects, aiding all types of students from different backgrounds in order for them to feel like the work has been fairly distributed. The features of this are as follows:
– All modules have their own page each of which can allow students share their profiles. This is in order to help students get each other and each one knows others’ skills.
– Each student posts their skills, his/her background and area interested in.
– After students grouped up a close and secrete should be created.
– Each group page should provide area for update codes, Q&A as well as enables students to schedule tasks and alert them at the deadline for each one.
– At the end of coursework, a report on proportion of student’s contribution should be issued (AS GITHUP)
– An area for posting stuff related to the modules (AS A DISSCUTION AREA IN BLACKBOARD)
– With regard to subject of dissertation, some of projects are varied. For example, the final project would be on disabilities, so I do need writing about laws of disabilities and I don’t have any idea about. Thus, I need to contact with laws’ students to explain some critical points and where I can find that. This is just an example.
– Search for students in particular department would be easily.
- Travel Safety app
This idea is a travel safety app which alerts travellers about tourist black-spots and suggests detour routes to avoid going unsafe areas The information is contributed from the social network and other reliable media. The app may have the features as follows:
– It can suggest the most safe route, and give useful guidance/tips (ie. be careful to the pickpocket before taking the train in Paris)
– It will make use of social networks to connect travellers and its news
– Verification of taxis/ tour guides/ hotels/shops/restaurants/police office (prevent illegal operators, black taxis or being overcharged)
– Alert travel updates
– Detect user’s current GPS location and provide suitable emergency contact.
– Provide corresponding embassy details, credit card lost emergency call, insurance company details and claiming procedure
- Tool to improve existing group sites in academia
Based on the literature I have been reading it suggests that group study for university students in particular could greatly be improved by better management tools, as in most cases students prefer to use social media as a lack of any other competitive options. Specifically I think it should target existing student-based sites that aim to help project management, such as Medeley, and identify how they could be improved. Often this will be something along the lines of ‘it doesnt have an option to invite others to meetings’, or ‘for a project papers that the group are reading can’t easily be stored in the same place for all to have access to’. We can then propose key changes (or a new site entirely) that improves the weak areas, I.e. a group discussion area in blackboard, paper sharing, meeting planning, and personal deadlines all in the same space.
- Online Memorials
This idea is based upon the collection and presentation of personal information after someone has died. In many cases when someone dies their social networking profiles remain, but act as a place for friends and family to visit to remember them or leave comments. However, a majority of people actually have more than one profile on social media sites, and these aren’t linked up. For example if you gave a family member permission to change your account if you have died, they would not have the same permission on another social networking platform, so your profile on one site may be a cut-off memorial that not everyone can access. This idea is for a tool that scrapes information from each of these platforms (once a family or friend has permission to do so) and displays it on one profile/site, thus making it easier for everyone to see.
- Charity Crowdsourcing
My suggestion for our social network was something that combines crowdfunding and charity donation sites like JustGiving. This idea is that people can have a profile, show interest in charities/causes etc, create events for fundraisers that people can join in with or do at the same time elsewhere (for example, how Macmillan coffee morning takes place in lots of different places, run by lots of different people but all on the same day) – basically a platform for allowing this.
In conclusion we have picked idea number 3, the travel safety application, as it fits both the most criteria in the matrix, and each member was happy with the idea. Further research and a gantt chart mapping out the stages of our project will follow shortly.
A table to show the analysis matrix conducted in selecting a project idea.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
In addition this post represents Innovation and Creativity by identifying a project idea in a novel and well-informed manner.
This post also represents that the group has chosen appropriate criteria for the comparison of ideas that directly link to the marking criteria. The analysis matrix criteria were chosen intelligently to produce a project of professional quality, leading to a successful product.
Written by Briony.
Meeting Summary 26/02/15
Posted by Taekyun Kim in Meeting Summary, Structure and Story on 26/02/2015
Meeting Summary 26/02/2015
During this meeting we addresses the ethical issues of the app’s pricing that were raised during the previous meeting. This meant considering whether it was morally right to charge people in order to feel safe. Each member conducted market analysis of similar applications, and came to the conclusion that a majority of app’s within the safety market do not charge, and therefore we should not either. This is an important consideration for our product, as it may determine how many users user our product over others.
Furthermore based on this market analysis the team have identified features of app’s on the market and the potential weaknesses that these have. During the meeting this was discussed in further detail, and the group came to the conclusion that our product should build upon the weaknesses of existing apps which would therefore create a niche market for our product. This has allowed the group to scope out a short-list of app features which were lacking or inconsistent in other existing app’s.
For the next meeting
The group decided that as the success criteria dictates that extensive testing will not be included in our project, we should decide the app features by acquiring expert opinions, group discussion, and literature reviews. Alongside this the group will research engineering choices in order to decide whether the app should be mobile based or web based, as choice of platform may dictate the usability of the app, the technologies involved to create it, and what different means of testing it may require in the future.
This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.
Minutes by Briony Gray