Complexity

With such a variety of projects and matching solutions, it is important to give learners a project that will stretch and demonstrate their skills. Judging the complexity of a project is not a straight forward task and if you are in doubt you should consult NIS for guidance. The following is a set of rough guidelines:

· Options and Big O Notation: if a problem has only one set solution then this is normally not considered to be a complex problem. Ideally learners should be trying to write efficient algorithms to help solve their client's problems. If a task allows for a variety of algorithms each of differing efficiency then this suggests that they are tackling a complex problem. They can then be judged on the efficiency of their solution, amongst other things.

· Data volumes: if a solution can handle large amounts of data at once this suggests a complex solution. This might be the difference between a single user revision game and a revision game collecting and comparing the results from dozens of users. Or, this might be the difference between a scientific analysis tool collecting and processing information from multiple sensors as opposed to one.

· Additional languages: some languages may be considered more complex to use than others. For example if a learner creates the same project in Lisp or C++, then the final project may be considered of a higher complexity to one created in VB.NET.

· A project may cover several areas, matching different complexity levels in each area. Projects aren't expected to be judged complex in each category and some complex projects may only cover one area. A holistic judgement should be applied to each project.

If complexity was judged on a scale of 1 to 4 (with 4 being the most complex project), the following table illustrates different levels of complexity.