When creating documentation towards, or, for a system, there are no specifics or rules to how to approach the documenting of the creation or design of the system. However, it is agreed that planning and documentation is a key requirement.
There are a number of design resources that can be used, these are;
Structure Charts
These are hierarchal documents that are used to display components of a system to a detailed level. For example, within a computer program, a range of operators, functions and methods that may be segmented.
This type of prototyping use media that is not like the final output, for example, this could be the use of paper and or cardboard to give a sense of structure.
The benefit of using low fidelity prototyping is that it is quick, cheap and easily changed. Classic examples of this are the use of sketches of screens in a sequence that a user would follow.
High Fidelity Prototyping
This type of prototyping is linked closer to the final product output media and enables a potential experience of the final system. These prototypes can be built in environments like Visual Basic .Net and Powerpoint
The Aims of prototyping in software
The aim and purpose of prototyping in software is to target areas that may make a system clunky and usable for users to use and understand. This look and feel effect that a prototype can provide can provide developers further insights to the functional inputs and outputs against user requirements.
Possibly the most vital parts of any systems design is the testing stage. Testing the design of a purposed prototype is an opportunity to perfect and hone a prototype to meet its intended purpose and function. It is important to log all of the stages and tests undertaken, this includes the following areas.
Any testing should be against the original specification and design requirements that the client had. This will enable testers to assess the impact of the tests against the product and offer suggestions against how that thing can be updated or improved.
Links to Learning Outcomes |
Links to Assessment criteria |
|
---|---|---|
LO3 Be able to design and implement user interfaces |
P5 test the HCIs created M3 explain how the effectiveness of HCIs may be measured. P6 document the HCIs created. D2 evaluate the HCIs developed. |
Qualitative - Opinion, verbal and written viewpoints.
Quantitative- Number and numerical data capture
Learning Capture - Teachers allocate time at the end of the session for the group to write down what they think they have learned. The information shared helps the teacher to see which content he may need to revisit and so shapes future planning.