Skip navigation
The Australian National University

COMP3530 and COMP6353

Panels, Speakers and Resources

Overview

This page presents the COMP3530/COMP6353 course schedule. It identifies the topic to be covered each week, the panelists involved (with short bios) and a set of associated resources.

Each weekly entry also includes some questions you might consider when writing your Learning Portfolio. These are only suggested starting points.

Note that some sessions may be moved around as panelists are finalised.

Preparation

Before every panel, each student is required to:

  • Study the associated resources, and
  • Prepare a question they would like to ask the panel.

Panel recordings

We will do our best to record each panel session. Recordings will be posted to the COMP3530 Wattle site.

Quick Links

Week 1 (Monday, 18 Feb)
Course Introduction and Overview

Week 2 (Monday, 25 Feb)
Systems Thinking

Week 3 (Monday, 4 Mar)
Systems Engineering

Week 4 (Monday, 11 Mar)
PUBLIC HOLIDAY

Week 5 (Monday, 18 Mar)
Requirements Engineering

Week 6 (Monday, 25 Mar)
The Systems Engineering Team - the role of Software Engineers

Mid Semester Break (9Apr-20Apr)
System Safety

Week 7 (Monday, 15 Apr)
System Architecture

Week 8 (Monday, 22 Apr)
Model-Based Systems Engineering and Simulation

Week 9 (Monday, 29 Apr)
Human Error in Complex Systems

Week 10 (Monday, 6 May)
System Dynamics

Week 11 (Monday, 13 May)
Sustainability

Week 12 (Monday, 20 May)
The Big Picture

Week 13 (Monday, 27 May)
'The Unwritten Laws of Engineering' and Examination Preparation

First Teaching Period

  • Week 6 (Monday, 25 Mar)

    The Systems Engineering Team - the role of Software Engineers

    This week we will look at the role that Software Engineers play in Systems Engineering. While the Panel session will cover this from a practitioners perspective, it is also interesting to look at how the discipline more generally is recognising the importance of software engineering within the context of systems engineering. This week's readings provide a taste for this.

    • Panelists
    • Resources
      • ISO/IEC 12207 and ISO/IEC 15288 are international system and software engineering standards. 12207 was developed by the software engineering community to define Software Life Cycle Processes, while 15288 was developed by the Systems Engineering community to address System Life Cycle Processes. While the two standards are similar, 12207 originally focused on software and did not say much about the broader systems context. 15288, on the other hand, started out treating software as just another system component. In recent years there has been an effort to harmonise the standards as reflected in ISO/IEC 15288 (2008) as "Changes in this revision of ISO/IEC 15288 were developed in conjunction with a corresponding revision of ISO/IEC 12207. The purpose of these revisions is to better align the two International Standards to facilitate their joint use. This alignment takes the first step toward harmonization of the structures and contents of the two International Standards, while supporting the requirements of the assessment community. This alignment provides the foundation to facilitate evolution to an integrated and fully harmonized treatment of life cycle processes.".

        ISO/IEC 12207 and ISO/IEC 15288 are not freely available standards. However, the following Google searches may be useful:

      • The role of software engineers can also be considered within the context of multi-disciplinary teams and approaches to engineering. For example, the mission of MIT's Engineering Systems Division is "To solve previously intractable engineering systems problems by integrating approaches based on engineering, management, and social sciences, using new framing and modeling methodologies." They achieve this by developing and applying "innovative and interdisciplinary approaches". Another interesting example is the emerging need to develop and operate Ultra-Large Scale systems.
    • Questions for your Learning Portfolio
      • There is a lot to think about this week! In addition to reflecting on what most interested you this week, I would like you to consider 'What it is to be an Engineer?' Have you ever thought about the responsibilities of an engineer and the impact they have on society? Can you give an example of when you questioned, from an ethical perspective, something you were doing as part of a larger team?

    • Mid Semester Break (Monday, 9Apr)

    This is a special session scheduled during the mid-semester break to take advantage of a visit to the ANU by experts from The High Integrity Systems Engineering group at The University of York in the UK.

    System and Software Safety

    Many of the most complex systems that we build, such as nuclear power plants, aircraft flight control systems or railway signalling systems are also safety critical - that is, systems whose failure could cause or contribute to human deaths or injuries.

    It has been commented that "safety is like justice - it not only needs to be done, it needs to be seen to be done".

    In designing safety critical systems, therefore, we face the challenges of any complex systems engineering project - but also the added dimensions of ensuring that we can meet the double goals of achieving and demonstrating acceptable levels of safety.

    There are some very significant issues to consider.

    The first is that there is no such thing as absolute safety. Simply defining what level of safety will be acceptable fo a given project can be extremely problematic, requiring careful negotiation of a range of misunserstandings, biases and prejudices about the technologies involved.

    Secondly, providing evidence of achievement can be exceedingly difficult. Many projects involve novel technologies and high levels of bespoke development. Even where familiar components and technologies are used, it can be almost impossible to obtain statistically-significant data to substantiate some of the ultra-high reliability claims that need to be made.

    Finally, we need somehow to put together a "safety case" - a document which justifies our claims of acceptable safety. Writing the safety case for even a simple safety critical system can involve many inter-related arguments about its design, testing, operation, maintenance etc.. For a large, complex system, building the safety case is a formidable challenge in its own right.

    This panel will consider broad issues around safety critical systems, but with a particular emphasis on understanding what "acceptable safety" means, how understanding of safety requirements shapes system development, and how we can develop and present arguments of acceptable safety.

    Second Teaching Period

  • Week 8 (Monday, 22 Apr)

    Model-Based Systems Engineering and Simulation

    "In many respects, the future of systems engineering can be said to be 'model-based'. A key driver will be the continued evolution of complex, intelligent, global systems that exceed the ability of the humans who design them to comprehend and control all aspects of the systems they are creating. The role of modeling will mature to respond to this need."

    INCOSE (2007). Systems Engineering Vision 2020

    The aim this week, is to introduce students to Model Based Systems Engineering (MBSE)

  • Week 9 (Monday, 29 Apr)

    Human Error in Complex Systems

    One of the by-products of conducting normal human operations in complex systems is error. Colloquially, error has been acknowledged as an inherent part of the human condition since Cicero (106-43BC) declared ‘to err is human’. It was not until the Second World War, when accidents occurred on a large enough scale to impact on performance, however, that error became linked to safety. With the introduction of computer-based information technology in the 1960s, systems became larger, increasingly centralised and more complex. As human ability to manage these systems started to become a limitation, accidents became a more common occurrence. Interdependency of system elements and fast system response may cause a seemingly innocuous error to develop into a catastrophic accident before a solution can be found. Well known examples include nuclear accidents at Three Mille Island, USA (1979) and Chernobyl, USSR (1986), and the space shuttle Challenger (1986) and Columbia (2003) accidents.

    Despite a large body of literature on error modelling and categorisation, little progress has been made on elimination of errors. Research has found that errors can be statistically predicted, but not with sufficient precision for prevention. The best we can do is to explore ways to minimise or mitigate the undesirable consequences of error. Current research efforts concentrate on engineering and design, psychology and human factors, or a combination of both.

    Through discussion of accidents in aviation and health care, the presentation will explore how the ways that humans behave, both as individuals and in groups, can contribute to error. Some of the methods currently used by industry to prevent human error will also be introduced, with examples from aviation and health care.

  • Week 10 (Monday, 6 May)

    System Dynamics

    System Dynamics is an approach to understanding the behaviour of complex systems over time. It deals with internal feedback loops and time delays that affect the behaviour of the entire system. What makes using system dynamics different from other approaches to studying complex systems is the use of feedback loops and stocks and flows. These elements help describe how even seemingly simple systems display baffling nonlinearity. (Wikipedia)

  • Week 11 (Monday, 13 May)

    Sustainability

    Our first speaker, Lorrae van Kerkhoff, will introduce us to how qualitative and integrative research methods can help us make decisions regarding sustainable decvelopment.

    Our second speaker, Tom Worthington, will give us a quick introduction to Green ICT.

  • Week 12 (Monday, 20 May)

    The Big Picture

    This week, we will run an extended Q&A with a diverse panel of experts. The aim is to sit back from what we have covered during the course and attempt to put it all together within the broader context of society and the environment.

  • Week 13 (Monday, 27 May)

    'The Unwritten Laws of Engineering' and Examination Preparation

    • Panelists
      • Dr. Shayne Flint
      • Mr. Walter Newland
    • Sample examination paper
      • Sample examination paper
    • Resources
      • The Unwritten Laws of Engineering, by W. J. King was first published in 1944 as three articles in Mechanical Engineering magazine
        • Part 1 - What the beginner needs to learn at once
        • Part 2 - Relating chiefly to engineering managers
        • Part 3 - Professional and personal considerations
        • NOTE: The above pages are no longer available - I am looking for alternatives

    • Updated:  07 May 2013 / Responsible Officer:   JavaScript must be enabled to display this email address. / Page Contact:   JavaScript must be enabled to display this email address.