TechLauncher Course Outline

Introduction

TechLauncher Overview

The TechLauncher program is for team-based activities at ANU, where the project and/or group activity undertaken is real, not synthetic. In TechLauncher you will be a team member on a project, and shall be supported by a program of tutorials at which your peers, along with experienced professional tutors/mentors, facilitate your professional development and mediate your team processes and interactions.

Expected Workload

A standard workload for full-time study at ANU is 10 hours per week per subject. In TechLauncher, a large portion of this time will be independent group work. If you are spending drastically more or less time than this, you should discuss how to manage your workload better with your your peers, tutors, or an examiner.

Below is an approximation of time allocation over a typical week in TechLauncher.

Face-to-face Activities

See the Program Dates page for a list of all whole-of-class dates associated with the semester.

See the Indicative Tutorial Schedule for a generic list of tutorial week activities.

See the Tutorial Schedule for a list of tutorial times, locations and tutors. This will be available after team formation and tutorial preferences have been considered.

Co-Taught Courses

If you would like to join a Techlauncher cohort, you can do so by enrolling in any on the following courses:

• COMP3500 - Software Engineering Project
• COMP4500 - Software Engineering Practice
• COMP8715 - Computing Project

Note: Please contact an examiner if you wish to join the cohort by enrolling in COMP3710.

Note: If you require a permission code and are undertaking a computing qualification, then please complete this form.

Teaching Staff

The course conveners are listed on the Contact page.

Tutor details will be available in Week 2, after tutorial assignments have been made.

Delivering Value

In TechLauncher you collaborate with others to deliver real value, by developing a mature process with your team and your stakeholders. Although not an exhaustive list, your stakeholders shall include:

• your client, customer/s, users, and other external stakeholders
• your teamates
• other teams, especially the team you’re shadowing or being shadowed by

The maturity of your team and team processes enable you to repeatably and predictably deliver planned/negotiated artefacts that are recognised as being of high value. By developing and investing in productive relationships with other TechLauncher teams, both your and their efforts are multiplied in terms of the recognised value produced. A team that delivers value must carefully trade off: (i) delivering project outcomes (the application, device, prototype, etc), and (ii) demonstrating professional project governance (evidence of decision-making). There is no prescribed outcome for projects, and each project will have different goals and challenges to overcome.

Determining value in a TechLauncher project

Little project value

Group is doing little development and shows little evidence of decision-making - little to no value for anyone (probably including team members!). Don’t be surprised if you have to do a make-up review, or end up failing the course

Too output focussed

Group focusses mainly on development and prototyping, with documentation and tracability lagging behind - while it might look good, this is of moderate value to the client in the long term. Groups in this category will likely pass the course.

Too process focussed

Group focusses mainly on governance, but there are few outcomes for all that work - moderate value to the client. Groups in this category will likely pass the course.

Good value delivered

Group is iteratively doing and justifying decisions, and using both to improve the next iteration - high value to the client. Groups in this category will likely achieve a credit or distinction grade.

High value delivered

Group is going above and beyond in terms of development and governance. All stakeholders actively involved and contributing. Groups in this category will likely achieve a distinction or high distinction grade.

Advise from David R.: “There needs to be evidence of management activity, however management should consume no more than 10-15% of the team’s overall weekly budget. Teams are expected to produce outputs that are relevant, value-adding, and appropriate for their project. Explicitly, this means that: (i) teams should consider and factor in outputs around planning, experimentation, research, user engagement (interviews, shadowing, testing), prototyping, generating documentation, coordinating with each other, provisioning infrastructure, testing (early!) communicating with the client… etc, not “just” generating software, and (ii) all of these activities (except shadowing) should be traceable to outcomes in the active Statement of Work.”

Resources

TechLauncher does not have a textbook, but there are many resources that might be useful for your project – too many to list.

Repositories

Make certain that your convener, tutor and shadows have access to all Project IP. With that in mind, some tools that you can use to host repositories include:

• Local CECS gitlab
• github
• bitbucket

Otherwise, in relation to hosting data, most public cloud systems have bucket stores that are fairly cheap to use.

Documentation

The degree of documentation that makes sense in a project varies. Some tools that can be helpful include:

• pitchspot
• readthedocs.io, for example.
• Doxygen
• draw.io

Design

Some projects shall require that the team design and develop a user interface. A valuable interface design considers roles, associated workflows, and how those interact over time with the system being designed. Your storyboard is something you can sketch by hand to document that, typically once you have completed a first iteration of a user story map. From there it is somewhat easy to build an interface that theoretically provides some desirable set of functionality. However, carefully designing an interface that is intuitive and seamless is something that requires your UX/UI team members engage in a deep active process with folks who will interact with your interface/tool. To drive some engagement with users who will be interacting with the system you are designing, some tools that can help include:

• Figma
• XD
• InVision

Chat

Know the names of your teammates, and please talk to each other. Some tools you can use to support that when you are not all physically together, include:

• Slack
• Discord
• Mattermost. Deploy this simply via bitnami stack

Testing, Continuous Integration, Continuous Deploymenet

Many of us dislike recipes… Let the bots handle the recipes, and let us concentrate of the creative process.

• coveralls.io
• Jenkins CI/D Server
• Chef

Agile, Kanban, Planning and Execution Monitoring

We shall list some tools in a moment, however wrt these some guidance and context is required. Teams are expected to:

• Identify tasks and activities,
• Model resources and resource availability (people, software, hosts, and other project assets),
• Model task dependencies and resource assignments,
• Plan and schedule activities,
• Monitor and track execution of project activities and re-plan as required, AND
• provide executive reporting based on the measurements you are making.

Advisory: In terms of the low level management of day-to-day task execution, the following list of tools can be helpful. If your team adopts one of these tools, we expect you to codify a team process around the use of this tool, and for your team’s cadence against status capture and reporting to be regular, and consistent. For example, in the worst case you have a chaotic dysfunctional team, so that one team member is unilaterally active on this tool before each assessment audit. On the other hand, a mature team develops and codifies a team process, and fine tunes that process over time. In that case we shall see regular and coordinated interaction with a low level status reporting tool, such as:

• notion
• trello
• zenhub
• pivotal
• jira
• miro

Exactly what tasks your team identifies, and the activities your team identifies, should be appropriate to the project you are undertaking. Some teams will schedule shift work against a large task. This makes sense in case team members are homogeneous. Some teams are required to deliver a presentation, demo or performance. Here, we expect to see rehearsals scheduled, and for there to be measurable/reportable objectives and outcomes against those. In many cases the team will undertake activities as per a modern agile methodology – with planning, estimation, and day-to-day resource assignments as per scrum. Irrespective of the structure and coordination required, we expect to see some evidence of reflection by the team, consideration of the measurements (velocity, inventory/record-of-repertoire, reduction in polygons, etc.), and a redefinition/refinement of the team processes. Meaningful reflection and refinement of team process is expected as the team matures, and becomes better at predicting and tracking the measurable outcomes of activities (inc. delivery of Project IP to a client, and recording the client’s degree of acceptance of any delivered artefact).

Professional Guidance

Often groups in TechLauncher will describe their project approach as ‘agile’ but are better described as ‘firefighting poorly designed systems’. The SEBoK and the SWEBoK and PMBoK are great resources for putting proper, auditable processes in place so your team can be ‘agile’!

Ideation and Processes for Proceeding under Uncertainty

The below are not prescribed tasks or resources, but rather provided for your information.

• Steve Blank, How to Build a Startup
• J. Patton and P. Economy. User Story Mapping: Discover the Whole Story, Build the Right Product. 2014.
• M. Cohn. Agile Estimating and Planning. 2005.
• A. Osterwalder et al. Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. 2010.
• E. Ries. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. 2011.

Related Standards

Many ISO/IEEE standards can be accessed via the ANU Library. Many ANSI standards can be accessed through the National Library of Australia. Some common standards for project management are:

• ISO/IEC/IEEE 15288 - Systems and software engineering—System life cycle processes
• ANSI/EIA‐632 - Processes for engineering a system
• ISO/IEC/IEEE 26702 - Systems engineering—Application and management of the systems engineering process
• ISO/IEC/IEEE 29148 - Software and systems engineering—Life cycle processes—requirements engineering
• ISO/IEC/IEEE 16326 - Systems and software engineering—Life cycle processes—Project management

Evaluation

Summary of Evaluation Processes

The processes by which your work and individual contributions are evaluated is designed to emulate project work in a real-world. These processes are centered around three evaluation themes:

• Evaluation of your group project work
• Provision of constructive feedback for other teams
• Reflecting and showcasing your learning in the course

The majority of evaluation activities are coordinated around a ‘many eyes” process. Details about this process can be found on the Many Eyes Process page.

For a detailed listing of the evaluation dates and requirements, see the guide.

Learning Outcomes

Each of the above courses have slightly different learning outcomes, depending on year level and expectations. However, all courses share these five common outcomes:

1. Technical. Synthesise technical knowledge and approaches to generate solutions to a complex problem.
2. Problem Solving. Develop, analyse, and critically evaluate alternative options in order to justify and generate solutions in a real-world project.
3. Teamwork. Apply project management and organisational skills to produce time-sensitive deliverables in a multi-disciplinary team.
4. Stakeholder Engagement. Effective, collaborative, timely, and recorded engagement with all stakeholders. Professional and accessible communication channels and media.
5. Reflection. Demonstrate and reflect on leadership and creativity as an individual and within a multi-disciplinary team.

For specific learning outcomes against each course, see the Programs & Courses sites listed above.

Tools to Assist

It is important that all participants, including external, are able to fully participate in all aspects of TechLauncher. For this reason, we need to employ additional systems which can be accessed by all TechLauncher participants and can be used to manage all TechLauncher resources.

Expectations and processes

Absences

It is expected that you will attend all classes and meetings, but as senior students at ANU the responsibility is on you.

You should attend all tutorials to provide a coherent Tag Report when you do the Project Audit. If you don’t attend tutorials for your group, you should have a good reason for not turning up and communicate this clearly with your team (or others might moderate you down!). Absences will be recorded in project minutes.

Late submissions and extensions

Reasonable requests for extensions, special consideration and accessibility will be considered with courteous regard to the due dates. If you have any concerns, please talk to your team members, tutors and convener (very) early. No leeway will be offered after due dates.

Late submission of deliverables without an extension shall not be accepted. Your participation and completion of evaluation tasks determines the mark you receive for that task. A mark of zero will be awarded in case your work is not submitted on time.

Feedback and Comments

Feedback is widely misunderstood concept in education. In systems theory, feedback is a systems process that drives behaviour (such as negative feedback in an electronics circuit) towards an objective, rather than being the outcome of a process.

In this course, there are many formal and informal processes to collect formative feedback to help you submit the best work you can. These include regular opportunities with your tutor for specific feedback before project reviews. Your peers, both in your team and otherwise, are a central part of this process.

Feedback on your progress will be provided through the ‘many eyes’ process. This feedback will be returned rapidly to teams so that teams can reflect and react to this feedback. All provided written materials shall be available to you via the TechLauncher Portal system. Shortly after each evaluation activity is scheduled to be completed you shall receive a mark associated with that activity.

Marking and Assessment

As described in the Evaluation Guide, each task is undertaken in stages.

1. Qualitative evaluations of your work are collected from multiple sources (self, team, shadows, tutors, clients)
2. Your examiners (usually the course convenors), then use this information to determine a numeric mark for your work
3. You will receive a report detailing the above via the TechLauncher Portal. You are asked to reflect on this feedback and take actions to deal with areas in need of improvement.

If you have a problem with the marks you receive in relation to the many-eyes activities, there is a process that you can follow to come to a resolution on the issue. This process must be initiated within two weeks of receiving your mark.

• discuss the issue with your tutor
• your tutor will provide further comments or clarification if needed
• if the issue remains unresolved, you can
• ask the course convener to re-mark the assessment - this requires you to first submit in writing exactly what your concerns are and how the marking has missed some significant aspect of your work
• ask the course convener if you can resubmit (typically reserved for failed work) - this requires negotiation with the course convener
• if you are unhappy with the course convener’s response, you can appeal to the Associate Director (Academic), in consultation with the course convener as described by the appropriate policy

Examiners’ Meetings

Final grades are subject to deliberations at school and college examiners’ meetings.

Academic Integrity

All students must read and understand the ANU guidelines on Academic honesty & plagiarism.

Any sign of academic misconduct in any assessment task will be fully investigated in accordance with the ANU Academic Misconduct Rule 2015.

Turnitin Submissions

This advise only applies to assessment that is not recorded via the TechLauncher portal

The following applies to your Work Portfolio Package and your team’s Showcase Video. Both are assessment items.

The ANU is using Turnitin to enhance student citation and referencing techniques, and to assess assignment submissions as a component of the University’s approach to managing Academic Integrity. For additional information regarding Turnitin please visit the ANU Online website. Students may choose not to submit assessment items through Turnitin. In this instance you will be required to submit, alongside the assessment item itself, copies of all references included in the assessment item.

Submission

Digital copies of WPP and Showcase assesment items shall stay in the relevant submission on Wattle.

Resubmission of Assessable Works

Groups may be required to resubmit work where the submission is deemed inappropriate, or requires major revision. At their discretion, the course conveners and examiners can require that students resubmit records, where an initial record is not appropriate.

Referencing Requirements

There are no specific referencing requirements in TechLauncher. You should consult with your client where referencing is required.

Relevant University Policies

Policies for Studying at ANU

ANU has educational policies, procedures and guidelines, which are designed to ensure that staff and students are aware of the University’s academic standards, and implement them. You can find the University’s education policies and an explanatory glossary at: http://policies.anu.edu.au/

Students are expected to have read the Academic Misconduct Rule before the commencement of their course. Other key policies include:

• Student Assessment (Coursework)
• Student Surveys and Evaluations

Course Improvement

There will be opportunities to provide feedback throughout the course to the course coordinators or your tutors. There will be a formal session for feedback.

One of the key formal ways students have to provide feedback is through Student Experience of Learning Support (SELS) surveys. The feedback given in these surveys is anonymous and provides the Colleges, University Education Committee and Academic Board with opportunities to recognise excellent teaching, and opportunities for improvement.

For more information on student surveys at ANU and reports on the feedback provided on ANU courses, go to http://unistats.anu.edu.au/surveys/selt/students/ and http://unistats.anu.edu.au/surveys/selt/results/learning/

We ask all students to complete their SELS during the final tutorial in TechLauncher.

Student support

Support for Students

The University offers a number of support services for students. Information on these is available online from https://services.anu.edu.au/business-units/division-of-student-life. TechLauncher encourages diversity and inclusion - if there are issues that have not been addressed that need to be, please get in touch with the conveners, or someone you feel comfortable with who can on your behalf.

Useful Links

The following links may be useful or worth understanding:

• ANU Timetable
• Engineers Australia Graduate Competencies

When researching journals for your project, many journals can be accessed on campus, or off-campus using the ANU’s reverse proxy server: https://login.virtual.anu.edu.au/login