Learning Objectives
Our Studio Subject Learning Objectives (SLO’s)
Upon successful completion of this subject students should be able to:
|
Learning Objective: Process & Collaboration
RESOURCES & STRATEGIES
- – Approach perceived stakeholders with solution for ideas or comments. (SLO 1, 2, 4)
– Refine brief from stakeholders (SLO 1, 2).
– Ideation surrounding brief & review (SLO 2, 3).
– Refinement of idea to a solution to build prototype & review (SLO 3, 4, 5).
– Building of prototype for initial design phase & review (SLO 5).
– Get assistance when required with prototyping components (SLO 4)
WHAT IS TO BE ASSESSED
-
- Update progress of design process in blog posts on blackburn.id.au. (SLO 2, 3 &4)
- Code properly commented and explained (SLO 2, 3 & 4).
- How the prototype is performing with documentation of collaborative efforts throughout the design process. (SLO 4)
CRITERIA FOR ASSESSMENT
-
- Have I documented a methodical approach from consultation to prototyping?
- Can another programmer understand my code and make changes if asked?
- Collaborative efforts documented where necessary.
Learning Objective: Hardware, Design & implementation
RESOURCES & STRATEGIES
- – Find peers that could assist with their knowledge (SLO 3, 4, 5).
– Research different technologies & implementations of hardware that could achieve possible solutions (SLO1, 2).
– Find expert knowledge of hardware to achieve desired design. (SLO 1, 2, 4)
WHAT IS TO BE ASSESSED
- – Does the hardware perform as intended? (SLO 3)
– Have you documented difficulties, solutions, assistance and references from assistance? (Who, When and What) (SLO 2, 3, 4, 5)
CRITERIA FOR ASSESSMENT
- – Documentation references collaborative efforts as required.
– Demonstrations of hardware performance and/or testing.
Learning Objective: Software & Programming
RESOURCES & STRATEGIES
- – Find peers that could assist with their knowledge (SLO 3, 4, 5).
– Research different languages, libraries & implementations of software and languages that could achieve possible solutions (SLO1, 2).
– Find expert knowledge of software implementations to achieve desired design. (SLO 1, 2, 4)
WHAT IS TO BE ASSESSED
- – Does the software perform as intended? (SLO 3)
– Have you documented difficulties, solutions, assistance and references from assistance? (Who, When and What) (SLO 2, 3, 4, 5)
CRITERIA FOR ASSESSMENT
- – Documentation references collaborative efforts as required.
– Demonstrations of hardware performance and/or testing.
Learning Objective: Prototyping
RESOURCES & STRATEGIES
- – Hardware components assembled and operational as technical package for prototype (SLO 2, 3, 4).
– Software components operational on data pulled from hardware components (SLO 2, 3, 4).
– Feedback from operation on sensor data (SLO 2, 3, 4).
– Housing for prototype printed encasing technical package (SLO 2, 3, 4).
– Review of initial prototype with documented improvements. (SLO 4, 5)
– Appropriately review and make changes to the strain gauge to minimse impact on housing and there for user. (SLO 3, 4)
WHAT IS TO BE ASSESSED
- – Does the housing house the technical package?
– Does the hardware / technical package collect sensor data?
– Does the software pull sensor data and perform some operation on sensor data?
– Does the user get feedback from operation performed on sensor data?
– Has other strain gauges been explored for implementation?
CRITERIA FOR ASSESSMENT
- Does the prototype perform as intended from resources and strategy criteria?
Has the prototype explored usability for end user and the business to implement the product?
Learning Objective: Documentation
RESOURCES & STRATEGIES
- – Making use of software to work collaborative with the Studio Team (SLO 2, 3, 4, 5).
– Built portfolio live online with posts updating progress and process of building prototype (SLO 2, 3, 4, 5).
– Continual update of online posts as design process is progressing (SLO 1, 2, 4, 5).
– Complete ‘In-code’ documentation clearly understandable.
WHAT IS TO BE ASSESSED
-
- Is the design process documented?
- Can the documentation be viewed online?
- Are possible stakeholders engaged?
- Is the coding style easy to read?
CRITERIA FOR ASSESSMENT
- – Is the design process documented?
– Can the documentation be viewed online?
– Are possible stakeholders engaged?
– Is critical analysis of the design process documented?
– Can another programmer understand the purpose and interpret the code.
Change Log
Week 2
Documentation
- Resources & Strategies
- Updated requirements for documentation to include ‘in-code’ documentation.
What is to be assessed
- Is the coding style is easy to read.
Criteria For Assessment
- If another programmer can understand the purpose and interpret the code.
Design Process
- Learning Objectives
- Changed from Design Process to Design Process & Collaboration
Resources & Strategies
- Get Assistance where required for building prototype.
What is to be assessed
- How the prototype is performing with documentation of assistance & collaboration.
Criteria For Assessment
- Collaborative efforts are documented where necessary.
Week 3
Prototyping
- Resources & Strategies
- Explore different technical packaging for better usability and data collection trade off.
What is to be assessed
- Has alternate strain gauges been explored for better usability
Criteria For Assessment
- take into account use of device
Hardware Design & Implementatrion
- Resources & Strategies
- Look at differing hardware and appropriate applications for user.
What is to be assessed
- is there documentation of hardware exploration.
Criteria For Assessment
- More than one design for hardware documented.