Report

[klikooo]

Chapters

• Introduction
  • Process description
  • Project methodology -> goals
• Problem description
  • Needs of client
  • Problem Analysis
  • How do we fix the problem
  • Requirements
• Full prototype
  • MultiChain compatible with travel document
  • How is a transaction build
  • Screenshots?
  • Response from a municipality (if we can get an interview with someone)
• Performance analysis
  • Verifying a single transactions => brainpool vs secp
  • Creating elections
  • How fast is the chain downloaded and processed
  • Size of chain
  • Average waiting time for a transaction
  • Security
    • Description of the key aspects involving security
    • Analysis of security of used concepts
      • Blockchain
      • Crypto passport
• Quality assurance
  • SIG feedback
    • Explain why not all libraries where fully uploaded (see comment Pouwelse June 14th)
    • How did we address the feedback?
    • Sig II feedback (when on time, otherwise just add to the version that gets uploaded to the repository)
  • Multichain tests
  • Other tests
• Societal impact
  • Political response
  • Required legislative changes
  • Trust in the system
  • Positive and negative changes for voters
• Summary
• Conclusion & Discussion
  • Encountered difficulties
• Further improvements:
  • Scanning of face and check with picture of travel document
  • Proxy voting (maybe)
    • Enforce max 3 ballots in blockchain
  • Don't specify with which document you want to vote, just you want to vote digital
  • Multisig with government priv key to retract voting rights
  • voting with drivers license
  • Use the metadata capabilites of MultiChain and store a password, so a voter can redeem its voting right with an ID and a password

Other

• UX implementation [W]
  • Link with trust (blue is peaceful/trustworthy)
• Add UML diagrams
• Node organization
• Clear description of what the difference is between a public key and address
• Influence in other problems which require ID
• Infosheet as an appendix
• reference to original problem description and how our solution differs from it.
• Add a paragraph about the ethical implications. (probably mostly about privacy, stemgeheim etc.)

From Pouwelse

• MOSCOW pointer sentence in intro + 1 line this is a thesis project.
• blockchain and e-passport prototype (suggestion title for Ch 3)
• fault-tolerance and attack-resilience
  • summary
• thousands votes are lost in the last election.
• with accusations that Russia has electronically attacked US-presential elections..
• easy to read picture for chapter 1 or 2 (illustrate analog voting pass).
• intro : we use the blockchain as a tamper-proof database. ensure integrity
• all appendixes are pointed to and have intro sentence.
• Voting passes from a live blockchain (suggestion title for Ch 4)
• add screenshots to chapters
• chapter 6: MBytes ?
• needs overall polish
• Explain that voter helper app was not implemented

Main requirements

Requirements for the formal form of the final report. The report…

• Must be well structured. Each section, sub-section should have a clear purpose. Paragraphs
  should open with a topic sentence and the rest of the paragraph should support the topic.
• Must contain at least 6 sections. Sections should at least include: a foreword, a table of
  contents, a summary, an introduction, problem definition and problem analysis, the design,
  the implementations, the conclusions, discuss and recommendations, a conclusion, a
  reference list. Note that different structures will be more appropriate for different projects.
• Must include references to the references or other sources that were analyzed during the
  research phase. Please check that your references are properly and consistently formatted.
• Must be spell- and grammar-checked. Check that abbreviations are defined at their first use.
  Check that tables and figures are labeled with captions.
• Must include a title page. Make sure not to forget: name of the members of the team and the
  Bachelor Project Committee (Coach, Client, Bachelor Project Coordinator). Include your
  student number in the email that you send to your Committee, but not in the report.
• Must include the Infosheet as an appendix. (See below for instructions.)
• Must include the research report (10 pages) either as an appendix or integrated into the
  report.
• Should include the original project description as an appendix.
• Should be 30-50 pages (plus appendices, if necessary).
• Must include the first feedback of the SIG, how the team addressed the feedback, and the
  second feedback of the SIG (if necessary, the second feedback of the SIG can be added after
  the final presentation and before uploading the report to http://repository.tudelft.nl)
• The report is a public document. Proprietary information should be kept to the minimum
  necessary. It should be included in an appendix that can be removed before publishing the
  report to http://repository.tudelft.nl

List of some requirements of report

• Has the team remembered to include a clear description of the problem that is addressed by the
  project? Does the description include mention of the immediate context of the project, including the
  needs and the motivation of the Client?
• Is the larger context and vision of the project described? What is the potential impact on day-today
  business or business, on people’s daily lives, on society at large?
• Is the solution proposed by the team clearly described?
• Is the software development methodology chosen by the team clear and well justified?
  10
  2017 General Guide Computer Science Bachelor Project
• Is the process by which the team arrived at its solution to solution clearly described? Does it
  reflect the problem analysis that was carried out and the research questions that were addressed?
  Does the report include the appropriate references?
• Are the requirements clear? Do they have an appropriate level of detail? Are they prioritized?
• Is it clear that the team developed success criteria, i.e., did they have a clear picture at the
  beginning of the project how they would recognize success when they achieved it?
• Are the system specifications complete? Do they reflect both the big picture and the details
  needed for implementation? Are UML diagrams used to support understanding of the application?
  Are they used appropriately (communicate what is essential, but also avoid redundancy)?
• Does the report include plans for quality control and testing?
• Does the report allow the reader to understand how the software development methodology
  was applied? Does the report allow the reader to understand the division of labor among members
  of the team and how the team communicated (both among themselves and with the Coach and the
  Client)?
• Did the team remember to include a complete description of the final product? (Are graphics
  used appropriately to this end?)
• Does the report close the loop (i.e., provide evidence that the initial problem was solved)?
• Does the report include the necessary background information? This should be the information
  needed by someone with a technical background, but not necessarily one lying directly in the field
  of the project to understand it? (Or think about the more specific question, “Would the Dean be able
  to follow it?” http://www.ewi.tudelft.nl/en/the-faculty/dean/)
• Is something that the team spent a lot of time on not mentioned in the report? Did the team
  make any important decisions that do not appear in the report?
• Are there important insights about what the team feels that they should have done differently
  in retrospect that are not included in the report?
• Does the team have recommendations for the Client that were not included in the report?
• Would this report allow other similar teams to understand what was done, in order to extend
  this project or to create a similar one?
• Does the report as a whole convey to the reader that the team has the software development
  experience necessary in order to carry out a follow-up contract? i.e., that if the team were assigned
  another software development project by a Client, the team could carry it out as successfully as they
  carried out this one.
• Although all bachelor projects are software development projects and follow a particular
  pattern, in the end every project has a unique aspect to it. Does the report as a whole communicate
  how this project was special? Are there innovative aspects that should be more clearly emphasized?
  The report is the “official” record of the bachelor project and is published to
  http://repository.tudelft.nl. Is the team happy that the report adequately represents the effort that
  they invested into the project and the solution and insights that they achieved?

[landgenoot]