systems engineering newsletter - ppi · 2017-11-26 · systems engineering newsletter brought to...
TRANSCRIPT
PPA-006764-1 1 of 39
SYSTEMS ENGINEERING NEWSLETTER
brought to you by
Project Performance International (PPI)
SyEN 59 – November 20, 2017
SyEN is an independent free newsletter containing informative reading for the technical project
professional, with scores of news and other items summarizing developments in the field, including
related industry, month by month. This newsletter and a newsletter archive are also available at
www.ppi-int.com.
Systems engineering can be thought of as the problem-independent, solution technology-
independent, life-cycle-oriented principles and methods, based on systems thinking, for defining,
performing, and controlling the engineering effort within a technical project. The approach aims to
maximize the benefit delivered to the enterprise, as influenced by the needs and values of the
applicable stakeholders.
If you are presently receiving this newsletter from an associate, you may wish to receive the
newsletter directly in future by signing up for this free service of PPI, using the form at www.ppi-
int.com. If you do not wish to receive future Systems Engineering Newsletters, please unsubscribe
by clicking on the link at the bottom of this email.
We hope that you find this newsletter to be informative and useful. Please tell us what you think.
Email us at [email protected].
The views expressed in externally authored articles are those of the author(s), and not necessarily those
of PPI or its professional staff.
PPA-006764-1 2 of 39
IN THIS EDITION Quotations to Open On
Read More…
Feature Article
• Error Sources in Airborne Systems, by Walter Delashmit
Read More…
Article
• Managing Risk During Reliability Demonstration Testing for DoD Acquisition Programs, by Grant Schmeider
• Integrating Program Management and Systems Engineering, by Dr. Ralph Young
Read More…
Systems Engineering News
• INCOSE International Symposium 2018 – Washington D.C.
• Systems Engineers Day – November 24, 2017
• What do Systems Engineers Need to Know Concerning Cybersecurity?
Read More…
Featured Organization
• Defense Science and Technology Group
Read More…
Conferences and Meetings
Read More…
PPA-006764-1 3 of 39
Some Systems Engineering-Relevant Websites
Read More…
Systems Engineering Publications
• Collaboration Across Linked Disciplines: Skills and Roles for Integrating Systems Engineering
and Program Management
• Process Analyzer Systems Project Engineering and Management
• The Industries of the Future
• The Certified Quality Engineer Handbook
• Configuration Management Best Practices: Practical Methods that Work in the Real World
Read More…
Systems Engineering Tools News
• Cradle
Read More…
Education and Academia
• Engineering Education Needs a 'Major Shake-up'
Read More…
Standards and Guides
• ASQ/ANSI/ISO/TR 9002:2016: Quality management systems — Guidelines for the application of
ISO 9001:2015
• The ASQ Pocket Guide to Root Cause Analysis
Read More…
A Definition to Close On
Read More…
PPA-006764-1 4 of 39
PPI and CTI News
Read More…
Upcoming PPI and CTI Participation in Professional Conferences
Read More…
PPI and CTI Events
Read More…
PPA-006764-1 5 of 39
QUOTATIONS TO OPEN ON
“Values are like fingerprints. Nobody’s are the same, but you leave ‘em all over everything you
do.”
Elvis Presley
“Character is formed, not by laws, commands, and decrees, but by quiet influence, unconscious
suggestion, and personal guidance.”
Marion L. Burton
“The only significance of the word spiral in the spiral model is that a spiral is a way of fitting a
long timeline onto a small screen. But it is a great approach in the presence of significant risk.”
Robert John Halligan
PPA-006764-1 6 of 39
FEATURE ARTICLE
Error Sources in Airborne Systems by
Walter Delashmit, Ph. D.
Retired Defense, Space, and Education Professional
Abstract
Airborne systems are used extensively in military weapons and are coming into increased use in
commercial systems. Military weapons include cruise missiles and other precision targeting systems.
Commercial systems are starting to include package delivery which will eventually evolve into fast food
and grocery/department store delivery as well as medicine delivery for the elderly. All of these systems
require precise targeting to ensure that the package goes to the correct location. This requires an
extensive analysis of system parameters via mathematical or simulation or a combination of both so that
the system accuracy can be verified and improved as necessary.
Systematic Error Sources
A general operational version of these systems usually includes comparing or correlating a sensed “live”
signal with a pre-stored map signal (“reference” signal). These signals often are obtained by different
sensors. The “live” signal may be a radar signal or photographic signal (signature) and the “reference”
signature may be from a map, drawing or photograph.
Error sources include [1-4] a signal plus random noise for both the “live” and “reference” signals with
these being different. The most detailed mathematical analysis with simulation verification was
presented in [1]. The platform that collects the “live” signature will have errors due to tilt, altitude,
rotation, scale factor, timing, and random mapping errors. These errors will be present in operational
PPA-006764-1 7 of 39
systems as a result of imperfections in the inertial reference, altitude accuracy, reference misalignment,
radar timing, reference object location, etc.
Analyses of these systems will aid in predicting potential system performance to evaluate feasibility of a
proposed system for defined mission goals. In addition, the most critical error sources will be identified
so that provisions can be made to control the magnitudes of the errors to increase the potential
performance of the system.
The accuracy evaluation is usually treated from a statistical point of view with the scene, noise, and
various errors treated as members of ensembles. It must also be determined in this analysis whether the
systematic errors enter into the system accuracy as additive or multiplicative factors. The accuracy
formulas obtained predict accuracy, parameter variation effects, and error sensitivities, and can be
optimized to improve system performance [1-4]. For a particular scenario the results obtained cannot be
expected to agree with the exact real world experiments but allow a prediction of average accuracy to be
obtained.
True accuracy prediction will depend on the defined system parameters with specified signal to noise
ratios (SNRs) or an evaluation over a range of SNRs. It is also dependent on system altitude and sensor
resolution which may be different in the X and Y dimensions or range and azimuth dimensions [1-4].
To accurately model the system, equations must be derived relating actual system coordinates to
mapped coordinates with the systematic errors of scale factor, random scale factor, altitude, rotation,
timing, and tilt considered.
A. Scale Factor Error
For the scale factor error, the distortion effect can be determined by inspection since the mapped
coordinates Xm and Ym are equal to the actual coordinates plus some fractional part (scale
factor).
B. Random Mapping Error
Random mapping error can be considered as a shift in the mapped coordinates by a specified
amount as a result of reference location accuracy.
C. Altitude Error
Altitude error is dependent on the altitude and scan radius on the ground and scan angle θ.
D. Rotation Error
A rotation error for the coordinates can be expressed by considering a misalignment in scan
angle, θ.
E. Timing Error
PPA-006764-1 8 of 39
A timing error will produce an error in the slant range and a corresponding error in the scan
radius on the ground.
F. Tilt Error
For a tilt about the X axis with fixed slant range timing, a shift in the antenna beam location will be
obtained
Conclusions
Error sources for airborne sensor systems have been presented in general terms. More details can be
provided given defined system and sensor parameters [1-4]. These techniques are applicable to both
military and future commercial systems.
References
[1] W. H. Delashmit and R. F. Webber, “Accuracy and Error Sensitivities for Circular Scan Correlator
Systems”, IEEE Transaction on Aerospace and Electronic Systems, Vol. AES-13, No. 1, January 1977
[2] M. W. Johnson, “Analytical development and test results of acquisition probability for terrain
correlation devices used in navigation systems”, AIAA 10th Aerospace Sciences Meeting, San Diego,
CA, 17-19 January 1972, Paper No. 72-122
[3} D. A. Fogle and R. H. Goebel, “The Two-dimensional Accuracy of a One-dimensional Correlator,”
Southeastcon 76 Proceedings.
[4] I. N. Durboraw III and A. N. Beavers Jr., “Deterministic Approach for Evaluation of Correlation
Guidance Signature Quality,” AIAA Journal of Spacecraft, Vol. 12, September 1975.
Biography of Walter H. Delashmit
Walter H. Delashmit was born in Memphis, TN in 1944. He received the BSEE from Christian Brothers
University, Memphis, TN in 1966, the MSEE with a minor in mathematics from the University of
Tennessee in 1968, and the Ph.D. EE from the University of Texas at Arlington in 2003.
He retired from Lockheed Martin Missiles and Fire Control (1982-2006) in 2006 where he developed
”smart missiles” technology. He currently does some independent consulting. He previously worked at
the Penn State Applied Research Laboratory (1976-1982) on advanced torpedo systems, Martin
Marietta Aerospace (1972-1976) working on correlation terminal homing missile systems, and TRW
Systems (1969-1972) where he worked on the Apollo and Skylab Programs.
He has published many technical papers in professional journals and has received many honors and
awards. Awards include a copy of the Presidential Medal of Freedom from NASA for work on Apollo 13
(1970), the Lockheed Martin Missiles and Fire Control President’s Award (2000) for work on developing
improved software processes, and an award from the US Army for work on the Strategic Defense
PPA-006764-1 9 of 39
Initiative (SDI) Program. The most recent awards (2017) include the Marquis Who’s Who Alfred Norquist
Lifetime Achievement Award and the Worldwide Association of Notable Alumni VIP.
He is a Life Senior Member of the IEEE, a member of the Association of Old Crows, a member of Tau
Beta Pi engineering honorary society and a member of Eta Kappa Nu electrical engineering honorary
society.
His research interests are in automatic target recognition, neural networks, image and signal processing,
and process improvement.
ARTICLE
Managing Risk During Reliability Demonstration Testing for DoD Acquisition Programs
by
Grant Schmieder
Modern Technology Solutions, Inc. (MTSi)
Copyright © 2017 by Grant Schmieder. All rights reserved.
Introduction
The purpose of this article is to address basic issues that must be understood in order to put the
“reliability” evaluation resulting from a given test program into proper perspective. Commercial products
tend to be developed quickly and in large volume which enables efficient evaluation of the product’s
expected in-use reliability. This expected reliability is (or should be—but that’s another story) the basis
for warranty related analyses including expected repair frequency, repair costs, and all related supply
chain expected needs. Overestimation of the product’s actual reliability can lead to significant
unexpected costs that pose a high risk to the producer—the Samsung Galaxy 7 battery failures and
resulting removal from the market is a recent example of this. The combination of potential high financial
risk and the relative availability and affordability of test samples allows many commercial product
developers the opportunity to use classic reliability test techniques to thoroughly evaluate the product
and produce high-confidence estimates of what field reliability will be. The product individual item cost is
not normally a driving factor in these commercial scenarios since the cost of testing a small number of
items out of a large production run has a negligible effect on average unit cost when spread across the
entire run.
Traditional Department of Defense (DOD) Major Defense Acquisition Programs (MDAPs) do not have
any of these luxuries. MDAPs tend to have small production quantities, high unit costs, relatively long
development cycles, and, usually, very high reliability requirements are necessary to support mission
PPA-006764-1 10 of 39
effectiveness. This is the nature of building extremely complex, state of the art airplanes, ships, tanks, or
other systems. Thus, DOD development programs face significant obstacles when trying to evaluate
what the MDAP system’s in-use reliability will be. Traditionally, reliability is evaluated throughout
Developmental Test (DT) and Operational Test (OT) events with the system’s “suitability” assessed
during OT relying heavily on the reliability observed during testing.
Reliability Metrics and Normal DOD Test Approach
One of the basic issues encountered while trying to evaluate the reliability of an MDAP system is the
understanding that “Operational Testing” is focused on mission performance. This is actually a short
term focus for a reusable system (again, think airplane, ship, tank, etc.) that may have a 30 year or
longer service life but an average mission duration of hours or days. Since many performance metrics
are relatively easy to demonstrate—how high a plane can fly, how fast a ship can sail, how accurately a
tank can fire its main gun—test programs for most mission performance metrics are fairly easy to
construct and perform. In demonstrating reliability, though, things are not as clear. Repairable systems
with redundancy and fault tolerance can often perform the assigned mission in spite of failures occurring.
One of the major ramifications of this is that the potential failures which could be encountered during test
need to be identified, usually through standard Reliability Engineering practices, such as Failure Modes
and Effects Analysis (FMEA), and classified as critical (loss of mission) or non-critical (requires
maintenance but does not cause loss of mission) before testing begins. For defense acquisition
programs this classification is documented in the Failure Definition and Scoring Criteria (FDSC) for the
program.
There are two main complimentary reliability metrics: Mission Reliability (RM) and Logistics Reliability
(RL). To simplify the concepts involved, we will select Mean Time Between Critical Failure (MTBCF) to
represent the RM metric and Mean Time Between Failure (MTBF) as the RL metric for this article. Mission
reliability is defined as the probability that the system will successfully operate as designed throughout a
defined time period under specified conditions (i.e. “the mission”) and is often improved through the use
of redundancy and fault tolerance in system design. This approach allows for high RM even if the item
has relatively low RL. Having a high MTBCF value affords a greater probability of mission success while
also requiring, as we will discuss below, more test time to evaluate at a given confidence level. At the
same time, having a lower MTBF, which is defined as the probability that the system will operate as
defined without failure of any kind during a defined time period under stated conditions, while not
causing mission failures may drive system support costs in the field since logistics failures usually
require repair to restore the system to full functionality. It must be noted that there is a necessary cost-
benefit trade-off between test costs required to evaluate high reliability long-lived designs and the risk of
significantly higher sustainment costs than expected occurring due to failure modes being undiscovered
when using higher risk but lower cost test plans, but the methods for making this trade-off are beyond
the scope of this article.
PPA-006764-1 11 of 39
Flat Tire Example: A commercial product example for the MTBCF vs. MTBF issue is that if a car
gets a flat tire on a trip (its “mission”) then a short maintenance action, usually changing the tire
with a spare carried in the trunk at all times (i.e. there for redundancy), enables going on to
complete the trip.
While the trip might have been delayed, it was completed, so a mission success would be reported. But
the flat tire would be a logistics failure and full system capability (i.e. tolerance for another flat tire) will
only be restored when the flat tire is fixed and the spare tire is returned to its inactive redundant position
in the trunk. It is crucial to define the difference between a mission failure and a logistics failure when
evaluating the suitability of a system for use in the field.
Basics of Reliability Demonstration by Test
The following definitions from MIL-HDBK-108 (which regrettably was canceled during the heyday of
acquisition reform in the 1990’s) will be used throughout the remainder of this article:
• Ɵ (“Theta”) represents the true (and unknown) mean time to failure of the items under test
• Ɵ0 (“Theta Naught”) represents the minimum mean time to failure acceptable to the user
• Ɵ1 (“Theta One”) represents the point at which mean time to failures less than or equal to it are
considered unacceptable to the user
We will add a definition to facilitate discussion:
• ƟD (“Theta Design”) represents the design target for mean time to failure and acts as an estimate
of Ɵ during test design
One of the first things to understand about testing for reliability is that the result observed (usually total
test time/number of failures) is a random variable for each run of the test design. If you repeat the test
using the same design, the result of the second test will probably differ from the result of the first test,
and the third test would most likely differ from the first two, and so on. This is because the reliability test
itself is nothing more than a sampling from a population with unknown reliability Ɵ. If the test were either
sufficiently long or repeated frequently enough then the average of the test results will converge to the
true value of Ɵ. The level of testing required to fully evaluate reliability is usually impractical due to time,
cost, and sample availability issues and “undertesting” the system raises risks for operational
effectiveness through not uncovering important failure modes. A balancing is required when designing
the reliability test plan and statistical methods are used to trade-off design and test costs versus testing
risk.
Time Truncated Test Plan Example:
A test is designed for a given length, t, on a given number of test items, n, and is run with
replacement (failed test items are replaced immediately with spare items)
PPA-006764-1 12 of 39
The total test time, T, is
T = n * t
The test result is the total number of failures observed, r, and the point estimate of reliability, Ɵhat,
is
Ɵhat = Total Test Time / Total Number of Failures = T / r
The relationship between Ɵhat and the “true state of nature,” Ɵ, can be modeled under most DOD
Operational Test conditions. An assumption that must hold for reliability test approaches like these is
that the failures are exponentially distributed. If the design is stable, mature, and in the useful life phase
of the reliability bathtub curve, then the Non-Homogeneous Poisson Process resulting from multiple
competing failure modes justifies the assumption of a constant failure rate with exponentially distributed
interarrival times of failures. This allows the reliability practitioner to put confidence intervals around the
test point estimate to improve our understanding of the system’s observed reliability. The interval of
interest to a reliability demonstration is usually the lower one-sided confidence limit (LCL) which is given
by:
LCL = (2 * T)/χ2(α, 2r+2)
Where T is the total test time, α is the level of significance of the test (1 – confidence level), r is
the number of failures observed, and χ2 denotes the Chi-Squared distribution.
Electric Train Example: 5 electric trains are run for 600 hours with each failed train being
replaced immediately by a spare. At the end of the test, three failures had been observed and the
90% single sided LCL is desired.
The test results are:
T = n * t = 5 units * 600 hours/unit = 3000 hours
r = 3 failures
Ɵhat = T / r = 3000 hours / 3 failures = 1000 hours/failure
This gives a 90% one-sided lower confidence limit of:
LCL = (2 * 3000)/χ2(0.1, 6+2) = (2 * 3000)/13.362 = 449.03 hours with 90% confidence
What this test result actually indicates is if we repeat the exact same test then 90% of the time the true
value of Ɵ will be above the 90% one-sided LCL for Ɵhat. In practice, this is taken to mean that there is a
90% chance that the value of Ɵ is ≥ 449.03 hours based on the single test result even though this is not
technically correct. Just let it suffice to say that an OT event for these electric trains that produced 3
failures in 3000 total test hours would result in an assessment of Ɵ ≥ 449.03 hours at 90% confidence.
PPA-006764-1 13 of 39
Dealing with Risk in a Reliability Test Plan for Operational Testing
We are going to shift to looking at OT events evaluating RM. The applicable risk metrics are Producer’s
and Consumer’s risk. The Producer’s risk, β, is the probability of failing the test even though the
population MTBCF is ≥ Ɵ0 and the correct result would be passing the test. This is also called Type I
error in some testing scenarios. The Consumer’s risk, α, is the probability of passing the test even
though the population is MTBCF ≤ Ɵ1 and the correct result would be failing the test. This is also called
Type II error. Producer’s and Consumer’s risks result from the overlap of the sampling probability curves
for test results as shown in Figure 1.
Figure 1. Overlap of Continuous Probability Curves
Electric Train Operational Test Example: An Independent Operational Test and Evaluation
(IOT&E) event is scheduled for the electric trains. These are no longer toy trains but are instead
the first operationally representative prototypes from an MDAP to develop new trains. Because of
the cost and complexity of the system, only two test items are available for the IOT&E. The
specified requirement is a 95% chance of completing the standard mission duration of 36 hours.
The required value of Ɵ is desired.
We derive the Ɵ MTBCF requirement using:
Reliability at time t = R(t) = e-λt
Note that λ = failure rate = 1/MTBCF:
So, R(t) = e-t/MTBCF
Taking the natural log of both sides and re-arranging terms:
Ln R(t) = -t/MTBCF → MTBCF = - t / Ln R(t)
PPA-006764-1 14 of 39
Using the specifications (95% chance of completing a 36 hour mission) we can determine the
required MTBCF as:
MTBCF = - 36 / Ln (0.95) = - 36 / - 0.0513 = 702 hours
Now that we have our Ɵ (702 hours), it is necessary to design the required test. The first
consideration is what is the minimum number of test hours required to demonstrate an MTBCF of
702 hours? The minimum test time can be determined from the “failure-free testing” one-sided
lower limit at a significance level, α, of 0.1 (for a 90% one-sided LCL):
From “Reliability Statistics” by Robert A. Dovich, the equation for the failure free testing lower
limit is:
MTBF ≥ - n * T / ln α
This equation can be re-arranged to:
MTBF * ln α ≥ - n * T
Noting that n * T is actually the total test time, we can calculate the minimum total test time
required:
Minimum Total Test Time = - MTBCF * ln α = - 702 * ln 0.10 = 1616.4 hours
So, we should just put the two trains on test for 1616.4 total hours (or 808.2 hours each) and if there are
no failures we will have demonstrated the required MTBCF has been achieved, right? Unfortunately, it
isn’t this easy. The number of failures observed is a random variable based on the exponential
distribution used in the reliability equation above. We can use this knowledge to predict the number of
failures we expect to see in 1616.4 test hours if the population actually has a 702 hour MTBCF. A simple
initial way to view this is:
What is the probability of seeing 0 failures in 1616.4 test hours given an achieved 702 hour
MTBCF? We calculate that from the reliability equation:
R(t) = e-t/MTBCF = e-1616.4/702 = 0.100 or 10%
Which makes sense because we defined the test for 10% significance.
So, we could happily tell the random variable r that it will be zero and run our test for 1616.4 hours and 1
time in 10 it will oblige. The other 9 times it will take on a non-zero value and we will have “failed” our
test. This “failure-free” test plan has a 90% Producer’s Risk (since we calculated it based on having the
true state, Ɵ, be equal to the specified ƟD so the system should pass the test). In reality we will need to
take into account our acceptable levels of risk to design an adequate test.
Risk in testing is related to the length of the test (more testing usually means lower risk) and the value of
Ɵ compared to Ɵ1. The higher the ratio Ɵ/Ɵ1 the lower the test risk will be. This is shown in Figure 1 by
PPA-006764-1 15 of 39
the size of the areas where the Ɵ1 curve overlaps the Ɵ0 and ƟD curves. By designing the system to a
higher reliability than required (i.e. ƟD > Ɵ1) we reduce the test risk but we incur higher development
costs through implementation of reliability improvement techniques such as Highly Accelerated Life
Testing (HALT), other Physics of Failure (PoF) approaches, and, less desirably, potentially increase
system cost, complexity, size, and weight through incorporation of additional redundancy. Another way
of reducing test risk would be through increasing test time which will reduce the width of the curves (as
the results move closer to the true value of Ɵ) which decreases the overlap but increased testing
involves higher costs and will add significant time to the development schedule (if testing cannot be
accelerated through adding more test articles and/or running accelerated testing). It is usually impractical
to increase IOT&E testing to allow for lower risk reliability evaluation.
Electric Train Operational Test Example, Part 2: Returning to the train example, we will
assume that the maximum available test time for the IOT&E is 2000 hours. What is the minimum
value of ƟD we should set given Producer’s Risk = Consumer’s Risk = 0.20?
We start the analysis by revisiting the requirements:
Ɵ0 ≥ 702 hours to give 95% RM
T = 2000 hours
Next, we set the risk related requirements through discussion and agreement with stakeholders:
α = β = 0.20
Ɵ1 = 342 hours (equates to RM ≈ 90%)
We then use established equations for the maximum number of failures allowed during time
truncated testing to find the minimum value for ƟD:
ƟD ≥ 871 hours
Conclusion—Why Did We Look at this Example?
The takeaway here is that while the customer requirements could be met by a system with a 702 hour
MTBCF, the limitations (time, cost, schedule, test item availability, etc.) of the IOT&E event required
overdesigning the system MTBCF by 24% solely to reduce the risk of failing the test without adding
significant operational utility. Increasing the MTBCF from 702 hours to 871 hours only improves RM from
95% to 96% while most likely significantly increasing system complexity, cost, and weight. This is not
usually an effective design approach for DOD systems, since, for the most part, smaller, lighter, and
faster is desired. Testing and reliability demonstration should strive to avoid forcing overdesigning a
system simply to pass a test without tangible benefits to the customer. Understanding the meaning of
test results including what risks are present due to the test design is the most important factor in
evaluating reliability demonstrated during testing.
PPA-006764-1 16 of 39
Final Thoughts
There is another approach to demonstrating that reliability is “good enough” without determining what
the reliability “is” that can be very useful here. Sequential Testing, once a staple of DOD program
development, is a method that enables a quick decision as to whether the reliability is more likely Ɵ1
(fail) or Ɵ0 (fail to reject—i.e. “pass”). This involves running the test until a statistical decision can be
reached for either outcome. In cases where Ɵ is either much lower or much higher than Ɵ0 this approach
can save a significant amount of test time but it will not always provide a high confidence estimate of the
achieved reliability. Sequential Testing is the dominant approach in the commercial world due to its
efficiency and is now beginning to return to the test plans for MDAPs which should improve the
effectiveness of DT and OT in assessing reliability.
About the Author
Mr. Schmieder has 34 years of experience in Logistics and Reliability Engineering, working on multiple
Defense and Commercial device development and evaluation programs. Currently he is a Modern
Technologies Solutions Inc. (MTSi) Principal Engineer supporting a DOD program office. He has a
Masters in Systems and Industrial Engineering from the University of Arizona, is an ASQ Certified
Reliability Engineer and ASQ Certified Six Sigma Green Belt. In previous positions he has worked on
telecommunications equipment and medical device development programs and spent nine years
supporting OUSD(AT&L) Systems Engineering program oversight and policy development efforts. He
was the technical lead for the development of the RAM-C Rationale Report Manual for DOD. He
welcomes discussion and can best be reached by e-mail at [email protected].
List of Acronyms Used in This Article
Acronym Explanation
ASQ American Society for Quality
DACS Data and Analysis Center for Software
DOD Department of Defense
DT Development Test
FDSC Failure Definition and Scoring Criteria
FMEA Failure Modes and Effects Analysis
HALT Highly Accelerated Life Testing
IOT&E Independent Operational Test and Evaluation
LCL Lower Confidence Limit
PPA-006764-1 17 of 39
MDAP Major Defense Acquisition Program
MTBCF Mean Time Between Critical Failure
MTBF Mean Time Between Failure
OT Operational Test
OUSD(AT&L) Office of the Under Secretary of Defense (Acquisition, Technology, and Logistics)
PoF Physics of Failure
References
1. System Reliability Toolkit, 2005, Reliability Information Analysis Center
(http://acqnotes.com/acqnote/careerfields/reliability-information-analysis-center)
and Data and Analysis Center for Software (DACS)
(https://en.wikipedia.org/wiki/Data_%26_Analysis_Center_for_Software).
2. Dovich, Robert A. Reliability Statistics. Milwaukee, Wisconsin USA: American Society for Quality
(ASQ) Press, 1990. See https://www.amazon.com/Reliability-Statistics-H0601-Robert-
Dovich/dp/0873890868/ref=sr_1_3?s=books&ie=UTF8&qid=1507133294&sr=1-
3&keywords=Robert+A+Dovich.
3. Dovich, Robert A. Quality Engineering Statistics. Milwaukee, Wisconsin USA: American Society
for Quality (ASQ) Press, 1992.
4. MIL-HDBK-108, Sampling Procedures and Tables for Life and Reliability Testing, 29 April 1960.
5. Reliability, Availability, Maintainability, and Cost Rationale Report Manual, 2009, OUSD(AT&L).
6. American Society for Quality. The Certified Reliability Engineer Handbook, 3rd Ed. (e-book).
Milwaukee, Wisconsin USA: American Society for Quality (ASQ) Press, 2017 (see
https://asq.org/quality-press/display-item?item=E1535).
7. Burke, Sarah E. and Rachael T. Silvestrini. The Certified Quality Engineer Handbook (4th Ed.).
Milwaukee, Wisconsin USA: American Society for Quality (ASQ) Press, 2017 (see
https://asq.org/quality-press/display-item?item=H1518).
PPA-006764-1 18 of 39
ARTICLE
Integrating Program Management and Systems Engineering by
Dr. Ralph R. Young, Editor, SyEN
This month we provide a summary of Chapter 4 in Integrating Program Management and Systems
Engineering (“The Book”), a collaboration of the International Council on Systems Engineering
(INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program
Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT).
Chapter 4 of this new and profound book is titled “The Case for Integrating Program Management and
Technical Management”. This is a critical issue for all systems engineers because the current approach
of systems development and project/program management (PM) lacks integration of PM and systems
engineering and is not sustainable.
As we understand, program management and systems engineering are different. The challenge is one in
which the chief systems engineer is attempting to describe and define the optimal solution while at the
same time the program manager is attempting to determine the necessary work components, develop
the program implementation plan, and discern how to deliver benefits to stakeholders. Having one
person fill both roles does not scale well in the complex systems environment that exists today. A
starting point for improved integration of the two disciplines is a foundational understanding of both
disciplines and the standards that inform the practice of the disciplines. Tension between the two
disciplines has its roots in the specialized practices and standards that are highly role specific and often
have different measures of success. Whereas the project manager (PM) manages for benefits delivery,
the chief systems engineer (SE) is often concerned with optimizing the components. If these roles are
not working together closely, the result is often contention and conflict.
A significant difference that exists between project/program management and systems engineering is
the standards that are used by the two disciplines. PMI members developed The Standard for Program
Management, now in its third edition, as a consensus-based standard, detailing the common practices of
the profession, and building on internationally published practice and research. In 2007, PMI released
the Program Management Professional (PgMP) credential to certify mastery of the knowledge and
practice experience related to managing programs. PMI also offers the Project Management
Professional (PMP) certification.
Unlike engineers whose detailed technical training and credentialing requirements forge a strong shared
identity regardless of other differences, program managers may come into the profession from various
backgrounds and paths. While there is movement toward formal degree programs in program
PPA-006764-1 19 of 39
management, today it is still much more likely that the PM will have developed skills based primarily from
on-the-job experience.
The INCOSE United Kingdom (UK) chapter developed a Systems Engineering Competency Framework
(“Z6”)1 that describes the competencies that are required to conduct good systems engineering,
consistent with International Standards Organization (ISO) 15288, EIA 632, and the INCOSE Systems
Engineering Body of Knowledge and Systems Engineering Handbook. The Systems Engineering
Competency Framework was adopted by INCOSE and reflects the organization’s position on systems
engineering competencies. As we know, it takes a lot of education and training as well as years of
experience to become a solid systems engineer. Unlike the program manager role, systems engineers
share a common foundational knowledge associated with engineering and engineering management
principles. Some systems engineers may have extensive exposure to their discipline without
opportunities to develop broader management experience. This isolated professional development may
contribute to unproductive tension with program managers.
The examples of differing standards and different education and training suggests a danger that
representatives of the two disciplines may continually have a different view that sees possible solutions
through their respective lenses. Isolated mindsets have occurred in many technical programs, and the
result has been lack of cooperation and failure to achieve an integrated approach. Seeing different
approaches and solutions can lead to unproductive tension. Each discipline often focuses on the solution
from its own perspective without collaboration toward the optimal solution.
One of the dimensions that formed the research base for The Book was the level of unproductive tension
that existed between the two disciplines. Survey respondents rated the degree to which unproductive
tension between program managers and systems engineers existed in their organization. Among the
factors rated by respondents, three key factors stood out as sources of unproductive tension: lack of
integrated planning, authority not clearly defined, and conflicting practices for program management and
systems engineering.
Program managers and chief systems engineers each have unique but intertwined roles to play in
successful program outcomes. Viewed exclusively from their own professional identities, capabilities,
and methods, the need to work together may not be apparent. They each have their own discipline-
based measures of what problems have highest priority along with associated rewards. Sometimes, their
respective roles are not well-defined and may even be in conflict with one another. The opportunities and
rationales for them not working together closely are manifold, and the result can be unproductive
tension, or worse.
1 The Framework is available here. Note that the Framework describes the competencies of Systems Engineering rather than the competencies of an individual Systems Engineer.
PPA-006764-1 20 of 39
Integration of roles entails a mindset change for individual employees and changes to processes and
procedures for the organization. The latter may require a change to organizational culture, which comes
with its own set of issues.
The research provided several case studies of excellent integration and program success. The key to
success seems to be when the PM and the SE embrace the overall goal of improved technical program
performance and each practitioner’s ability to continue to that goal. Further, each must find ways to
apply specialized knowledge of their respective disciplines in a way that works to produce a sum greater
than the parts (empowered teams). This requires a vision beyond the task at hand and can prove to be
extremely difficult because it requires developing some new ways of looking at the challenges – a task
that forces new patterns of thinking.
As the case studies in The Book show, the benefits of integration far outweigh the effort required to
integrate the disciplines. The payoff can be large. But it is not necessary to move from minimal
integration to full integration in one step. Change begins with the first step and is sustained by
determining to press on with the next step even when the going gets rough.
Where have you seen successful integration of the disciplines of program management and systems
engineering in your organization? Have you noted examples of unproductive tension? What do you think
might be done at the project/program level and also for the organization to provide added integration
and, thus, higher probability of program success?
SYSTEMS ENGINEERING NEWS
INCOSE International Symposium (IS) 2018 - Washington DC, USA Delivering Systems in the Age of Globalization
Saturday, July 7 – Thursday, July 12, 2018
Grand Hyatt Washington1
000 H Street NW
Washington, DC 20001USA
Tel.+1 202 582 1234
PPA-006764-1 21 of 39
Call for submissions
The INCOSE International Symposium is the premier international forum for Systems Engineering.
Participants network, share ideas, knowledge and practices, and learn more about the most recent
innovations, trends, experiences and issues in Systems Engineering from world-class thought leaders.
Key Dates
Submission deadline 10th November 2017
Notification of acceptance and referee comments 16th February 2018
Final Manuscript 30th March 2018
More information
Systems Engineer Day – November 24th, 2017 With the world becoming more and more digitized every day, there is a group of people that has rather
suddenly become one of the most important groups of people in the world: systems engineers. Systems
engineers make enormous contributions to the world as we know it every single day, allowing us to live
the increasingly comfortable lives we are accustomed to, and neither our personal nor our professional
lives would be the same without them. Systems engineers work on numerous complex projects:
spacecraft design, computer chip design, robotics, software integration, and bridge building. The
computer you’re using right now to read this article would not exist if it weren’t for systems engineers,
nor would the plane you’re taking to go to your exotic holiday destination, and nor would the bridge you
need to cross to get to work every day. And let’s not forget the International Space Station, one of the
most impressive examples of what systems engineering can accomplish. Though systems engineering is
a very young profession, there is no disputing that it is one of the most important ones in today’s world.
The History of Systems Engineer Day
PPA-006764-1 22 of 39
The term systems engineering first appeared in Bell Telephone Laboratories in the 1940s. Today, 75
years later, systems engineering has been divided into many fields and sub-fields including cognitive
systems engineering, industrial engineering, mechatronic engineering, reliability engineering, security
engineering and software engineering, to name but a few.
Systems Engineer Day was created just recently by the folks at www.systemsengineerday.com as a way
of saying thank you to the men and women who sit in front of computers for hours every day to make our
lives better and easier.
How to Celebrate Systems Engineer Day
If you yourself are a systems engineer, today is your day, so make the most of it: maybe it’s high time
you took a day off and looked at a real landscape instead of the Windows desktop ones. Relax your
eyes, enjoy the fresh air, have a picnic! Or if you fancy a more social situation, why not get together with
your other systems engineer buddies and just have some beers, hang out and laugh at jokes only you
understand?
What Do Systems Engineers Need to Know About Cybersecurity? The applications of systems engineering are extensive. Information security can be regarded as a
specialty discipline, and cybersecurity an application of that specialty discipline. A recent summit
concerning cybersecurity raised a number of key issues that are relevant to the practice of systems
engineering. Foremost among them is that cybersecurity must be a priority for all of us.
The Washington Post (USA) sponsored its seventh annual Cybersecurity Summit (2017) on October 3rd,
2017. Government leaders, security experts, and security advocates gathered for a discussion of the top
issues. Speakers addressed hacks, cybercrime, cyberspying as well as the latest developments in
protecting consumer data and critical infrastructure. Speakers included Rob Joyce, White House
Cybersecurity Coordinator; General Michael Hayden (Ret.), Former Director, Central Intelligence Agency
and National Security Agency; Representative Will Hurd, Member, House Committee on Homeland
Security and House Permanent Select Committee on Intelligence; Michelle Richardson, Center for
Democracy and Technology’s Freedom, Security, and Technology Project; Richard Clark, Former White
House Advisor; Christopher Furlow, President, Ridge Global; Marcy Wheeler, National Security
Journalist; and Jeffrey Lush, U.S. Federal Chief Technology Officer, HP Enterprise (HPE).
Some of the interesting insights provided by the speakers included the following:
• It’s critical for all to operate in the international space. In particular, we should look to bilateral
agreements with individual countries.
• Cyber (security) has many communities and jurisdictions. The current strategy is to optimize what
we have.
PPA-006764-1 23 of 39
• The Vulnerabilities Equities Process (VEP) (https://thecyberwire.com/events/cycon2016/the-
vulnerabilities-equity-program-disputed-questions.html) is not well understood. A charter for the
VEP is being finalized that will include criteria and participants.
• We need to emphasize the people component of technology.
• Theft of data is “honourable espionage” – all countries do it.
• Social media is the main way we communicate these days.
• The sophistication of cyber efforts is different today in scale, style, and approval at the highest
level.
• We need to make encryption stronger.
• Companies must have a good cybersecurity risk profile. They must be willing to invest money.
Currently, companies are spending 3-5% on cyber; they need to spend 8-12%. From the National
perspective, there needs to be a penalty for making mistakes. Then, the business model will
ensure that needed investments are made.
• Executives in companies, legislators, and the general public need to get up-to-speed concerning
risk management of cybersecurity.
• Executives do not understand the value of the data they possess.
• There is a tendency in Government to underplay potentialities. We need to open views to the
broader society.
• Regarding the “Internet of Things (IOT), today there are an estimated five billion devices; the
projection is for 30 billion devices in 3-4 years. This vastly increases the number of devices being
rushed to the market that do not address cyber concerns.
• We are getting many of the basics wrong, including passwords, two-factor identification, the
number of data centers in existence, licensing of software, inventories of software on our
systems, privacy, international harmonization, and the need to build trust, for examples.
• Technology has outpaced our abilities at the policy level.
• Systemic changes need to be sponsored by companies and governments.
PPA-006764-1 24 of 39
FEATURED ORGANIZATION
Defence Science and Technology Group The Defence Science and Technology Group (abbreviated as DST Group or DST) is part of
the Australian Department of Defence dedicated to providing science and technology support for
Australia's defence and national security needs. It is Australia's second largest government-funded
science organization after the CSIRO. The agency's name was changed from Defence Science and
Technology Organization (DSTO) to Defence Science and Technology Group on 1 July 2015.
To achieve its mission, DST provides scientific and technical support to current defence operations,
investigates future technologies for defence and national security applications, advises on the purchase
and smart use of defence equipment, develops new defence capabilities, and enhances existing
systems by improving performance and safety and reducing the cost of owning defence assets.
The Chief Defence Scientist leads DST. The position is supported by an independent Advisory Board
with representatives from defence, industry, academia and the science community. DST has an annual
budget of approximately $440 million and employs over 2500 staff, predominantly scientists, engineers,
IT specialists and technicians.
DST has establishments in all Australian states and the Australian Capital Territory with posted
representatives in Washington, London and Tokyo. DST collaborates with science and technology
organizations around the world to strengthen its technology base and works closely with Australian
industry and universities to enhance defence capability. International engagement allows DST to explore
potential technological opportunities at significantly less cost and provides access to overseas
capabilities otherwise not available to the ADF. DST is a member of The Technical Cooperation
Program (TTCP) with the United States, United Kingdom, Canada and New Zealand. It also has bilateral
defence science agreements with USA, UK, France, Sweden, Netherlands, Norway and Singapore. In
February 2012, DST was given the whole-of-government responsibility to co-ordinate research and
development for Australia's national security.
More Information
CONFERENCES AND MEETINGS
For more information on systems engineering related conferences and meetings, please proceed to our
website.
PPA-006764-1 25 of 39
SOME SYSTEMS ENGINEERING-RELEVANT WEBSITES
Applied Systems Thinking
Michael Goodman and David Peter Stroh have over 50 years of experience with working with leaders in
applying Systems Thinking and have created this site containing a wealth of information to help
introduce Systems Thinking to people at all levels of the organisation. Resources and services are on
offer that will help to develop technical skill and improve effectiveness when applying the principles of
Systems Thinking and tools.
http://www.appliedsystemsthinking.com/testimonials.html
Systems Engineering Software
This site contains access to tools for modelling languages Chi 3 and CIF 3 and cross platform scripting
language ToolDef 2. The tools were developed by the Systems Engineering group of the Mechanical
Engineering Department at Eidhoven University of Technology.
http://update.se.wtb.tue.nl/documentation/
Systems Engineering Job Description Sample
This free system engineer job description sample template can assist recruiters in attracting innovative
and experienced systems engineers to their company. Requirements, benefits and perks specific to the
company should be added to this template before advertising for employment.
https://www.ziprecruiter.com/blog/systems-engineer-job-description-sample-template
CSEP Overview
Downloadable presentation containing an overview of the Systems Engineering Professional certification
program by the International Council on Systems Engineering (INCOSE).
http://www.swe-sc.org/Seminar/CSEP_Overview-%20Heidel.pdf
Innoslate
PPA-006764-1 26 of 39
A full lifecycle systems engineering tool that enables model-based diagrams, requirements
management, lifecycle traceability, verification and validation, simulation and much more.
https://www.innoslate.com/systems-engineering/
INCOSE UK “Z Guides”
INCOSE UK has produced a series of accessible guides to aspects of systems engineering, each in the
form of a one page, double sided, guide designed to be folded up into three panels giving a "Z" cross
section, to be known as "Z-Guides". The aim is to provide focused, accessible, information which can be
presented to individuals who are not directly involved in systems engineering on a day to day basis.
https://incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications&SubCat=zGui
des
SYSTEMS ENGINEERING PUBLICATIONS
Collaboration Across Linked Disciplines: Skills and Roles for Integrating Systems Engineering and Program Management
by
Eric Rebentisch (MIT), Stephen Townsend (PMI), and E.C. Conforto (MIT Consortium for Engineering
Program Excellence (CEPE), Sociotechnical Systems Research Center (SSRC)
Abstract
In new product development programs, systems engineers and program managers must often work
together closely to define the product, the program structure and objectives, and allocate and define the
focus of work effort. Poor communication and lack of integration between these two critical functions can
often spell the difference between success and disappointment for the program and its stakeholders.
Despite common and sometimes overlapping skills required for both disciplines, and their respective
extensive practice and process models, effective integration and collaboration continues to elude many
engineering efforts. Unfortunately, this failure of collaboration and integration negatively impacts
program performance and outcomes. This study draws upon a large global survey of program managers
and systems engineers to better understand the backgrounds, training, roles, and responsibilities of
program managers and systems engineers. The analysis of the data identifies systems engineering and
program management capabilities that are considered critical to program success, as well as those
areas where both roles share key responsibilities. The implications of these findings for engineering
students and for their engineering curricula will be discussed. For systems engineering students and
PPA-006764-1 27 of 39
future engineering leaders, having learned these principles and concepts may be critical to them as they
prepare to enter a highly competitive workforce.
To better understand these issues and their impact on professionals in the project/program management
and systems engineering fields, in the Fall of 2012 INCOSE and PMI established a joint working group to
investigate the issues and challenges to developing closer working relationships between program
management and systems engineering disciplines in organizations. One of the primary objectives of this
alliance was to identify potential areas for improvement, from both a theoretical and a practical
perspective.
Data were collected during the fall of 2012. An invitation to participate in the study was sent to
approximately 3,000 members of the INCOSE System Engineering community of practice and to
approximately 5,000 members of the PMI Program Management community of practice.
Conclusions
The analysis confirmed roles and skills for engineering program leaders (PMs and CSEs) that are
consistent not only with traditional engineering education and training programs but also professional
standards and certifications. This reinforces the notion that these roles are indeed part of functional
disciplines based in specialized knowledge. While each of these domains has unique roles and skills,
there are significant areas of overlapping or shared responsibility, particularly with respect to PMs. Both
PMs and CSEs are viewed as jointly accountable for managing program and project risk, external
supplier relations, quality management, and lifecycle planning. In each of those areas (e.g., managing
program and project risk) there are unique perspectives and analyses that each function brings to the
shared responsibility. Nevertheless, successful integration may not be so much in the accumulation of
multiple analyses as in the way in which one analysis or perspective informs the other, and ultimately
shapes the unified program-level approach. This suggests the ability to synthesize integrated solutions
from multiple perspectives is an important engineering leadership skill. Whether through shared
responsibilities or from the need to share knowledge derived from unique functional responsibilities, the
respective functions need the ability to work together in an integrated fashion. The most important skills
claimed by PMs include leadership and stakeholder management. Combined, these suggest the ability
to bring together diverse interests to embrace a common objective and work collaboratively. The most
important skills claimed by CSEs include system thinking and requirements management, which suggest
an ability to link overarching objectives to detailed elements in a holistic integrated perspective. Both
PMs and CSEs share communication as a key skill. An educational or professional development
program may not necessarily need to develop all of these skills in its students, but it should nevertheless
strive to develop an understanding and appreciation of the different roles that are required in an
integrated program leadership team. Innovative engineering leadership education programs increasingly
emphasize the introduction of more elements of lifecycle processes and operations for engineered
systems, including interpersonal skills and leadership. Yet, they still may not address some of the
organizational and relational elements highlighted by this study. Particularly, integration across functional
PPA-006764-1 28 of 39
and organizational boundaries appears to be an important element of engineering program success.
Unproductive tension between the PM and SE disciplines results when integration of the functions is
informal, ad hoc, or just ineffective. The roots of unproductive tension may ultimately lie with poorly-
defined roles and relationships in the program and organization. As engineering efforts became more
integrated, as relationships become more explicit and formally-defined, the unproductive tension in
organizations is seen to decrease. This suggests that organizational or program design may play a
significant role in shaping the effectiveness of engineering efforts. While engineering students may learn
a good deal about product design during the course of their education, they may not be exposed as
extensively concerning the design of organizations and the relationships they embody. It is
recommended that these issues be considered for addition in future engineering leadership curricula.
More information
Process Analyzer Systems Project Engineering and Management
Image source
by
Gary Nicols
Book Description (from the Automation.com web site):
This book includes specific recommendations for defining hardware and documentation
deliverables, adhering to procurement policy, working with team members in other disciplines and in
the supply chain, and communicating among project teams.
More Information
PPA-006764-1 29 of 39
The Industries of the Future
Image source
by
Alec Ross
Book Description (from the Amazon web site):
Leading innovation expert Alec Ross explains what’s next for the world: the advances and stumbling
blocks that will emerge in the next ten years, and how we can navigate them. While working as Senior
Advisor for Innovation to the Secretary of State, he traveled to forty-one countries, exploring the latest
advances coming out of every continent. From startup hubs in Kenya to R&D labs in South Korea, Ross
has seen what the future holds.
In The Industries of the Future, Ross shows us what changes are coming in the next ten years,
highlighting the best opportunities for progress and explaining why countries thrive or sputter. He
examines the specific fields that will most shape our economic future, including robotics, cybersecurity,
the commercialization of genomics, the next step for big data, and the coming impact of digital
technology on money and markets.
In each of these realms, Ross addresses the toughest questions: How will we adapt to the changing
nature of work? Is the prospect of cyberwar sparking the next arms race? How can the world’s rising
nations hope to match Silicon Valley in creating their own innovation hotspots? And what can today’s
parents do to prepare their children for tomorrow?
Ross blends storytelling and economic analysis to give a vivid and informed perspective on how
sweeping global trends are affecting the ways we live. Incorporating the insights of leaders ranging from
tech moguls to defense experts, The Industries of the Future takes the intimidating, complex topics that
many of us know to be important and boils them down into clear, plainspoken language. This is an
PPA-006764-1 30 of 39
essential book for understanding how the world works—now and tomorrow—and a must-read for
businesspeople in every sector, from every country.
More Information
The Certified Quality Engineer Handbook
Image source
by
Sarah E. Burke and Rachel T. Silvestrini
Book Description (from the Amazon web site):
This fourth edition is intended to provide the quality professional with a reference book aligned with the
ASQ Certified Quality Engineer (CQE) Body of Knowledge (BoK). The book was not written solely as a
study guide to pass the certification exam, but rather as a comprehensive guide to the field of quality
engineering. Therefore, most of the chapters include material that goes well beyond the CQE exam
requirements.
Based on the changes to the CQE BoK, as well as helpful feedback from colleagues and reviewers, this
revised edition contains the following major changes:
• A new chapter on risk management
• An extensively updated glossary
• New and updated references
• A new layout
The editors included many new textbook and journal article references throughout the entire book.
Within the discussion of continuous improvement methods, they added descriptions of and references to
several case studies. These case studies, which include applications in the service industry, give the
PPA-006764-1 31 of 39
reader a broader context on how to apply many of the methods discussed in a real-life scenario. In
particular, some of these case studies are related to quality in the service industry. Additionally, the
editors updated discussions of and references to new technology important to the quality professional,
such as Industry 4.0.
More Information
Configuration Management Best Practices
Image source
by
Bob Aiello and Leslie Sachs
Book Description (from the Amazon web site):
As IT systems have grown increasingly complex and mission-critical, effective configuration
management (CM) has become critical to an organization’s success. Using CM best practices, IT
professionals can systematically manage change, avoiding unexpected problems introduced by changes
to hardware, software, or networks. Now, today’s best CM practices have been gathered in one
indispensable resource showing you how to implement them throughout any agile or traditional
development organization.
Configuration Management Best Practices is practical, easy to understand and apply, and fully reflects
the day-to-day realities faced by practitioners. Bob Aiello and Leslie Sachs thoroughly address all six
“pillars” of CM: source code management, build engineering, environment configuration, change control,
release engineering, and deployment. They demonstrate how to implement CM in ways that support
software and systems development, meet compliance rules such as SOX and SAS-70, anticipate
emerging standards such as IEEE/ISO 12207, and integrate with modern frameworks such as ITIL,
COBIT, and CMMI. Coverage includes:
• Using CM to meet business objectives, contractual requirements, and compliance rules
PPA-006764-1 32 of 39
• Enhancing quality and productivity through lean processes and “just-in-time” process
improvement
• Getting off to a good start in organizations without effective CM
• Implementing a Core CM Best Practices Framework that supports the entire development
lifecycle
• Mastering the “people” side of CM: rightsizing processes, overcoming resistance, and
understanding
workplace psychology
• Architecting applications to take full advantage of CM best practices
• Establishing effective IT controls and compliance
• Managing tradeoffs and costs and avoiding expensive pitfalls
Configuration Management Best Practices is the essential resource for everyone concerned with CM:
from CTOs and CIOs to development, QA, and project managers and software engineers to analysts,
testers, and compliance professionals.
More Information
SYSTEMS ENGINEERING TOOLS NEWS
BigLever's Gears Product Line Engineering Tool and Lifecycle Framework™
The characteristic that distinguishes the systems and software product line engineering (PLE) approach
from the traditional product-centric approach is when an organization has a means of production that
enables it to efficiently create a product line of similar systems from a consolidated set of soft assets
such as requirements, designs, source code and test cases. The focus on that singular means of
production rather than a focus on the multitude of products is what makes the BigLever Software
Gears™ approach so unique.
The Gears PLE Lifecycle Framework provides a set of industry-standard PLE concepts and constructs
that augment your existing tools, assets and processes across the entire lifecycle:
• A feature model that you use to express the feature diversity (optional and varying feature
choices) among the products in your product line.
• A uniform variation point mechanism that is available directly within your tools and their
associated assets, to manage feature-based variations in all stages of the engineering lifecycle.
PPA-006764-1 33 of 39
• A product configurator you use to automatically assemble and configure your assets and their
variation points – based on the feature selections you make in the feature model – producing all
of the assets for each product in your product line.
More Information
EDUCATION AND ACADEMIA
Stevens Institute of Technology Launches Industrial and Systems Engineering Undergraduate Program to Address Growing Need for
Systems Engineers There is a critical need for 21st Century technical leaders who can improve productivity and efficiency for
enterprises in industry and government. Leaders in these enterprises are seeking engineers with
analytical skills and a strong systems perspective. To help fill that need, Stevens Institute of Technology
has launched a new undergraduate Industrial and Systems Engineering (ISE) program to prepare
students with a broad-based engineering foundation, a systems thinking perspective and strong data
analysis skills to improve existing systems and build new modern, efficient systems. The job outlook for
industrial and systems engineers (ISEs) is expected to grow steadily over the next decade based on
data from the Bureau of Labor Statistics. Typical roles Stevens ISE graduates are well-positioned to
pursue after graduation include industrial engineer, systems engineer, systems integration engineer,
quality engineer, project engineer, sales and marketing engineer, and more.
The Stevens ISE program emphasizes cross-disciplinary systems perspectives and complex data
analysis in its core curriculum. The aim of the program is to teach students to think about the ways in
which technology can help organizations accomplish goals through the application of data science to
define engineering solutions. Another unique component of the Stevens ISE program is that students will
have varied opportunities to interact with well-known systems engineering researchers at Stevens, which
is home to state-of-the-art research centers: the Systems Engineering Research Center (SERC) and the
Center for Complex Systems and Enterprises (CCSE). Through these centers, faculty, and
undergraduate and graduate researchers, collaborate with interdisciplinary academic and industry
partners to understand and address the increasing complexity of the world’s systems.
More Information
STANDARDS AND GUIDES
ASQ/ANSI/ISO/TR 9002:2016: Quality Management Systems — Guidelines for the Application of ISO 9001:2015
PPA-006764-1 34 of 39
ISO/TS 9002:2016 provides guidance on the intent of the requirements in ISO 9001:2015, with examples
of possible steps an organization can take to meet the requirements. It does not add to, subtract from, or
in any way modify those requirements.
ISO/TS 9002:2016 does not prescribe mandatory approaches to implementation, or provide any
preferred method of interpretation.
More Information
The ASQ Pocket Guide to Root Cause Analysis All organizations experience unintended variation and its consequences. Such problems exist within a
broad range of scope, persistence, and severity across different industries. Some problems cause minor
nuisances, others leads to loss of customers or money, others yet can be a matter of life and death.
The purpose of this pocket guide is to provide you with easily accessible knowledge about the art of
problem solving, with a specific focus on identifying and eliminating root causes of problems.
Root cause analysis is a skill that absolutely everybody should master, irrespective of which sector you
work in, what educational background you have, and which position in the organization you hold. The
content in this little pocket guide can contribute to disseminating this skill a little further in the world.
More information
A DEFINITION TO CLOSE ON
What is Cyber Security? Cybersecurity is the body of technologies, processes, and practices designed to protect networks,
computers, programs, and data from attack, damage, or unauthorized access. In a computing context,
security includes both cybersecurity and physical security.
Ensuring cybersecurity requires coordinated efforts throughout an information system. Elements of
cybersecurity include:
• Application security
• Information security
• Network security
• Disaster recovery / business continuity planning
• Operational security
PPA-006764-1 35 of 39
• End-user education
One of the most problematic elements of cybersecurity is the quickly and constantly evolving nature of
security risks. The traditional approach has been to focus most resources on the most crucial system
components and protect against the biggest known threats, which necessitated leaving some less
important system components undefended and some less dangerous risks not protected against. Such
an approach is insufficient in the current environment. Adam Vincent, CTO-public sector at Layer 7
Technologies (a security services provider to federal agencies including Defense Department
organizations), describes the problem:
"The threat is advancing quicker than we can keep up with it. The threat changes faster than our
idea of the risk. It's no longer possible to write a large white paper about the risk to a particular
system. You would be rewriting the white paper constantly..."
To deal with the current environment, advisory organizations are promoting a more proactive and
adaptive approach. The National Institute of Standards and Technology (NIST) for example, recently
issued updated guidelines in its risk assessment framework that recommended a shift toward continuous
monitoring and real-time assessments (https://www.nist.gov/cyberframework).
According to Forbes, the global cybersecurity market reached $75 billion for 2015 and is expected to hit
$170 billion in 2020.
More information
PPI AND CTI NEWS
PPI Participation in the NZDIA Conference We were pleased to have had more presence at the New Zealand Defence Industry Association (NZDIA)
conference this year. Unfortunately, this conference tends to attract protesters who barricade entrances
and make it very difficult for the conference to take place. The organisers this year masterminded
contingency plans and managed to arrange access to the venue without too much disruption. This year
we were pleased to see the conference showcased many different products and service offerings,
fantastic and informative speakers as well as wonderful networking opportunities. It is always a pleasure
being in New Zealand, the Kiwi’s are ever so welcoming and are happy to take the time to have a
friendly chat. We are sure to further develop existing relationships as well as create many new ones from
this exciting opportunity.
PPI Participation in the INCOSE South Africa Conference The INCOSE South Africa Conference hosted its 13th Annual Conference over 11 – 13 Oct 2017. The
conference attracted a mix of professionals from industry, government, and academia. The programme
PPA-006764-1 36 of 39
comprised of more than twenty peer reviewed papers, six tutorials and an impressive line-up of keynote
speakers on various topics.
The conference also hosted the culmination of the GYSEOY (Greatest Young Systems Engineer of the
Year) challenge as well as the WiSEMOY (Wisest Systems Engineering Mentor of the Year) Challenge.
There was also an opportunity for engineers attending the conference to start their journey in becoming
certified as systems engineering professionals (SEPs) through INCOSE’s certification programme by
taking the free INCOSE SEP knowledge exam based on the INCOSE handbook.
The INCOSE SA MBSE Working Group was officially launched at the conference as well.
More information on the conference can be viewed here.
Newest Addition to the List of INCOSE Systems Engineering Professionals
We are proud to announce that CTI’s Chinese Professional Development Manager, Victoria Huang has
taken the INCOSE knowledge examination and has passed! Victoria will become the newest member of
our team to become certified as a systems engineering professional! Congratulations Victoria.
UPCOMING PPI AND CTI PARTICIPATION IN PROFESSIONAL CONFERENCES
PPI will be participating in the following upcoming events.
INCOSE UK, Annual Systems Engineering Conference (ASEC) 2017
(Exhibiting)
21 - 22 November 2017
Warwick, UK
8th CSD&M Paris
12 - 13 December 2017
Paris, France
INCOSE San Diego Mini-Conference
2 December 2017
San Diego, California, USA
INCOSE IW2018
20 – 23 January 2018
Jacksonville, Florida, USA
PPA-006764-1 37 of 39
INCOSE IS2018
7 – 12 July 2018
Washington, DC, USA
PPI AND CTI EVENTS
Systems Engineering 5-Day Courses
Upcoming locations include:
• Eindhoven, the Netherlands
• Las Vegas, NV, United Stated of America
• São José dos Campos, Brazil
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
• Las Vegas, NV, United States of America
• Amsterdam, the Netherlands
• Pretoria, South Africa
Systems Engineering Management 5-Day Courses
Upcoming locations include:
• Las Vegas, NV, United States of America
• Stellenbosch, South Africa
• Amsterdam, the Netherlands
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
• Amsterdam, the Netherlands
• Ankara, Turkey
• São José dos Campos, Brazil
Architectural Design 5-Day Course
PPA-006764-1 38 of 39
Upcoming locations include:
• London, United Kingdom
• Pretoria, South Africa
• Stellenbosch, South Africa
Software Engineering 5-Day Courses
Upcoming locations include:
• Pretoria, South Africa
• London, United Kingdom
• Las Vegas, NV, United States of America
Human Systems Integration Public 5-Day Courses
Upcoming locations include:
• Sydney, Australia
• Melbourne, Australia
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
• Madrid, Spain
• Pretoria, South Africa
• Laurel, MD, United States of America
Kind regards from the SyEN team:
Robert Halligan, Editor-in-Chief, email: [email protected]
Dr. Ralph Young, Editor, email: [email protected]
Suja Joseph-Malherbe, Managing Editor, email: [email protected]
Project Performance International
PPA-006764-1 39 of 39
2 Parkgate Drive, Ringwood North, Vic 3134 Australia Tel: +61 3 9876 7345 Fax: +61 3 9876 2664
Tel Brasil: +55 11 3958 8064
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Web: www.ppi-int.com
Email: [email protected]
Copyright 2012-2017 Project Performance (Australia) Pty Ltd, trading as Project Performance
International.
Tell us what you think of SyEN. Email us at [email protected].