An innovative introductory course to systems engineering teaching.pptx

An innova(ve introductory course to systems engineering: Teaching a problem solving

approach

1 Developed under a grant from The Leverhulme Trust 4 April 2013

RüR ü NSSSE 2007 (2007 NaBonal Symposium on System Science and Engineering in Taiwan, 21-‐22 June).

Today’s Topics

•  The stakeholders •  The stakeholder needs •  The design of the course •  The Problem Based Learning (PBL) exercises

•  The knowledge units •  Assessment and grades •  Summary •  QuesBons and comments

4 April 2013 2 Developed under a grant from The Leverhulme Trust


The stakeholders

•  Academia •  Students •  Industry •  Government •  Others

4 April 2013 Developed under a grant from The Leverhulme Trust 3


Academia

•  A marketable course •  A teachable course – using both full-‐Bme and part Bme instructors.

•  Contain components that can easily be incorporated in exisBng engineering and informaBon technology courses.



Students •  Enhanced career opportuniBes. •  Study workload that is appropriate to the lifestyle of a

full-‐(me employee with a family. •  An understanding of

–  what systems engineering is all about –  how to do systems engineering –  why every system engineer describes it differently. –  how what is being learnt in the class maps into their employer’s processes

•  A course experienced in a manner that makes learning effecBve. –  through the use of modern concepts in educaBon and cogniBve psychology

•  Affordable text books. 4 April 2013 Developed under a grant from The Leverhulme Trust 5


Industry and Government •  To be near the top of the value chain in the new global

economy. •  A pool of skilled personnel for the acquisiBon and

maintenance of the systems that underpin 21st century civilizaBon.

•  Competent, skilled and knowledgeable systems engineers –  capable of effecBvely working on various types of complex mulB-‐

disciplinary integrated systems –  in different applicaBon domains, –  in different porBons of the system lifecycle, –  in teams, alone, and –  with cognizant personnel in applicaBon and tool domains.



More Industry and Government •  Coursework is not to interfere with employment.

–  Flexible delivery modes to allow students to take the course as and when they can from whatever locaBon they happen to be in.

•  Knowledge, skills and competencies, that are useful immediately, and in the short and long terms.

•  Ability to communicate systems engineering principles to others. •  In the acquisiBon porBon of the system lifecycle,

–  facilitate the effecBve acquisiBon of systems that meet the customer’s needs •  at the Bme the system is specified, •  is actually delivered and •  during the full length of its operaBonal life.


Steps for CriBcal Thinking











Topics

•  The stakeholders •  The stakeholder needs •  The design of the course •  The PBL exercises •  The knowledge units •  Assessment and grades •  Summary •  QuesBons and comments


Integrated Mul(disciplinary Engineering for the 21st

Century

Not just your average systems engineering course



AssumpBons •  A single course cannot meet all the needs of the industrial and government stakeholders.

•  This class is not one in which the students do in-‐depth systems engineering

•  This is an introductory “breadth” class which examines systems engineering from various perspecBves (Kasser & Palmer 2005). –  The assumpBon is that students will conBnue their studies and take

“depth” classes in the requirements, test and evaluaBon, etc. in which they will apply systems engineering to tradiBonal technical systems in the appropriate phases of the lifecycle.

•  Each Knowledge Unit is a “breadth” unit –  references will be provided to the students for in depth study during the

assignment and aeer the course is completed. 4 April 2013 Developed under a grant from The Leverhulme Trust 15


More AssumpBons

•  The knowledge for this course comes from –  the lectures, the readings and the PBL exercises.

•  Students are expected to 1.  have at least a rudimentary knowledge of

systems engineering and project management. 2.  put in addiBonal out of class hours on their

studies. 3.  review the readings before doing the in-‐class

exercises. •  In block mode classes, Bme should be given for the students to scan the readings as part of the exercises.



Outcomes •  Improved cri(cal thinking skills. •  Understand the nature of mulBdisciplinary and interdisciplinary

engineering. •  Understand the reasons for the different definiBons of the term

“system”, and the various viewpoints on systems engineering. •  Understand the need for systems engineers with different

competencies, skills and knowledge in different parts of the system life cycle.

•  Be able to idenBfy the various types of problems faced by systems engineers in different phases of the system lifecycle.

•  Be able to idenBfy an appropriate tool or methodology to solve the problem.

•  Understand that there isn’t always a single “right” soluBon to a problem.

•  Be beger than average systems engineers for their level of experience (hopefully).



Delivery Modes

•  TradiBonal 13-‐week semester classroom •  Online asynchronous 13-‐week semester – allowing for some synchronous acBviBes if desired

•  Block mode lasBng one week – with post-‐class Bme for compleBng assignments.



Course Components 1.  A set of PowerPoint slides for a lecture. 2.  The accompanying instructor’s notes for what knowledge

to highlight during the lecture. 3.  Exercises

–  accompanied by suggesBons of •  what to do, •  what to expect the students to produce and •  how to assess the results.

4.  Instructor’s summaries of the readings –  to use when discussing the exercises with the students during

the classroom exercises. 5.  Chapters in a text book that supplement the lecture.

–  However, since there is no single textbook that fits this class, a set of readings, listed in each knowledge unit will be provided to the students unBl the book is wrigen.



Design Goals for Components 1.  The components should be designed to ensure the students

need to use and hence develop cri(cal thinking skills –  moving up the five steps published by (Wolcog and Gray 2003).

2.  Each knowledge unit should be split into three one-‐hour sessions with a short break between them.

3.  The lecture component should be no more than 45 minutes, –  preferably in two 15 minute sessions with the remaining 15 minutes

used in a facilitated discussion.

4.  The lectures should supplement the readings rather than contain the same content as the readings.

5.  When possible students should be asked to deliver the lecture components in units 6 to 11 for a porBon of their grade.



More Design Goals for Components 6.  The remaining two hours of the session should be

devoted to PBL in a team environment. 7.  The team exercises should be set within a single

context. –  This will minimize the Bme the students spend becoming familiar with

the context before actually performing the exercise.

8.  Each team should work on the same project independent of the others. –  This is to allow comparisons of approaches to demonstrate that there

need not be one “right” soluBon.

9.  The course notes should provide the instructor with subtle ways of guiding the teams along different paths but not misleading them.



Even More Design Goals for

Components 10.  Ideally teams should be composed of at least one male,

one female, one experienced and one novice. –  In an open class, students from different organizaBons and

naBonal cultures should be mixed into teams. –  One person may meet more than one of the criteria.

11. Students should be given the opportunity to choose –  who they would like to team with, and –  who they would not like to team with, and

12. Each team exercise should terminate with a presentaBon. –  Aeer the students have presented their work, the

similariBes and differences of the student teams’ presentaBons should be discussed.



Topics




Purpose •  To pracBce criBcal thinking, systems engineering, and problem

solving •  To understand the scope of mulBdisciplinary and interdisciplinary

engineering •  To enable the students to grow intellectually and deal with

ambiguity and complexity (Perry 1981) •  To learn about systems engineering by doing systems engineering •  To understand the need for the various competencies, skills and

knowledge and develop them. –  These skills and knowledge needed by systems engineers over the

system life cycle can be divided into •  Those needed in several if not all phases of the system life cycle. •  Those needed in specific phases of the system life cycle. •  Knowledge in the domain in which the system being developed/maintained/upgraded exists or will exist.



Context – Federated Aerospace •  A major conglomeraBon with systems engineering experBse in several commercial and defence domains.

•  Has five current projects. •  Has just been awarded a major mulB-‐billion pound systems development contract for Project Sukumu. –  must raid its current projects for the core personnel as well as hiring new people in order to meet the schedule of Project Sukumu.

–  each current project is going to lose people, •  much to the chagrin of the team leaders & the personnel lee behind.

•  Needs to hire replacements for the personnel being taken off the current projects.



Federated Aerospace’s Current Projects

Project Phase in the Lifecycle

Applica(on Domain

Nemesis Needs Ship acquisiBon

Radiator Requirements Aerospace Dataweight Design Database Terminal Test & EvaluaBon

(T&E) InformaBon Technology

Orrible O&M (In-‐service) TransportaBon 4 April 2013 Developed under a grant from The Leverhulme Trust 26


Project Sukumu Exercise •  Purpose of the exercise is for each team to – develop examples of systems engineering process-‐products (documents) •  from a problem solving perspec(ve

– develop an understanding of the links between them – begin to understand the consequences of poor •  documentaBon in earlier phases of the SLC. •  management (ineffecBve or wrong).

•  Designed so that Project Sukumu could be classified as more than one type (Shenhar and Bonen 1997).



Project Sukumu AcBviBes •  The students will prepare a high level Concept of

Opera(ons, Requirements Summary, Systems Engineering Management Plan and Test and Evalua(on Plan as a PowerPoint presentaBon to be made in Unit 13. –  As secBons of later documents are developed, the students will find that the earlier documents are incomplete and will need updaBng.

•  The team will first iden(fy the type of project as discussed in unit 2 as classified by (Shenhar and Bonen 1997).

•  The focus will be on the nature of the problems to be faced in each phase of the lifecycle and the approaches to be used to overcome those problems.

•  The students will be requested to reflect on this process at the end of their presenta(ons in unit 13 in order to increase their grade.



Staffing Exercise •  Purpose -‐ To allow the students to develop an understanding of the

competencies, knowledge and skills needed in different types of projects in different phases of the system life cycle. –  The students will have to understand competencies, skills and knowledge, as well

as the phase in the lifecycle in order to map the competencies to the needs for staffing a project.

•  The students will be shown how to use a systems engineering approach to –  developing the requirements (what is being done to determine and solve problems

(use cases), –  idenBfy the competencies needed to develop a job descripBon (requirements for

personnel), –  perform a gap analysis between the exisBng project team skills and select from a

set of resumes to fill the gap in an opBmal manner (design and integraBon). •  The comments on the presentaBon of their work by the instructor and other

students will fill the test and evaluaBon funcBon. •  By having the students develop a non-‐technical system the students will be

exposed to the concept that systems engineering applies to all sorts of systems.



Staffing Exercise AcBvity •  Each team will be associated with one of Federated Aerospace’s

current projects. •  For units 6 to 11 inclusive, each student team will be given the

resumes of the remaining project personnel and asked to produce the job descripBons for addiBonal staff members to round off the project teams’ skills for the lifecycle phase associated with the unit. –  The students will also have to take into consideraBon constraints such

as the salary budget, so they cannot adverBse a large number of posiBons.

–  The students will present what they would be looking for in a resume at the end of the unit and defend their choices.

•  As a variaBon, in some units the student teams will be given a set of resumes from applicants and asked to jusBfy to which ones they would recommend that offers of employment be made.

•  As by-‐product, they should also learn how to recognize and hence write a good resume.



Topics




Knowledge Units •  Units 1 to 5 –  provide the contextual background to mulBdisciplinary and interdisciplinary engineering, systems engineers and systems engineering.

•  Units 6 to 11 –  provide the knowledge about what systems engineers do in the various phases of the systems life cycle and what problems they face. •  Using the FRAT cycle (Mar 1994).

•  Unit 12 summarises modelling, simulaBon and other tools and techniques used in the system lifecycle.

•  Unit 13 wraps up the course.



Drae Unit Titles 1.  What are mulBdisciplinary engineering, interdisciplinary engineering and

systems engineering (SE)? 2.  Why projects fail 3.  An introducBon to lifecycles 4.  A framework for systems engineering 5.  The competencies of a systems engineer 6.  SE in the needs definiBon phases of the system lifecycle (SLC) 7.  SE in the requirements phases of the SLC 8.  SE in the design phases of the SLC 9.  SE in the integraBon phases of the SLC 10.  SE in the test and evaluaBon phases of the SLC 11.  SE in the operaBons & maintenance (in-‐service) phases of the SLC 12.  Modelling, simulaBon and other methodologies, tools and techniques for SE 13.  Student presentaBons and wrap up



Unit 1 Purpose To:

1.   provide an answer the ques(on in the (tle of the unit, 2.   iden(fy the existence of confusion amongst systems engineers

as to the nature of systems engineering 3.   understand the nature of the differences between systems

engineering and project management. Lecture 1.  MulBdisciplinary and interdisciplinary engineering; a brief

history of systems engineering and project management. 2.  Discusses the many different definiBons of the word “system”,

the various viewpoints on systems engineering and presents a hypothesis for the reason why there are so many definiBons.

Exercise The students compare the definiBons of systems engineering and group them to determine common denominators and determine support or refutaBon of the hypothesis.



Unit 2 Purpose To provide the students with an understanding of

the need to make use of lessons learned from past projects.

Lecture Introduce the context for the class team exercises in the course; discusses a number of lessons learned from high-‐tech project failures and successes; mulBdisciplinary and interdisciplinary engineering.

Exercise IdenBfy reasons why things go wrong if the causes are known and published.



Unit 3 Purpose To provide the students with the background for

the ac(vi(es performed by systems engineers in various stages of system development. To explain the difference between systems,

products, processes and lifecycles. Lecture Introduces the systems development lifecycle,

project life cycles, waterfall, spiral, DERA and Cataract models of the lifecycle, systems engineering standards, architecture frameworks and the nature of changes during the lifecycle.

Exercise Compare the different lifecycles and recommend and defend the choice of an opBmal life cycle for Project Sukumu.



Unit 4 Purpose To provide a framework for systems engineering

which provides an understanding of why there are many defini(ons of, and viewpoints on systems engineering.

Lecture Presents the Hitchins-‐Kasser-‐Massie Framework (HKMF), maps the lifecycles discussed in Unit 3 into the HKMF.

Exercise The students determine the nature of the different types of problems faced by systems engineers in the various phases of Layer 2 of the HKMF.



Unit 5 Purpose To iden(fy the quali(es, knowledge and

experience needed by junior, intermediate and advanced systems engineers in various phases of the system lifecycle.

Lecture Discusses the role of the systems engineer in projects, the skills needed to perform those roles, and systems thinking.

Exercise The students will map the skills, knowledge and experience requirements from the lecture and readings components, and external sources into Layer 2 and Layer 3 areas of the HKMF.



Units 6-‐11 Purpose To iden(fy the quali(es, knowledge and

experience needed by junior, intermediate and advanced systems engineers in various phases of the system lifecycle.

Lecture Discusses the role of the systems engineer in projects, the nature of the problems being faced, the skills needed to perform those roles, and systems thinking.

Exercise Staffing exercise Project Sukumu exercise



Unit 12

•  Modelling, simulaBon and other methodologies, tools and techniques for systems engineering



Unit 13

•  Project Sukumu student presentaBons •  Wrapup



42

HKM Framework VerBcal Dimension (Hitchins, 2000)

•  Layer 5 -‐ Socioeconomic, the stuff of regulaBon and government control

•  Layer 4 -‐ Industrial Systems Engineering or engineering of complete supply chains/circles

•  Layer 3 -‐ Business Systems Engineering •  Layer 2-‐ Project or System Layer •  Layer 1-‐ Product Layer


43

HKM Framework Horizontal Dimension (Kasser and Massie, 2001)

A.  IdenBfying the need B.  Requirements analysis C.  Design of the system D.  ConstrucBon of the system E.  TesBng of the system components F.  IntegraBon and tesBng of the system G.  OperaBons, maintenance and upgrading the

system H.  Disposal of the system


44

HKM Framework Problem solving/risk miBgaBon

Shenhar and Bonen, 1997 •  Three levels of system scope

–  Hitchins’ lower three layers

•  Four levels of technological uncertainty (risk) – Type a — Low-‐Technology Projects. – Type b — Medium-‐Technology Projects. – Type c — High-‐Technology Projects. – Type d — Super-‐High-‐Technology Projects

45

The HKM Framework


Topics




ObjecBves in assessment and grading •  Provide a measure of criBcal thinking skills*, deep learning

(modified Biggs 1999) and systems engineering knowledge.


* From Wolcog and Gray 2003

Step Descrip(on Grade (Oz)

Grade (US)

0. Confused fact-‐finder E P2

1. Biased jumper D P1

2. Perpetual analyser C C

3. PragmaBc Performer B D

4. Strategic re-‐visioner A HD


Summary

•  The stakeholders •  The stakeholder needs •  The design of the course •  The PBL exercises •  The knowledge units •  Assessment and grades


hgp://au.geociBes.com/g3zcz/

QuesBons and comments

49

Education

An innovative introductory course to systems engineering teaching.pptx