University of London / MSc Computer Science: Project（1〜5 週目）

May 14, 2024

ロンドン大学で MSc Computer Science: Project モジュールを履修中。

講義内容に関して記録した個人的なスタディノートです。

全 24 週のうち 1〜5 週目の内容を記録します。（1 週目開始：2024 年 4 月 8 日 / 5 週目終了：2024 年 5 月 12 日）

モジュール概要 #

Aims

To consolidate the learning achieved during the ten modules of the MSc programme, students will undertake a work-based project. The project will draw on elements of learning from different parts of the programme and demonstrate students’ insight into, and understanding of, software engineering and computer science. The projects they will complete in this module should address the needs of a client organisation. Examples of projects include:

• An electronic commerce website for a family business following digitisation
• A mind-mapping native application tool for a major operating system such as Linux, Windows or Mac OS designed for the specific requirements of a school
• A fundraising app for a charity for one of the major mobile OSs such as Android and iOS
• A data analytics tool for the analysis of mobility patterns collected from a geo-location service for a local delivery business
• The back-end service and REST API providing access to a legacy knowledge base operated by a client organisation.

Weeks

プロジェクトは他のモジュールの長さ（12 週間）とは異なり、24 週間にわたる内容となっている。

前半 12 週間の各パートの内容は以下の通り。

• Week 1: Introduction to the project
• Week 2: Developing the project idea
• Week 3: Researching the project idea
• Week 4: Project aims and objectives
• Week 5: Writing the project proposal
• Week 6: Developing your project
• Week 7: How to organise and plan the project
• Week 8: Testing, analysis, and evaluation
• Week 9: Referencing, citation, and plagiarism
• Week 10: Writing the project report
• Week 11: Preparation for project proposal submission
• Week 12: Preparation for project proposal submission

参考文書 #

Module reading list

• Association for Computing Machinery ‘ACM Code of Ethics and Professional Conduct’ (2018)
• McMillan K. and J. Weyers How to Write Essays & Assignments. (Harlow: Pearson Education Ltd, 2014) 2nd edition.

Week 1: Introduction to the project #

レクチャーリスト #

• Introduction to the project
  • Lecture 1: Overview
  • Lecture 2: Choosing a topic for your project
  • Lecture 3: Project themes
• Project deliverables
  • Lecture 4: The project proposal
  • Lecture 5: The project report
  • Lecture 6: Software artefacts

レクチャー内容のメモ #

• 本モジュールについての概要説明。
• プロジェクトのアイデアの見つけ方、参考となるプロジェクト例の紹介などの説明があった。

アクティビティ #

• Open a new document or grab a clean sheet of paper.
• Write three short titles for your proposed project, make them concise, but attention grabbing, whilst at the same time hinting at the technology or innovation behind the idea.

Week 2: Developing the project idea #

レクチャーリスト #

• Writing your project proposal
  • Lecture 1: Structure of the project proposal
  • Lecture 2: Computing project types
• Ethical review
  • Lecture 3: What does ethics mean to your project?

レクチャー内容のメモ #

• プロジェクトで解決する課題を定義する際の注意点についての説明。
• プロジェクトで扱う課題のタイプについて。リサーチベースの課題にするのか、何かソフトウェアを開発するような課題にするのかなど。
• Ethical review（倫理申請）についても説明。

What project topic should I do?

MSc Project is an independent project and it is up to you to choose the topic and area that you would like to focus on. You can run your project ideas by your work colleagues, friends and family, or peers in the forum discussions. For work related projects, you may be able to obtain a list of requirements and objectives that would help define a clear idea and plan. If you are not doing a work-based project, then think of an area of computer science that inspires you. This could be a data set, technique, or technology. If you have a hobby, then consider what computer science might do to facilitate it.

アクティビティ #

• Write 5 sentences, describing the main ideas of your project starting from the general to the more precise.
• Consider including the area you are contributing to, what the application or analysis provides in terms of the features or insights, the methods adopted, and how it advances the area (e.g. improves processes at work through automation, automatic tagging of geolocations through social media posts).

These five points should give anyone a good idea of what your project is, what it does, and why it is important.

Week 3: Researching the project idea #

レクチャーリスト #

• Background research
  • Lecture 1: Performing background research
  • Lecture 2: How to undertake a critical literature review
• Referencing
  • Lecture 3: How to reference your sources

レクチャー内容のメモ #

• 事前調査の方法。参考となる文献の探し方など。
• 文献の客観的に読むために注意すべき点、文献の Critical literature review（批判的評価）の仕方の説明。
• 文献の引用することの意味、引用する際の引用方法。

アクティビティ #

Gather research and sources on the chosen topic relevant to your project idea. Try to find the most authoritative sources for inclusion. If you are referencing research papers, include those that have a high number of citations as your core sources, you might also find relevant sources in the reference section of the papers or sources you are citing:

• Summarise each source in terms of its contribution, impact, or methods: What did they do? Why was it important and worth doing? Who will benefit from the research or software application.
• How does your project fit in? Does it extend or improve on previous work in your area of interest?

Remember, performing background research at this stage will enable you to provide a clear description and context for your project. Someone may have already carried out research on what you are proposing, in which case, you need to argue why your solution improves, or builds upon an existing solution. Otherwise, this is the point where you might want to take a step back and reformulate the project idea and explore related topics, or other software solutions in order to find your contribution to your chosen area.

Week 4: Project aims and objectives #

レクチャーリスト #

• Project Aims
  • Lecture 1: How to formulate the aims of the project
  • Lecture 2: Case study 1 – research based
  • Lecture 3: Case study 2 – application based
• Referencing
  • Lecture 4: How to formulate the objectives of the project
  • Lecture 5: Case study 1 – research based
  • Lecture 6: Case study 2 – application based

レクチャー内容のメモ #

Aims

• プロジェクトの目的（ゴール）の設定について。Why?（なぜそのプロジェクトが必要か）What?（そのプロジェクトで何をするのか）How?（どのようにするのか）
• Aim（目的）を大きくし過ぎると達成が難しくなる。これは主にその課題領域について十分な理解がないままで目的を設定してしまったことによる。そうならないよう、対象ドメインに対して十分な事前調査を行なった上でプロジェクトの目的を設定すべきである。

Project’s aims essentially specifies what your study will answer.

Aim 設定の例：

• Research based なプロジェクトの場合
  • タイトル “Forecasting the Euro area unemployment rate: A machine learning approach”
    • 👉 具体的な Aim “Explore the main economic factors affecting unemployment in the Euro area and techniques to forecast the unemployment rate using machine learning.”
  • タイトル “Exploring the influence of twitter bots in predicting cryptocurrency pricing.”
    • 👉 具体的な Aim “Exploring the influence of twitter bots in predicting cryptocurrency pricing during quarter 1 2022.”
      • 👉 さらに具体化 Can volume or proportion of tweets by bots be used to predict cryptocurrency prices and volatility?
      • 👉 さらに具体化 Which method is best at predicting cryptocurrency prices and volatility?
• Application based なプロジェクトの場合
  • タイトル “General dimension controller plugin for QGIS” (QGIS is geographics software tool)
    • 👉 （Aim のつもりで）そのために実装したい機能を記述しただけの場合 “Required: features for this project are: use interface, a ‘playback’ slider, similar to one you would find on most media player gui’s, a pause / play button…”
      • 🚨 However, this is, unfortunately, not a very clear aim but simply a list of features that will be implemented, and so it does not actually answer the question as to what you want to do, why you want to do it, and why does this project matter.
      • 🚨 This is one common mistake when writing your aims for an application style or standalone piece of software which is not really focused on answering a research question.
  • タイトル “A web-application for the design and management of jack-up rigs in the offshore wind industry.”
    • 👉 具体的な Aim “Automate the site-specific assessment of jack-up rigs”
  • タイトル “Visualising small multi-threaded applications in Java”
    • 👉 具体的な Aim “Create a tool that affords students a truly visual representation of how threads act during the execution of multi-threaded programs, to better equip them to confidently interpret, debug and write multi-threaded programs.”

Objectives

Your aim is to focus on what the project is intended to achieve, whereas your objectives focus really on how the aims will be achieved. Project’s objectives specify how your project will address your aims. To divide your aims into several smaller parties, of which represents a key component of your project. As a result, almost all project objectives take the form of a numbered list, with each item usually receiving its own chapter or section in a final report.

As you formulate your objectives, think about being specific, providing ways to – Is it measurable, achievable, relevant ,and how much time are you going to need?

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

It’ll be easier to explain to people which step you are tackling. You’ll be able have a clear idea of which steps are going to be involved and in what sequence they should follow.

Objective 設定の例：

• Research based なプロジェクトの場合
  • タイトル “Forecasting the Euro area unemployment rate: A machine learning approach”
    • 👉 具体的な Aim “Explore the main economic factors affecting unemployment in the Euro area and techniques to forecast the unemployment rate using machine learning.”
    • 👉 具体的な Objective
      • To collect financial data
      • To analyse financial data
      • To design a ML model to predict Euro area unemployment rate
  • タイトル “Exploring the influence of twitter bots in predicting cryptocurrency pricing.”
    • 👉 具体的な Aim “Exploring the influence of twitter bots in predicting cryptocurrency pricing during quarter 1 2022.”
    • 👉 具体的な Objective
      • To collect tweet and price data.
      • To compare tweet volume to the price of each cryptocurrency.
      • To apply time series techniques to identify trends.
      • To evaluate the correlation between time series.
• Application based なプロジェクトの場合
  • タイトル “A web-application for the design and management of jack-up rigs in the offshore wind industry.”
    • 👉 具体的な Aim “Automate the site-specific assessment of jack-up rigs”
    • 👉 具体的な Objective
      • To develop a GIS map of rigs
      • To allow user data uploads
      • To store the data securely
      • To automatically produce assessment reports
      • To use test-driven development approach
  • タイトル “Visualising small multi-threaded applications in Java”
    • 👉 具体的な Aim “Create a tool that affords students a truly visual representation of how threads act during the execution of multi-threaded programs, to better equip them to confidently interpret, debug and write multi-threaded programs.”
    • 👉 具体的な Objective
      • To implement a method to capture the source code line number for the thread
      • To track source code lines during the execution of a thread
      • To visualise the running of a thread in graphical form
      • To output the visualisation as an animation

アクティビティ #

Consider and draft the aim(s) and objectives for your project for inclusion in your project proposal document.

If you have a client, then this step might be straightforward since your aims and objectives will largely be composed of user requirements.

The aims should be broad and cover the main reasons why the project is important in terms of the client need, or to fulfil a specific goal (if there are no client requirements). Your objectives should be specific and measurable. Add a short paragraph describing the main aims and objectives of your project.

Week 5: Writing the Project proposal #

レクチャーリスト #

• Writing the Project Proposal
  • Lecture 1: Writing the project proposal
• Proposal Structure (examples)
  • Lecture 2: Academic writing style: an overview

レクチャー内容のメモ #

Core elements of project proposal

Let’s discuss some of these important core elements of a project proposal.

There is some freedom in how you structure your proposal. However, there are some key elements you should include, which we have outlined in this lecture. You should not only include them, but also as I said, it’s very important to sign post them to the reader using clear headings as well as sentences.

1. Background research
   • Your background research is very important. Here, you should show, basically, once you’ve written this up,that you have a clear understanding of the research material that you’ve gathered. In this section, you should also identify any potential approaches, compare them, review them, analyze them, and then critically evaluate them. When you are critically evaluating others methods or approaches to things, you can highlight things like their strengths, weaknesses of either the dataset that they’ve used or the approach they’ve taken, or the results that they’ve finally produced.
2. Presentation of the problem
   • Here, your task is to describe the challenging problem you are tempting to address with your project. You should ensure that the problem is specified and clearly outlined by providing appropriate context and where it’s appropriate, if you’ve got a work-based project, you should include things like technical user requirements
3. Aim and objectives
   • Then a section that we’ve discussed at length so far is how to formulate your aims and objectives of your project. Therefore, you should ensure you have articulated these as we’ve suggested, that is using the smart approach for objectives, and that you have understood the difference between aims and objectives.
4. Methodology or Proposed solution
   • We have a methodology section, or proposed solution section if you wish to call it that. Once you have actually grasped the complexities of your chosen topics through the literary search and background review, as well as critical analysis, you should now be able to identify one or more appropriate development or research methods that would help you essentially to address the problem and therefore your aims. You should justify for each method why it is suitable. Try to break your project down into subtasks that are logically coherent. At this stage, there will still be some things that remain unknown until you start the actual development of your solution. Therefore, consider describing various fallback plans that can be brought into action should you be unable to obtain a particular data set, access to a resource, or your users are no longer around to test your application. What that means is have a backup. Tell us if there’s a risk to your project of something not going according to plan, then how will you mitigate against that risk and still achieve your project.
5. Plan for developing the solution
   • Then lastly, we want to see how you’ve considered the scope of your project and the work involved. Include a section that outlines your plan for developing the final software solution. This should ideally identify each of the important tasks or steps you need to take during the development phase. Have a look at your objectives, try and put some kind of time scale on each objective, and then try to find some way to plan this out in terms of a logical sequence of events over the course of your whole project. You might provide this, for example,as a timetable or consider the commonly used Gantt chart（ガントチャート） to show you. Gantt charts are my personal favorite. They do allow you to easily show how your project is organized and it allows you to show where tasks overlap, and it means that the reader is very clear just from a quick look at a Gantt chart what’s actually going to be happening. At this stage, you have a project idea, and you should have gathered some research material at this stage, some background literature or in terms of websites and blogs and other resources that you can then evaluate and pinpoint some kind of method that you can choose and then formulate aims and objectives. This is a good time really to start thinking about the structure of the report.

Academic writing style

We will focus mainly on providing you some tips in this lecture on how you can write academically in terms of the language and grammar that you use, which is ultimately at the core of communicating and writing down your ideas.

The sort of writing that you adapt to present your report can be discussed from three points of view. The first is the actual presentation style of your report. For example its layout, font size, and so on. Then another important component is the style of the grammar and language that you use within your report. The third ultimately relates to the content structure. It considers when you’re writing your project proposal and reports, is the overall content structured in a coherent and sensible way.

1. Presentation of the proposal
2. Style of grammar and language
3. Content structure

We will cover some simple rules that you can follow to improve your writing style for professional-style reports.

Do not use personal pronouns

Consider writing in the third person.In other words, try to avoid using personal pronouns such as I, you, we, my, etcetera, but make sure that you do not end up producing elaborate and complex sentences just in order to avoid this. Certainly, one recommendation is to avoid use of I in your writing. For example, take the following sentence. The student might write, “I interviewed twelve people to see what they thought of my system.” Now, we could actually reformat this because this should be written in a more academic style by removing the personal pronouns and restructuring the sentence with some changes in the choice of words. Here we can reformulate that previous statement into, “Twelve people were interviewed to determine their thoughts on the system.”

Keep it to the point

Another piece of advice is to just keep it to the point.Keep sentences short and to the point. To do this, avoid making several points within the same sentence. Don’t try to build long clauses with conjunctions like and, etcetera, to ultimately make it quite difficult. It basically forces the reader to keep a lot of information in their head before the sentence is concluded.

Avoid abbreviations, jargon and slang

You should avoid abbreviations unless you explain them. If you do have an abbreviation for a particular type of – API, for example, is a common abbreviation for Application Programming Interface. When you first use an acronym or an abbreviation, then do consider explaining in full first and putting the abbreviation in brackets. You should also avoid colloquial forms of a language like just regular language. You should try and use more specific terms and more technical terms, and avoid jargon unless it’s been explained. One last thing is to avoid slang.

Simple over complex

You should always aim for simple rather than complex words. When you’re using complex words which somebody has to go to a dictionary to look up, it’s often intimidating for the reader. It crowds the meaning also of your sentence, and it can sound somewhat contrived or convoluted. It’s also often used to actually hide a lack of understanding about the subject, which an educated reader will be able to spot quite easily. You should be able to explain your thoughts and statements, the arguments and ideas, as well as methods and things like that that you’ll describe in very simple language. This will then mean the readers are very clear about what’s being said.

Gender neutral: s/he, they

You should also, where possible, try to keep your report gender-neutral. For example, you can use these examples here where it’s “s/he” to capture both he and she, or you can use a collective term, they, rather than just solely he or she in order to avoid this.

Write in the past tense

You should also consider writing in the past tense. It is common practice, as you’ll see if you’ve read a lot of academic writing, that a lot of the work is in the past tense as it often represents the results of the project, which you have obviously completed in the past.

For the project proposal, it is more likely you will use the present tense for the time being because it was describing your plan of work and what you actually intend to do, which is obviously located in the future.

For the final report, it’ll be much more appropriate to write quite a large part of your report in the past tense to describe what was actually achieved.

Avoid jokes and personal stories

You should certainly avoid jokes and personal anecdotes and stories. All material should be ultimately relevant. The other problem is that humor can be somewhat subjective and generally not really appreciated by the reader when evaluating the professionalism of your work. That’s another thing to bear in mind.

Avoid contractions

You should also avoid contractions or shortened forms of words,such as “isn’t” it should be “is not”, as well as “didn’t” should be expanded to “did not” or even “does not”. Write these in full. Do not write with contracted forms because this is more used in speech.

Avoid certain words

There are certain terms that you should try to avoid. These words are things like “clearly” or “obviously”. You might start a sentence like this, “Clearly, X, Y, and Z was demonstrated,” or, “Obviously, this fact is true.” You might understand the fact which you are referring to, but it may not be actually clear to the reader themselves. The reader may also feel that they are being absent-minded if they don’t see the point clearly or obviously. Again, try to avoid these types of words.

Unsupported claims

Do not make unsupported claims in your written work. This is something that can happen when you’re initially, drafting a proposal or your report. Go back and have a look at anything that you’re saying is certain or that you’re claiming is true, and make sure that you’ve referenced it, for example. If you read it somewhere and so therefore you believed the fact to be true because you read it in a research article, then do include a reference to that research article within your reference section, but also within the text itself just afterwards.

“Requirements capture is the longest stage of the software development process” is one such overarching claim you might make. These are claims that are your personal opinions really rather than accepted facts supported by the literature. Here, you need to make sure that if you include these kinds of claims that you, as I said, do support them with either an appropriate reference or a caveat word such as often or sometimes. You can remove the intensity of your claim by including – you can say that “Often requirements capture is the longest stage of the software development process,” showing that it’s nota wholly factual or true statement necessarily, but it is possibly or hypothetically true. For example, we could reword our initial claim using one of these caveat words and supported by a reference where possible. Here the former example can be reformatted into, “Requirements capture is often the longest stage of the software development process.”

アクティビティ #

• Complete a first draft of the project proposal ensuring you include the sections highlighted in the lectures.
• Ensure you have provided the key points necessary to communicate your ideas to a technical and non-technical audience.