Get 15% off on your first assignment order and best assignment writing service for HND AssignmentsOrder Now

Have Any Question?

UK +4474648-84564

Free Support


COM709 Computer Fundamentals Assignment Help


COM709 Computer Fundamentals

Personal Learning Record Assignment Solent University

Unit Title: Computer Fundamentals
Unit Code: COM709
Unit Leader: Dr Andy Farnell
Level: 7
Assessment Title: Personal Learning Record
Assessment Number: 1
Assessment Type: AE1
Restrictions on Time/Word Count: 2500 words (Equivalent code metric : approx. 100-200 well commented lines of code)
Consequence of not meeting time/word count limit: There is no penalty for submitting below the word/count limit, but students should be aware that there is a risk they may not maximise their potential mark.
Individual/Group: Individual
Assessment Weighting: 100%
Issue Date: Week commencing 06/09/2020
Hand In Date: January 8th 2021
Planned Feedback Date: Within 4 weeks from submission
Mode of Submission: On-line
Number of copies to be submitted: 1

Anonymous Marking

This assessment: is exempt from anonymous marking.

Assessment Task

October 19, 2020

Create a program to meet given requirements within a deadline

1.1 Outline

To pass this module assessment you must write a program that meets all the requirements set out in a “requirements specification”. This models the real-world of software  engineering (S.E.) development.

Ability to carefully and seriously follow each of the steps will set you up for a good foundation in a development career. You will be given some examples of exercises from previous classes to help you understand what is expected.

1.2 Objectives

The program will be in Python3 language. It must use only the allowed libraries specified.

The program will be reviewed by the marker (human) for style and good structural technique. It will be tested by another program for correctness, robustness and performance.

You must deliver your program according to the packaging requirements given.

You must document your code as per instructions learned in the course, by using the Pydoc commenting system. You will have a limited time to complete the brief which reflects a realistic time constraint for the task at your level of ability.

In summary, your final mark will therefore depend on:

  • Correctness: The program does what it should
  • Performance and efficiency: The program works efficiently in space and time
  • Delivery: Timeliness and size is correct. Program is delivered on time and on code budget. Program includes only libraries allowed by the non-functional requirements.
  • Coverage/Features: Has the program covered all of the features/points given in the requirements specification to solve the problem?
  • Robustness: Does the program withstand abnormal input
  • Style: Theoretically sound style: Elegant code and use of best S.E. practices that show you have taken on board the theories in the course.

Please see the Assessment criteria Matrix in Section 2.0 which explains the weighting and organisation of these assessment points.

1.3 Detailed Instructions

  • You must follow the functional requirement specifications
  • You must follow the non-functional requirement specifications
  • You must deliver the product on time for the deadline
  • You must deliver all core parts of the product
  • You must deliver the product in the specified form

1.4 Date for your receipt of requirements specification

  • Before Thursday 19th November 2020 at 16h00

1.5 Delivery date

  • Friday 8th of January 2021 at 16h00

1.6 Non-Functional (constraints)

  • Program is to be written in Python >= v.3.20
  • Program must ONLY use specified libraries
    • Built-ins (os, sys, csv etc)
  • Program must execute from the command line
  • Program must be self-contained
    • a single python file
    • it should not take any command line options
    • it should execute entirely in its directory without system specific dependencies
    • no other config files or dependencies necessary

1.7 Delivery requirements

  • The program must be named program.py
  • it should be the only file in a .zip archive
  • the .zip file must be named as your student number
    • for example: Q1234567.zip

Tasks should be completed on an ongoing basis and you should request feedback to try and achieve improvement on your work before your final submission.

Many of the tasks covered in this unit are knowledge required for understanding computer fundamentals, subsequently, leading to understanding of high-level computer techniques and tools requires in real world, especially in today’s industry. Therefore, it is important that you aim to achieve a high level of understanding, and do not just aim towards completion of all tasks and assignments. 

Assessment criteria

CRITERIA F1 – F3 D1 – D3 C1 – C3 B1 – B3 A1 – A4


Code does not run in any meaningful way. No output produced. Code produces numerous serious errors or aborts during run. Serious Errors in the format or validity of output. Code runs and mostly produces valid output for main test cases. Code passes almost all tests with a few minor errors Code produces perfect output for all test cases



Program freezes or will not run . No evidence of defensive coding. Program is terribly slow and fails for many input conditions. No evidence of defensive coding. No evidence the program has been fully tested. Program runs adequately but fails on a few edge cases. Some evidence the developer has tried to mitigate. Highly robust program that has been well tested. Fails only in extreme conditions. Bulletproof program that uses formal unit-test suite to prove robustness.



A broken program, badly packaged. Unrunnable without major interventions, or cannot be made to run at all. Few or no features implemented. A runnable program. Some delivery issues, unpacks from/as wrong file type file. Minor naming, file, path or library convention errors. Some important features not implemented. Program delivered according to bare requirements, implementing most of the features. Program delivered according to requirements, implementing almost all features Perfect install and run of program inplementing ALL requirement features.
standing and proper use

tTheoretical understanding


Good Practiceechnologies

Poorly written, uncommented code. Mostly or wholly copied without understanding. S Code is weak and only a basic understanding is shown. Well written, modular code that shows some understanding of theory and good programming practices. Compact and well documented modular code with clear understanding of good principles. Elegant solutions to problem with exceptionally clear documentation and full test suite.

Learning Outcomes

This assessment will enable students to demonstrate in full or in part the learning outcomes identified in the unit descriptors

Late Submissions

Students are reminded that:

  1. If this assessment is submitted late i.e. within 5 working days of the submission deadline, the mark will be capped at 40% if a pass mark is achieved;
  2. If this assessment is submitted later than 5 working days after the submission deadline, the work will be regarded as a non-submission and will be awarded a zero;
  • If this assessment is being submitted as a referred piece of work (second or third attempt) then it must be submitted by the deadline date; any Refer assessment submitted late will be regarded as a non-submission and will be awarded a zero.


Extenuating Circumstances

The University’s Extenuating Circumstances procedure is in place if there are genuine circumstances that may prevent a student submitting an assessment. If students are not ‘fit to study’, they can either request an extension to the submission deadline of 5 working days or they can request to submit the assessment at the next opportunity (Defer).  In both instances students must submit an EC application with relevant evidence.   If accepted by the EC Panel there will be no academic penalty for late submission or non-submission dependent on what is requested.  Students are reminded that EC covers only short term issues (20 working days) and that if they experience longer term matters that impact on learning then they must contact the Student Hub for advice.

A summary of guidance notes for students is given below:


Academic Misconduct

Any submission must be students’ own work and, where facts or ideas have been used from other sources, these sources must be appropriately referenced. The University’s Academic Handbook includes the definitions of all practices that will be deemed to constitute academic misconduct.  Students should check this link before submitting their work.

Procedures relating to student academic misconduct are given below:


Ethics Policy

The work being carried out by students must be in compliance with the Ethics Policy. Where there is an ethical issue, as specified within the Ethics Policy, then students will need an ethics release or an ethical approval prior to the start of the project.

The Ethics Policy is contained within Section 2S of the Academic Handbook:


Grade marking

The University uses a letter grade scale for the marking of assessments. Unless students have been specifically informed otherwise their marked assignment will be awarded a letter grade. More detailed information on grade marking and the grade scale can be found on the portal and in the Student Handbook.


Guidance for online submission through Solent Online Learning (SOL)