University of London / MSc Computer Science: Project（6〜12 週目）

University of London / MSc Computer Science: Project（6〜12 週目）

July 3, 2024

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

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

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

Week 6: Developing your project #

レクチャーリスト #

  • Development 1
    • Lecture 1: Software development life cycle
    • Lecture 2: The earliest model: build-and-fix
    • Lecture 3: The incremental model
  • Development 2
    • Lecture 4: Top-down and bottom-up development
    • Lecture 5: Which development approach should I use?

レクチャー内容のメモ #

  • システム開発の手法（進め方）について。

Software development life cycle

  1. Requirements capture
  2. Design
  3. Build
  4. Test
  5. Implement (Install)

Software development models

  • Build-and-fix model
  • Incremental model
  • Top-down model
  • Bottom-up model

アクティビティ #

1

Select an appropriate software solution, methodology or process that can deliver your project idea and solution.

  • Think about whether it is appropriate, e.g. which type of database would be best if one is required? If your solution is a RESTAPI, which webserver architecture would be appropriate?
  • Draw a diagram of the architecture of your software solution to illustrate the main components of your application. For example, in a client-server architecture, supporting a web app or RESTAPI, there are typically two main components representing the front-end and back-end of the system. Alternatively, if it is a mobile phone app, then perhaps it connects to third-party services to fetch data.
  • You can include this final diagram as part of your project proposal.

2

Include the diagram of your software solution (from the previous activity) in your proposal draft document. Write a short paragraph describing the following for each main component of your software solution.

  • What the component is used for, or what part of your solution it supports.
  • Why the component is important in the system as a whole
  • How you plan to implement it, e.g. if you are using machine learning, you will require a model (explain the structure of the neural network) and training data (how big is it, is it balanced), if you are developing a mobile app, then perhaps there is a particular framework you need to support the OS of your choice (Apple or Android).

Week 7: How to organise and plan the project #

レクチャーリスト #

  • Project planning
    • Lecture 1: Planning and managing the project
    • Lecture 2: Collating and organising sources for better reference
  • Risk management and resolution
    • Lecture 3: Identifying and managing risks in your project
    • Lecture 4: Dealing with problems

レクチャー内容のメモ #

  • プロジェクトマネジメントについて。

追加資料 #

アクティビティ #

1

Revisit your critical literary review. Add a further 500 words detailing how your project builds on, or contributes to, previous research or software of a similar kind. Expand your review with further research that is relevant to your project.

2

Create a Gantt chart reflecting the main stages of development of your project. This should detail coherent phases of develop, such as:

  • Gathering data and/or resources.
  • Prototyping and final development phases for each of the main components of your system.
  • Testing and evaluation.
  • Report writing.

3

Perform a risk assessment for your project using some of the techniques we have introduced in this topic. Compute a risk impact score for each of the risks you have identified and order them using the RAG grading approach to identify the critical risks to your project.

4

Given the critical risks you have identified using the RAG grading method in the previous activity, think about how you will deal with them and write a short contingency plan on how you will manage each of these critical risks to your project. This will help you think about how you will control any issues arising one you begin the development phase of your project.

Week 8: Testing, analysis, and evaluation #

レクチャーリスト #

  • Testing, results and analysis
    • Lecture 1: Report - Testing, results, and analysis
    • Lecture 2: Verification, validation, and testing
  • Evaluation
    • Lecture 3: Evaluation, and critical evaluation

レクチャー内容のメモ #

  • 成果物の検証と評価について。

アクティビティ #

1

Add the following headers to your project report document and include them in your table of contents. A description of each section is provided as a guide to the content that will go in each section:

  • Testing:
    • A description of the test plan, i.e., how the program/system was verified.
    • Put the actual test results in an appendix if too long. This section may also include a user evaluation based on feedback where appropriate.
  • Results:
    • This chapter is relevant to projects where experiments or simulations were carried out with the code written.
      • Why were certain experiments carried out but not others?
      • What were the important parameters in the simulation and how did they affect the results?
    • If there are many graphs and tables associated with this chapter they may be put in an appendix, but it is generally better to keep these close to the text they illustrate, as this is easier for the reader.
  • Evaluation:
    • Evaluation and critical evaluation of the results including strong and weak points, lessons learnt, and design decisions.
      • Consider what you would do differently, are there ways in which the project could be improved or extended?

2

Think about how you will evaluate your chosen development approach at the end of your project.

  • Put together a test plan for your own project.
  • Think about how you will be evaluating your system towards the end of your project.

Check that you have allocated sufficient time for this evaluation in your project plan and confirm that you have access to the right people (if needed) to test your software when the time comes.

Week 9: Referencing, citation, and plagiarism #

レクチャーリスト #

  • Avoiding Plagiarism
    • Lecture 1: Referencing your sources
    • Lecture 2: Plagiarism guidance
  • Implementation of the research
    • Lecture 3: Structuring your project proposal

レクチャー内容のメモ #

  • 既存の研究や開発物の参照や引用と、剽窃について。
  • プロジェクト提案書について。

Why do we reference sources?

  • Avoid plagiarism
  • Provide context
  • Support argument
  • Source of information

How do we reference sources?

IEEE reference style is used mainly computer science.

The IEEE style is a numeric system where citations are numbered within the main body of your text within square brackets. The citation in your text corresponds to a full reference in the list of references at the end of your work. This is how the two aspects of referencing work. All references must have their own number in the main text and in the reference list, we reuse the same number for all subsequent citations of the same source.

That means that when the reader’s reading the text, they’ll see a number in square brackets, and then they’ll look up that number in your list, point to a line number in your reference list, which will then give them more information about how to find the original source.

The citation numbers should appear on the same line as a text inside any punctuation. Here, we have an example of how you might introduce the broad domain of your project. Here, you would add a reference to the main text on the subject that gives the reader a general review of the field. In this statement, we say machine learning has advanced in recent years, and some authors have made that claim before us, so we’ve put them in square brackets, the line number in the reference list, where they can be found. If there’s several sources which appear one after the other in your preference list, then you can provide a shorthand by listing references 3, 4, and 5,as [3]-[5] with a hyphen in between. Then you see how we’ve combined it with another source, specifically about neural networks.

Machine learning has advanced in recent years [1], [3]-[5], in part due to developments in neural networks [6].

Here’s an example of how citations to specific authors might appear in the main body of your text should you want to mention them. We might say, “Make a claim,” or, “Show some evidence to support our claim.” We say, “As demonstrated by Hinton,” and then we have a reference to perhaps a similar paper or piece of research by that author. Then we also reference another author, just to give further support to our argument, to Brown and Jones. Then we refer the reader again to another source in our reference list.

... as demonstrated by Hinton [4], Brown and Jones [5].

To submit the idea further, here is another example where we paraphrase some core idea. We’ve got a list of references again. We said a number of studies, including X, Y, and Z, which is referenced by reference list in line 2, 4, 9, have investigated these issues. Again, we have to set in the context, potentially for our introduction of our own ideas coming, therefore.

... a number of studies including [2], [4], and [9] have investigated these issues.

Reference list

Look what a reference list looks like. This is typically something which will appear at your end of your report.

Books

When the source is a book, if you’re citing a single chapter from this book on the subject, it could even be a collection of research papers. Then you can use the template that we have hereto add to your reference list. Here, you’ll see we’ve got some Xs, and these represent the edition number of the book because sometimes, books are printed several times. We have a chapter number and a section and page number to make it very specific about where we found this piece of information. Typically, you have the author at the beginning, and you’ll usually have their surname first, and then followed by a comma in their initials, the title of the chapter, if it appears in the book, then the title of the book follows. Then we have the name of the publisher. If it’s an American source, and typically, there will cite the city as well, where it was published. Then we have the year and chapter, section, and page numbers. As you can see, it’s quite a lot of information for the reader to then go and find out specific reference in the original source.

J.K. Author, "Title of chapter in the book," in Title of the published book, xth ed. name of publisher, year, chapter.x, section.x, pp.xxx-xxx.

Articles

When the source is a research articles that you found in a research journal, for example, or even in an industry report. Typically, we would, again, cite their surname and their initials, the title of the article. We might then have an abbreviation for the title of the journal because typically, journal titles can be quite long. You can usually look these up on the internet to find out what the appropriate abbreviation is. Then we commonly cite the volume number of the journal, the number of the issue of the journal as well, and then the page number. We might also include the year, the month, and the year, and what we call a doi, if it’s available. The doi is really just a special–it’s almost like a URL. You can click on the doi and be taken straight to the original source. It’s a unique number.

Authors(s) Initial(s). Surname(s), "Title of the article," Abbrev. Title of Journal, vol. x, no. x, pp. xxx-xxx, Abbrev. Month. Year, doi:xxxxx (if available).

Websites

You might obviously want to reference websites in your work as well. Again, there are conventions. The most basic citing style for websites consist of the author name, the page title, website title, web address, and the dates that you accessed it. Now, you might not be able to find the name of an author, which is fine. You usually look at the head of the text or the bottom of the article, and this is where you traditionally find out who wrote the article. Page title is obviously the title of the page, and then we have the website title, as well. That’ll be the main domain. Then one of the most important parts is the date that you accessed it. You want to include the date you actually read the article online, and this is important for one particular reason,and that is the content on the internet is often revised and edited, is made unavailable for whatever reason, which means that the original source that you’re citing from might not exist or the text has been heavily edited, which means your claims are no longer supported in some sense, but by giving the reader a date, then when they check on the source, and they find it has been changed, then they know that there was due diligence in a sense that it was there for you originally.

First Name Initial(s) Last Name. "Page Title." Website Title. Date Accessed. [Online]. Available: Web Address

Codes

Then there’s times when you want to reference code snippets. When it comes to coding, there are obviously going to be occasions where we get a bit stuck, and this means we might do some research on how to implement something in our chosen programming language. At this point, you might stumble on a tutorial that shows you how things should fit together, for example, using an API or a library. Other times, you may head over to StackOverflow, and see if others have had the same or similar problem. You might even post a question in the hope that someone can provide you with a solution or even an idea, essentially on where the error might be. If you do copy code from these types of sources, then you need to make it clear by adding a comment in your code. You can use the same reference style as for websites, and you can paste this reference above the snippet of code you have borrowed followed by your code. Do make sure that the code written by you, however, is still substantial, and that it covers the most important and novel aspects of your software that make up your contribution to your chosen area. If, at the end of the day, your code is largely by third parties in a sense that you cited it, but it’s essentially bolting together all these various solutions, it’s not going to be substantial enough to be considered your own work. Do bury that in mind, it’s okay to look for help, but when it comes to copying code, do you make sure you cite text. It’s easy to pick up with plagiarism tools. The same applies, you are borrowing ideas from other people or other people’s work, and you’re using it in your own, so the same rules for referencing and citing and plagiarism still apply.

Example reference list

[1] F.P. Brroks, The Mythical Man-Month: Essays on Software Engineering, Anniversary ed. Boston: AddisonWesley, 1995.

[2] T. DeMarco and T.R. Listener, Peopleware: Productive Projects and Teams, 2nd ed. New York: Dorset House Publications, 1999.

[3] M. Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed. Boston: AddisonWesley, 2004.

[4] J. Seguel, "The doctoral program in Computing and Information Sciences and Engineering of the University of Puerto Rico," Future Gener. Comp. Sy., vol. 19, no. 8, pp.1293-1298, 2003.

[5] M. Semilof. (1996, July 15) Driving commerce to the Web - corporate Intranets and the Internet: LInes blur. Communications Week [Online]. 6(19). Available: http://www.techweb.com/se/directlink.cgi?CWK19960715S0005

Structuring your project proposal

これまで、たくさんのメモを取り、プロジェクトがどのように組み合わさるかをしっかりと把握し、プロジェクト提案ドキュメントのドラフトを書き上げてきたはずです。このドキュメントは、実行する必要がある作業のガイドとなります。業界では、これは技術仕様書または仕様および設計ドキュメントと呼ばれることがよくあります。自分が優れたライターではないと感じる場合、これを書くのは非常に困難ですが、技術仕様書を書くことで、プロジェクトがより成功する確率が高まり、実装フェーズで何かがひどく失敗する確率が減ります。優れたライターであるかどうかに関係なく、最も難しいのは始めることです。そこで、さまざまなメモや作業に使用できる資料があると仮定して、プロジェクト提案の構造を見てみましょう。技術仕様書またはプロジェクト提案と最終レポートは、基本的に、ソフトウェア ソリューションを設計および構築することで技術的な問題に対処する方法を概説したものです。前述のように、技術設計文書、ソフトウェア設計文書、またはエンジニアリング設計文書として作成されます。実装中にソリューションを構築する開発者によって作成されることが多いですが、大規模なプロジェクトの場合は、技術リーダー、プロジェクト リーダー、または上級エンジニアによって作成されることもあります。この文書には、プロジェクトの設計、関連する作業、影響、タイムラインが示されます。実装中に行う必要があるすべての作業を細分化し、整理し、タイム ボックス化すると、ソリューションの範囲をより適切に把握できます。技術仕様は、提案されたソリューションの概要を提供するため、実装フェーズだけでなくその後もプロジェクトのドキュメントとして機能します。また、最終レポートの形式で拡張バージョンを使用して、プロジェクトでの成果を伝えるのにも役立ちます。作業を開始する前に、問題領域に関する既存の情報を収集し、問題の履歴に関するこの知識を使用して、問題を詳細に説明し、問題を解決できると思われるあらゆる種類のソリューションを検討します。調査して思いついたすべてのオプションの中から、最も合理的なソリューションを選択します。あなた自身と話し合い、これが基本的に提案するソリューションを構成します。過去の背景調査と提案されたソリューションを使用して、プロジェクト提案レポートの作成を開始できます。これは短いドキュメントであり、前述したように技術仕様として構成できます。どのように行うかを見てみましょう。レポート提案と最終レポートを、前述したように技術仕様として構成することを検討してください。これは、プロジェクトの複雑さを管理し、プロジェクト制限を設定することでスコープと機能のクリープ (拡大) を防ぐのに役立つため、有益です。また、設定した優先順位を記述できるため、プロジェクトの最も影響が大きく緊急な部分のみが詳細に記述されます。実装後は、プロジェクト内で発生した問題がどのように解決されたかを含め、評価と批判的評価の一環として、振り返りと事後検証の形で洞察を提供するように拡張できます。最もよく計画された技術仕様は、ソフトウェアの実装を開始するときに成功を測定するための優れたガイドになります。提案書の構成方法を見てみましょう。提案書は最終的に 4 つの主要な部分に分けることができます。導入部では、基本的に解決しようとしている問題と、既存の作業に関する調査の大部分をカバーします。もう 1 つの重要なセクションは提案ソリューションです。ここでは、ソフトウェアの実装に採用する方法またはアプローチについて説明します。次に、作業計画があります。これは、ソフトウェアの開発を開始するときに非常に役立つ参照資料となります。最後に、最後に参照リストがあります。これは、基本的に、実施した調査の範囲と、主張を裏付ける参照資料を誰かに示します。これらの個別のセクションに必要なコンテンツを見てみましょう。まず、はじめに、そして簡単な概要を述べます。これは、ユーザーの潜在的視点からの問題、問題の背景、提案する解決策、および影響や利害関係者について要約します。これは、レポートの他のすべてのセクションの簡単な概要にすぎません。次に、問題をより詳細に定義し、たとえば、問題の原因、問題を解決する価値がある理由、問題がユーザー、会社の目標、または社会にどのように影響するかについてコメントすることを検討します。次に、作業している領域またはドメインの文献レビューに進むことができます。この作業の一部は既に行っている可能性があります。解決策を解決するために過去に行われた取り組みと、それが必ずしも効果的ではなかった理由、特定のソフトウェアが会社の目標とどのように関連しているか、提案された解決策が組織の全体的なロードマップや戦略にどのように適合しているか、または研究を前進させているか、解決策が何らかの技術戦略にどのように適合するかを検討することもできます。また、代替の解決策や設計が何であるかを検討することもできます。それぞれについて短い概要を提供できます。また、これらの代替ソリューションのそれぞれについて、いくつかの長所と短所、および代替ソリューションが提案しているソリューションよりも本質的に劣っている点をリストできます。最後に、このセクションの目的と目標があります。これは、基本的に以前に説明したように、プロジェクトの目的と目標の詳細です。これに加えて、提案文書の次の章の概要で締めくくることができます。次に、核心またはコアに移ります。これは、問題に対する提案されたソリューションの詳細です。提案されたソリューションのセクションでは、提案された説明、基本的に現在の提案されたソリューションを提供できます。ソリューションが使用する外部コンポーネントを参照できます。相互作用して変更または影響を与える可能性のあるもの、現在のソリューションの依存関係、提案されたソリューションに関する長所と短所、または制限などの注意事項について説明することもできます。また、データ モデルやスキーマについて、モデルの外観、検証方法、スキーマの内訳などについて説明することもできます。ビジネス スタイルのロジック、API の変更についても説明する場合があります。エラー状態、障害シナリオ、エラーや障害につながる条件、前述の制限などについても説明する場合があります。ビジネス ロジックの説明に役立つ擬似コードとフロー チャートを含めることもできます。ツールまたはソフトウェアにユーザー インターフェイスがある場合は、インターフェイスのアクセシビリティに関するユーザー要件、ユーザー エクスペリエンス、以前のソリューションを強化するために行う変更、行った新しいユーザー インターフェイス設計の選択について説明する場合があります。ワイヤーフレームや説明、携帯電話の操作性やアプリケーションのアクセシビリティなどに関する懸念事項などを含めることができます。ユーザーがエラーに遭遇したときにどのように対処するかについても話し合うことができます。また、このセクションでは、ソリューションの拡張性、その他の制限事項、障害からどのように回復するか、将来の要件やその他の側面にどのように対処するかについても検討する必要があります。次に、テスト計画について話し合う必要があります。テストによってユーザー要件がどのように満たされるかについて最大限の説明を提供し、設定する単体テスト、統合テスト、品質保証などについて話し合うことができます。また、ユーザーからのフィードバックを収集するための調査をどのように設計するかについても話し合うことができます。設定する予定の評価指標や評価基準についてもここで話し合うことができます。最後に、プロジェクトの成功に最終的に影響を与えるリスクがあるかどうかを確認し、そのリスクをどのように管理するかを検討します。たとえば、ソリューションが特に重要な場合は、異なるデータセットや異なるクラウドフレームワークを使用したり、開発する予定のコア機能のセットを減らしたりすることができます。複雑です。これは、プロジェクトが複雑であったり、たとえばクライアントが関与していたり ​​、プロジェクト期間中にクライアントの可用性に関してリスクが生じる可能性がある組織が関与している場合に適用されます。次の主要なセクションは作業計画です。プロジェクトでの時間管理と実装の管理について説明しましたが、作業計画セクションには、作業見積もりやタイムラインなど、いくつかの項目を表形式で含める必要があります。前に説明した特定の測定可能でタイムダウンのタスクをリストすることもできます。各タスクを完了するために必要なリソース、各タスクを完了するのに必要な時間の見積もりなどをリストすることもできます。これについては以前のトピックで説明しましたので、参照してください。最初に開発するものと、プロジェクトで最も重要なコンポーネントまたはリスクの高いコンポーネントに関する優先順位リストを作成することもできます。マイルストーンを含めることもできます。これらは、作業の重要な部分が完了した日付付きのチェックポイントです。マイルストーンの通過を示すメトリックなどを含めることもできます。また、アクティビティ ネットワークを検討して、プロジェクトのすべての主要目標がどのように分割され、どのように相互に関連しているのか、どれくらいの時間がかかるのか、これらのアクティビティがいつ完了するのかを示すこともできます。また、アクティビティ ネットワークの一部としてマイルストーンを含めて、主要なチェックポイントがどこにあるかを示すこともできます。最後に、ガント チャートを検討して作業計画をまとめます。ガント チャートは、時間の経過とともに展開するタスクを示すのに最適です。また、重複するタスクも表示できます。多くのプロジェクトでは、同時に実行しているさまざまなタスクや、新しいタスクを開始するときに互いに重複しているタスクがあります。採点者や審査員は、ガント チャートがプロジェクトの全体的な構造と組織を評価するだけでなく、プロジェクトの実現可能性と範囲を十分に検討しているかどうかという点でも非常に役立つと考えています。プロジェクト提案の最後のセクションは、当然のことながら、参考文献リストまたは書誌になります。このセクションは言うまでもありませんが、一貫性があり、よく整理されていることを確認してください。このセクションは他のセクションと同様に重要です。参照は、全体を通して同じスタイルに従います。著者の姓とイニシャルが含まれていることを確認し、プレゼンテーションに一貫性があることを確認してください。要約すると、修正メモとドラフトを 1 つのドキュメントに構造化し、技術仕様の形式で 1 ​​ つのドキュメントにまとめる方法について説明しました。これは、基本的に実装プロセスを通じてガイドとして機能します。また、これは最初のプロジェクト提案の基礎となり、プロジェクトが成功する可能性とその実現可能性を評価し、最終レポートの形式でより詳細な技術仕様を提供する前の早い段階でフィードバックを提供します。あなた自身のために、提案の形式で有用な技術仕様を用意し、必要に応じてそれを拡張して参照できるようにする必要があります。特に、プロジェクトの実装中に進捗状況を確認し、予定どおりに進んでいることを確認する場合はそうです。

追加資料 #

アクティビティ #

Create a new document for your project proposal report. Your task will be to structure it as a technical specification document through editing and restructuring of your draft proposal so far.

Create a title page, and table of contents to include at least the following sections for the project proposal. More information about the requirements of each section is described under each heading to give you an idea of the content that should be included.

  • Introduction:
    • Provide the context and motivation for the project, You will include your problem definition, objectives and aims in this section. At the end, introduce the structure of the report (including a short summary of what you will cover in each chapter).
    • Include your literary review of past research or work in your chosen area. Make sure you include everything the reader needs to know to understand the rest of the report. This might include the wider background research or an evaluation of previous software solutions similar to the chosen topic.
  • Proposed solution
    • Focus on important points that you want the examiners to pay attention to rather than attempting a detailed description of the whole program/system.
    • This section could include requirements analysis, comparison of different choices for algorithms and data structures, overall system structure, dataflow, entity-relationship, and object diagrams as appropriate. You can include the image of your system architecture that you produced in an earlier topic to provide context and describe it.
  • Work plan:
    • Illustrate how you will carry out the software development and report writing. Consider breaking down the project into small units that can be illustrated in an activity network or Gantt chart.
    • This section will detail the sources and publication details for all the references made in the report.

Week 10: Writing the final report #

レクチャーリスト #

  • Writing the final report
    • Lecture 1: Structure of the final report
  • Software artefacts
    • Lecture 2: Commenting your code
    • Lecture 3: Demonstrating your software

レクチャー内容のメモ #

  • 最終レポート（プロジェクト報告書）について。

Structuring of the final report

プロジェクト提案と最終レポートの違いについて見ていきます。プロジェクト提案、文書、技術仕様としての提案の構造の書き方について説明しました。その点では、4 つの主要部分を詳しく説明しました。導入部では、問題の定義について説明しました。基本的には、解決しようとしている問題と、文献レビューの形式で既存の作業に関する調査の大部分を説明します。また、このセクションでは、目的と目標についても説明しました。次に、もう 1 つの重要なセクションである提案ソリューションをまとめました。ここでは、ソフトウェアの実装に採用している方法またはアプローチについて説明します。次に、3 番目のセクションである作業計画の重要性について説明しました。作業計画は、ソフトウェアの開発を開始するときに、作業を簡潔な部分に分割して、各サブタスクにどのくらいの時間がかかるかを把握できるようにするための便利な参照資料となります。最後に、参考文献リストをレポートの最後に含めました。提案書を作成し、文献レビュー中に入手したすべての参考文献をリストします。では、最終レポートが提案書と比べてどのように異なるかを見てみましょう。見栄えを良くしたいのは当然なので、タイトル ページや、読者がレポートを読み進めるのに役立つ目次などの他の規則をいくつか用意することを強くお勧めします。次に、セクションに関しては、プロジェクトとレポートの主な結果または発見を要約した約 250 語の要約を含める必要があります。要約の書き方がわからない場合は、文献レビューでいくつか目にしたことがあるかもしれません。戻って、それらの構造と基本的に要約の内容を確認してください。次に、再び序論があります。これには、問題の定義、目的と目標、および前述のように、過去または関連する作業に関する調査の大部分など、提案書の資料の一部が含まれます。これは、文献レビューを構成するものです。最終レポートで良い評価を得たいのであれば、文献レビューの更新を検討する必要があります。実装フェーズで調査または読んだものすべてについて、文献レビューでプロジェクトに関連する文献の批判的な分析を提供する必要があります。ここでは、以前の研究で使用された関連する理論、モデル、およびアプローチについて説明します。また、プロジェクトがこの以前の作業に基づいてどのように構築されているかについても説明する必要があります。次に、方法論という新しいセクションがあります。ここでは、データ収集、分析方法またはアプローチ、テストなどに使用したソフトウェアツール、選択した方法の仮定または制限など、研究または開発を実施するために基本的に使用した方法とテクニックについて説明します。提案のソリューションセクションの資料の一部を使用して、提案を構築できます。ただし、アプローチを開発するにつれて、および実装フェーズ中に、方法論セクションを更新してください。最終的なプロジェクトソフトウェアを開発するために選択した方法に関して、物事がもう少し具体的になるにつれて、基本的にこれらの詳細を記録できるようになります。もちろん、提案段階のときは、実際に開始するまで不明な点がまだたくさんあります。プロトタイプを作成してソリューションを構築します。さらに、結果と分析というセクションも含めます。ここでは、研究の結果を明確かつ簡潔に提示することを目指します。必要に応じて、表やチャート、グラフなどを使用できます。基本的には、結果を説明し、ソフトウェアによって生成された結果に関するデータの興味深い傾向やパターンについて説明します。また、ここでは、プロジェクトの目的と目標の達成という観点からソフトウェアを評価し、テストやユーザーまたはクライアントからのフィードバック、評価基準の分析を提供します。さらに、ここではプロジェクトを批判的に評価します。つまり、これが、どのように進んだか、どのように進んだか、何がうまくいったか、何がうまくいかなかったか、実装中に遭遇した障壁や困難により、方法、範囲、または焦点に関してプロジェクトの一部を調整する必要があったかどうか、もしそうなら、その理由を述べる機会です。次に、結論と呼ばれる別の新しいセクションを確認します。ここでは、基本的に、結果、プロジェクトの貢献、および将来の研究の方向性の可能性を要約します。プロジェクトが示唆する、実装フェーズ中に複雑さや時間不足のために一部の機能が削除された場合、有益または必要になります。次に、レポートで引用したすべてのソースをリストした参考文献リストがあります。標準的な引用形式では、IEE スタイルの使用をお勧めします。参考文献リストの後に、付録の形式で追加資料を含めることもできます。基本的には、参照しているコード、スニペット、サンプル、スクリーンショット (たくさんある場合)、フィードバックを利用した調査アンケートなど、プロジェクトに関連する可能性のあるものはすべて含めます。おわかりのように、提案と最終レポートには若干の違いがあります。ただし、先ほど述べたように、提案書の一部の資料を使用して開始することができます。提案書はプロジェクトの実装に着手する前に提出します。つまり、この時点では考慮していない未知の事項や課題、障壁がまだ残っている可能性があります。そのため、プロジェクトに着手する際に行ったこと、行った決定を必ずメモし、最終レポートにプロジェクトの必要な詳細を記入できるようにしてください。実装フェーズの最後まで待ってから書き上げるのではなく、最終的には行ったことをすべて文書化するのが最善です。これは、基本的に、特定の決定、設計上の決定、または特定の方法でコードを実装した理由を忘れてしまう可能性があるためです。それ以外にも、必ず事前に計画を立ててください。レポートの作成には十分な時間をかけ、早めに開始し、順調に進むように詳細な計画を立ててください。作業計画、提案書には、実装フェーズ全体にわたるレポートの作成時間を考慮する必要があります。また、集中力を維持するようにしてください。レポートは、最終的にはプロジェクトの目的と目標に焦点を当ててください。目的を明確にし、無関係な情報や脱線、あるいは本質的に曖昧な内容は避けてください。最終レポートでは、あなたが行ったことを具体的かつ明確かつ簡潔に記述するようにしてください。もちろん、これは非常に重要です。また、複雑な概念を説明するときは平易な言葉を使用し、読者に馴染みのない専門用語や技術用語の使用は避けてください。これらの用語が重要な場合は、レポートで最初に紹介するときに、簡単な言葉で定義してください。あなたが述べていることのギャップを埋めることを審査官や読者に任せたり、あなたが伝えようとしていることについて不明確または混乱させたりしないでください。そうすると、レポートの特定のセクションを再度読み直して、あなたが伝えようとしていること、およびそれがプロジェクトと関連していることを理解する必要があります。つまり、読者があなたが言おうとしていることを正確に理解できるように、明確かつ簡潔にしてください。ビジュアルを使用することもできます。前述したように、表やチャートやグラフを使用して、調査結果を説明し、レポートを読者にとってより理解しやすいものにします。また、作業の魅力とプレゼンテーションが向上します。レポートを注意深く編集および校正して、実際にエラーがなく読みやすいことを確認してください。スペルミスや語彙の選択は、作業の品質に影響を与える可能性があります。レポートは、学術的なライティング能力に基づいて評価されることを覚えておいてください。これには、最終的に書かれた作業をどのように提示するかが含まれます。要約すると、最終レポートは気が遠くなるような作業に思えるかもしれませんが、すでに途中まで進んでいることを忘れないでください。プロジェクトの実装と並行して、少しずつ作業を進める必要がある場合があります。これにより、プロジェクトの進行に合わせて、プロジェクトの詳細をすべて把握できるようになります。また、実装フェーズのさまざまな時点で他の約束のために時間が足りない場合に備えて、何かを確保することもできます。つまり、最後まで残しておかないでください。

追加資料 #

アクティビティ #

Return to the draft of your critical review, and evaluate the following points for each source or group of related sources

  • Have you included all the relevant sources, in terms of research this means those publications that are core or that you have cited several times.
  • Have you evaluated the contribution of the source to your chosen area?
  • Have you identified the relationship between this source and your proposed solution?
  • Have you critically evaluated the advantages and disadvantages proposed by the source – making it clear how you will resolve or build on these previous contributions?

In addition to this, consider the following questions when reviewing your literary review:

  • How effectively have you managed the information you have acquired for the project?
  • How well do you understand and comprehend the subject area of the project?
  • What is the extent and depth of the literature survey undertaken?
  • Does the literature survey provide a firm theoretical basis for the report/ dissertation?
  • Does your literature survey set your project in context

Week 11, 12 #

プロジェクト提案書を作成、提出する期間。2,000〜2,500 ワードでプロジェクト提案書を作成する。