This assignment is graded out of 90 marks, and is worth 30% of the PDP (5N2927) module.
The summary breakdown of marks is as follows:
Design - Algorithm, documented using a flowchart: 15 marks (16.66%)
Development - accurate programming to complete the specified task including: 45 marks (50%)
code runs without error
good use of variable and function names (semantic, lower/snake_case, length)
accurate prompts for user input
useful information output to users
use of math, relational and boolean operators
functions created as per guidelines here
correct use of conditionals including if/elif/else, try/except or assert, loops
Testing - Unit, Integration and user tests: 15 marks (16.66%)
Documentation and QA - File headers, docstrings, PEP8 compliant: 15 marks (16.66%)
This first part could be considered the most important, or the least (see here for flowchart advice and guidance) but an important aspect is that flowcharts are system independent- that is to say- they do not depend on the language, and could be brought into being using any one of a multitude of coding languages.
This is the design stage of the SDLC, where the requirements are represented by a diagram that shows visually what the final product will achieve. The flowchart illustrates only functional requirements- not no-functional requirements such as speed or the quality of the interface.
It should serve to help you clarify the sequence needed, and it can further assist with identifying what functions may be useful as part of building a solution iteratively- step by step, bit by bit.
This will all be submitted as code.
Here you can see that there are several files involved in the solution. Each function should be tested individually to make sure that it is working as expected.
This may comprise a mixture of code, test tables, screenshots and or video evidence. The most important element here is to show evidence of comprehensive testing. Using doctest, pytest or unittest may make this evidence clearer to see, and will almost certainly - if used in conjunction with test-tables- catch errors that can easily escape manual testing.
Test tables are a way to show what tests- including testing for and catching or handling invalid data- will be completed on a function or set of functions.
This is described as implementing code solutions to industry standards. For our purposes, this will mean:
All files maintain a consistent and appropriate header such as this Google format, i.e. a comment followed by a docstring for the file (module) contained in a multiline str.
# -*- coding: utf-8 -*-
'''
@author: mjones
@date: dd-mmm-yyyy
@project: example
@description: like it says on the tin
'''
In all cases, these are the FIRST lines of text in a python file!
All functions use a clear and consistent docstring format as shown here
All code complies with the PEP8 standard. In VS Code this is included in the plugin which uses pycodestyle(E302). Repl also includes some limited style checking, but will not flag some serious violations. You may find this online checker useful and I tried out this website to check python style.
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
Aside from being a requirement for all assignments, it is important to write code that is readable, as well as consistent.
For our programs, we will use the following schema where such elements are present in our code:
file header information including the elements shown above
imports of any other modules or functions from modules we will use in our program
declare and initialise global variables (avoid where possible) or CONSTANTS
functions and classes (if used)
main body of code- often this may simply be:
if __name__ == "__main__:
main()