Home » Resources » SyEN Newsjournal » PPI SyEN 60

PPI SyEN 60

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 60

In This Edition

Quotations to Open On

Feature Article

A Convergence Model for Systems Engineering, by Michael Gainford

Article

Navigating the Future of IoT One Step at a Time, by Wael Elrifai
Second Generation Product Line Engineering for Systems and Software (Part 3), by Dr. Charles W. Krueger
Integrating Program Management and Systems Engineering, by Dr. Ralph Young

Systems Engineering News

INCOSE Foundation
2018 Engineers Week Planning Webinar

Featured Organizations

International Society for Systems Pathology (ISSP)
Society of Asian Scientists and Engineers (SASE)
STEM Education Coalition
INCOSE Program Management-Systems Engineering (PM-SE) Integration Working Group

Conferences and Meetings

Some Systems Engineering-Relevant Websites

Systems Engineering Publications

New INCOSE Publications and Presentations Library
Second Edition of INCOSE Guide to Writing Requirements
The Future of IoT
How Technology will Impact Our Future
Systems Thinking for Peacebuilding and Rule of Law
Product Line Engineering Newsletter
Configuration Management Resources
Sociotechnical System Safety: Hierarchical Control versus Mindfulness
System: The Shaping of Modern Knowledge

Systems Engineering Tools News

Education and Academia

Online Master’s Degree in Systems Engineering at George Mason University, Virginia, USA
Caltech (California USA) Opens New Center for Autonomous Systems and Technologies

Standards and Guides

ISO/IEC TS 24748-6:2016: Systems and Software Engineering – Life Cycle Management — Part 6: System Integration Engineering

Definitions to Close On

PPI and CTI News

Upcoming PPI and CTI Participation in Professional Conferences

PPI and CTI Events

QuotationS to Open On

“Most people don’t listen with the intent to understand – they listen with the intent to reply.”

Stephen R. Covey

“A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.”

Freeman Dyson

“Systems engineering is not a process, it is a set of principles and a set of process tools with which to implement the principles. Apply the principles all the time. Use the tools selectively, based on the specifics of the task at hand.”

Robert John Halligan

Feature Article

A Convergence Model for Systems Engineering

Michael Gainford

MA(Eng), FRAeS, CEng, MSc, ESEP, MINCOSE

Abstract

Readers of the Systems Engineering Newsletter (SyEN) are invited to participate in helping to refine concepts concerning a convergence model for systems engineering. There are at least three questions of interest:

Is a convergence model for systems engineering potentially useful?
If so, why and to whom, and how could it be improved?
Is it original? (If not, I apologize to the authors whose work I have not read, and hope that SyEN readers can point me to relevant work so that I can give it credit.)

Several development models are well-known to SyEN readers (including the “V” or “Vee” model, iterative, incremental, spiral [2], and agile [9]). They all have their uses, and some have their problems. Over a number of years, the author has, in a rather unconscious and unresearched way, developed a different way of communicating what goes on during a systems engineering endeavor.

The so-called convergence model “does what it says on the tin”, and is launched on the unsuspecting SyEN readership as a crowd experiment. (The author grew up in the era of analogue computers but likes to give the impression that he can keep up with the times.)

Simply put:

There is a Problem (P) to be solved;
There is a Solution (S) to be created, deployed, operated, maintained, and retired;
We use Evaluation (E) to assess the match between P and S;
We systems engineers push for convergence between P and S.

The proposed model potentially offers benefits in terms of communication, cohesive decision-making, and planning for verification and validation.

Introduction

The author has been a practicing systems engineer and project manager for several decades. During that time he has seen a range of development models used, and always felt that there was something lacking about them. The proposed convergence model can potentially address some of those concerns.

Philosophical origins

The convergence model may be attractive because it resonates with how we human beings think about things. This assertion is explained in paragraphs 2.1, 2.2, and 2.3.

An allegorical tale in 2.4 may help to make the philosophy more tangible.

1. How we think, in general

The philosopher John Dewey, in How we Think [4], describes a five-step model for how we engage in reflective thinking. Figure 1 aims to represent John Dewey’s text in diagrammatical form.

We feel a difficulty, or tension, and this incites us to think about the situation. The Dewey text deals mostly with finding explanations for things, and believing or not believing the suggested explanations.

1. How we think, while solving problems

Arthur Hall, in a relatively early systems engineering textbook [5], developed this into the more specific case of where we desire to find solutions to problems. His representation, based on another work by John Dewey [6], is reproduced in Figure 2.

1. How we think, in relation to the convergence model

A static view of the convergence model, which is a further development of Hall’s representation, is shown in Figure 3.

The problem statement corresponds to Dewey’s “felt difficulty” or “tension”. In systems engineering, this incites us to do more than just understand a situation; it incites us to do something about it. In this article we do not need to debate the vocabulary of “problem”, “opportunity”, or “need” and for simplicity will use “problem” to cover any situation that demands action. We remember that what is good news for one stakeholder may be bad for another. {A new high speed train line may be good for business people, but less palatable to the couple who devoted 30 years of their life to developing a beautiful garden at the side of the proposed track.]

In a similar way, to simplify the text and the diagrams, we may use “Solution” to cover definitions of proposed solutions, or the solutions themselves.^[1]

1. An allegorical tale

“One night as I was trying to go to sleep I heard some scratching noises in the attic. They persisted for about 10 minutes but then stopped. My anxiety about this made it difficult to sleep, but I resolved to buy a few “humane” mouse traps in the morning, and after a while was able to “drift off”.

The next morning, I installed the mouse traps, hoping to have solved the problem. During the day, I started to think about the possible outcomes of this experiment, and I looked into my systems engineering toolbox to find one of my favorite analysis tools; “the 4-box chart”; see Figure 4.

I then realized that when evaluating the problem, the solution, and the match between problem and solution, I was not going to make much progress based on my impetuous decision-making approach. I also started to think about root-cause analysis; the scratching was only a symptom, but what was the cause? I needed to put forward alternative solutions, and do a trade study, but without knowing the problem I was stuck. Maybe the problem was not that I heard noises, but that I heard noises (solution path: doctor – audiologist – psychiatrist).

By now it was obvious that my confidence in the evaluation would be very low, but how much confidence would I need? That would depend on the impact of failing to deal with the situation. If mice could chew through cables and cause a fire I would need very high confidence. If I wanted to sell the property and was concerned about surveyors finding mice in the attic, a moderate level of confidence might suffice. If I could get used to scratching sounds whilst falling asleep, a low level of confidence would be enough.”

Reflecting on the above, we need to establish our level of confidence in all three of the problem, the evaluation, and the solution. In the author’s experience:

It is “business as usual” for most businesses to check their confidence in the solution (even though they may be hazy about understanding the problem);

There has been an increasing trend for businesses to appreciate the need for checking their confidence in the problem statement, and some businesses do this in a systematic and effective way;

Relatively few businesses have a systematic approach to determining and demonstrating the required confidence level in the evaluation. This consideration is vitally important to drawing up an effective plan for verification and validation^[2]. Halligan offers a methodology for doing this with the Verification Requirements Specification [7, 8].

Development models: synopsis

We use development models as a communications tool and to govern how we progress through our development activities in an orderly fashion. Selection of the most appropriate development model for your project deserves careful attention in the planning stage. Having selected and tailored it:

It needs to be well-communicated;
Processes have to be written to align with that choice.

The ubiquitous V-model [3] is strong on showing logical dependencies between work products as we decompose and recompose (the architecture depends logically on requirements; solution elements depend on element specifications; etc.). In a V-diagram, the vertical axis shows levels of decomposition, which is a powerful communications tool. But what does the horizontal axis show? Only if we have a truly sequential project does it show time. Halligan [1] suggests that we can more generally think of it as a time trend.

There seems to be a natural human compulsion to read time into the V-diagram, and lots of variants have been produced to overcome this. However hard we try to explain that time dependency is not necessarily the same as logical dependency, there is a risk that the V-diagram confuses people, losing some of its power as a communications tool.

The spiral model [2] acknowledges that we can explore the Problem and the Solution in parallel, checking in at the end-of-loop gates to see how they match. This has many attractions, but doesn’t quite satisfy the craving to read time into the diagram: we have to imagine unravelling the spiral into a straight line. When presented as a spiral, the radial direction corresponds to a cumulative increase in cost incurred.

Another representation: a convergence model
1. The match between problem and solution

Figure 5 illustrates how the convergence model represents the match between problem and solution, at a given point of time, for some selected cases.

Cases 1 and 2 represent two different problem-solution pairs when the confidence in the evaluation is high (a short bar for “E”). Although in each case there may be more work to do to improve the match, we can be confident that we understand where the issues lie, which will lead to better-informed decision-making.

For Case 3, the confidence in the evaluation is low (a long bar for “E”). In this case, the match between problem and solution is unclear; it could be anywhere on the following spectrum:

Worst case (no match) – Case 3a;
Most likely (some match) – Case 3b;
Best case (full match with some gold plating and some waste) – Case 3c.

In the author’s experience, most Gate reviews (which are major decision points in the system life cycle) have only asked about Case 3b.

1. How the match changes with time; the convergence model

Figure 6 illustrates the fundamental concepts behind the convergence model:

“P” represents the Problem;
“S” represents the Solution;
“E” represents our Evaluation of the match between P and S;
The horizontal axis represents time (yes, really!);
The vertical axis represents effectiveness (in an admittedly abstract way);
The heights of the bars represent our uncertainty in expressing P, S, and E;
As time progresses, we aim to achieve convergence between P and S, whilst reducing our uncertainty in P, S, and E;
A number of evaluation points, reviews, and gates are indicated; these feed into the project decision-making processes;
When the solution “goes into service” (or whatever the equivalent is), there may still be discrepancies between P and S, but we will be very confident that we understand them (a short bar for E);
The bars indicate that there is hopefully overlap between P and S. There can still be areas of P unaddressed, and areas of S that do not strictly serve a purpose, but as our confidence in E improves we will understand these better;
There could be some “gold plating” (see Figure 5 Case 2), but this possibility has been omitted from Figure 6;
E includes elements of both validation and verification (see Footnote 2);
The suggested downward trend in the mid-point of the “P” bar has only been used to give the diagram a symmetrical visual appeal. Of course there are many projects where the stakeholders are persuaded to reduce their aspirations during a project, but it doesn’t have to be that way. Alternatively the mid-point of “P” could be flat, with the solution climbing to meet it, or it could climb as opportunities are found to go beyond the original aspiration.

1. Variations on the theme

Many development model stories can be explained using the fundamental concepts in Figure 6. A few examples are provided in the following sections. Readers are invited to try out their own!

- 1. S-heartbeat faster than P-heartbeat

Figure 7 depicts a project where significant effort goes into baselining a set of requirements (P) early on. There are subsequently several iterations in S before P gets re-baselined. Each evaluation (E) of the P-S gap is done with respect to the early baseline of requirements.

We are rather trusting that the revision of requirements at Gate 4 is just a tidy-up!

- 1. In-service problem-led change

Figure 8 depicts what happens if (when) a new requirement comes along in service. At Gate 3 the solution is the same, but three things instantly increase:

The mismatch between P and S
Our uncertainty in P
Our uncertainty in E (we can’t be sure to understand the mismatch if we don’t understand the problem)

At Gate 4, we have a modified solution that increases uncertainty in S, and potentially in E.

We then use our systems engineering toolkit to achieve convergence by Gate 5.

- 1. In-service solution-led change

Figure 9 shows what happens with an in-service Solution-led change. This could typically happen if solution problems emerge in service, or if components become obsolete.

At Gate 3:

P is initially unchanged;
we know that the mismatch between P and S has increased (because we had a problem);
the solution is changed;
Our uncertainty in S and E increases.

At Gate 4:

The change control board spots an “opportunity” to introduce new requirements or “improve” existing ones (“we are opening the system up anyway”). This could be on the same day as Gate 3, or the day after. Alternatively, the change control board could resist the temptation.
- 1. Incremental and iterative approaches

For the purposes of this discussion, the author does not attempt to distinguish between “incremental” and “iterative” approaches (readers may not be unanimous on that issue, but it doesn’t matter for the purposes of this paper).

Figure 10 tells a story that might be described as incremental, or perhaps as something else. Hopefully readers can see how to tailor it to their understanding of such development approaches.

Imagine that at Gate 1, we have an initial problem understanding (P) and an idea of a solution concept (S). We then develop an early version of a solution (or a particular element of it), with reference to the initial P. When we get to Gate 2, we share the early solution with stakeholders. They like some aspects of it, there are bits they don’t like, and often they get excited to see that it can do things they had never imagined. They use an early version of S to help them articulate their needs, so uncertainty in P instantly goes up. Then we realize that some aspects of S aren’t relevant, and some are now missing, so uncertainty in S also increases.

We can imagine this scenario repeating itself a few times before ultimately getting to Gate 4, where everyone agrees there is sufficient match between P and S, given our confidence in E.

- 1. Combining development approaches

A system, by definition, comprises a number of elements. The optimum development model choice for the elements may not be the same as the optimum choice for the system. Hence a system development model may need to accommodate a mix of element-level development model approaches that are not necessarily synchronized.

Figure 11 offers a way of telling this story.

As depicted by the red dots in the diagram, the Gate 2 build standard at system level has to consist of valid combinations of element-level configurations. This is not necessarily the latest version of each element “on the day”. Halligan’s “Wedge” model [1] illustrates this in another way, using a 3-dimensional version of the “V”.

The diagram shows that selection of the optimum development model at system level is not a straightforward task. There is clearly a benefit in being able to align the element-level development models to the extent that this can be done without forcing a burden onto the element suppliers.

The reader is now asked to imagine combining Figure 6 with Figure 11, and to use Figure 6 as an alternative representation of the concepts behind the spiral model. Figure 6 can accommodate a whole range of element-level models as in Figure 11. Suggestion: the spiral model is an over-arching representation that can combine a range of element-level models, and the mix of element-level models can change as we go through a project. For example, an element that started out as incremental may switch to sequential once the risks in P and S are sufficiently low.

Feedback request

The author would be delighted to receive any feedback at Michael.Gainford@es.catapult.org.uk.

Some questions:

Is a convergence model for systems engineering potentially useful?
If so why and to whom, and how could it be improved?
Is it original? (If not, please point me to relevant work so that I can give it credit)
Did you have a go at representing your project using the convergence model and if so, what did it look like?
Summary and conclusions

The proposed convergence model may have benefits in how we communicate our development approaches. Readers have been asked to comment, and to provide ideas for its further development.

The main benefits claimed for the convergence model are as follows:

It seems to resonate with “the way we think”;
It integrates the consideration of uncertainty in Problem, Solution, and Evaluation, thus providing a more cohesive input to decision-making;
The consideration of uncertainty in Evaluation should be a driver for effective verification and validation planning;
With further work, there is at least potential for the vertical axis of the model to have some qualitative/quantitative meaning related to effectiveness, and the horizontal axis represents elapsed time. Other well-known development models are perhaps less tangible in terms of the meanings of the axes.

List of acronyms used in this paper

Acronym Explanation

E Evaluation

P Problem

S Solution

Acknowledgements

My thanks are due to:

Philip J. Wilkinson (Rolls-Royce), who showed me Arthur Hall’s model (Figure 2), well over a decade ago;
Ian Gallagher (Altran), who reviewed a much earlier version of these ideas, a few years ago;
Robert Halligan, Ralph Young, and Alwyn Smit (Project Performance International), who all provided valuable inputs into the current article.

References

[1] Halligan, Robert J. ”Beyond the “Vee” Model: The Wedge Model”. Systems Engineering Newsletter (SyEN 57), September 18, 2017. Available at www.ppi-int.com/systems-engineering/SYEN57-a2.php. Accessed October 29, 2017.

[2] Boehm, Barry W. “A Spiral Model of Software Development and Enhancement”, 2000. Available at

http://csse.usc.edu/TECHRPTS/1988/usccse88-500/usccse88-500.pdf. Accessed October 26, 2017.

[3] Tim Weilkiens, Jesko G. Lamm, Stephan Roth, and Markus Walker. “The V-Model.” Model-Based System Architecture, First Edition, 2016 John Wiley & Sons. Available at

http://onlinelibrary.wiley.com/doi/10.1002/9781119051930.app2/pdf. Accessed October 27, 2017.

[4] Dewey, John, “How we Think”, 1909, BiblioBazaar, ISBN-10: 1110296037.

[5] Hall, Arthur D., “A Methodology for Systems Engineering”, 1962, D. Van Nostrand, Princeton, New Jersey.

[6] Dewey, John, “Logic, the Theory of Inquiry”, 1938, Henry Holt and Co., New York.

[7] Halligan, Robert J. “The Business Case for Requirements Engineering”. April 2014. Available at http://www.ppi-int.com/systems-engineering/free%20resources/P1343-005258-2%20The%20Business%20Case%20for%20Requirements%20Engineering%20140409.pdf. Accessed October 29, 2017.

[8] Project Performance International. Data Item Description (DID), Verification Requirements Specification. Identification Number PPA-003914-3, 30 May 2012. Available at www.ppi-int.com/systems-engineering/free%20resources/PPA-003914-3%20(VRS)%20120530.pdf. Accessed October 29, 2017.

[9] Taymor, Emmerson. “Agile Handbook”. Available at http://agilehandbook.com/agile-handbook.pdf.

Accessed November 15, 2017.

Article

Navigating the Future of IoT One Step at a Time

Wael Elrifai

Like many of you, I’ve been in the big data, machine learning and Internet of Things gig long enough to assemble an impressive collection of battle scars from use cases and technologies that were closer to bleeding edge than cutting edge.

In collaboration with Emil Berthelsen, IoT Analyst at Gartner, and Don DeLoach, co-chair of the Midwest IoT Council, we set out to help organizations learn from our battle scars, so they could gain the greatest and most sustainable competitive advantage with IoT.

In 2014, we read an article by Michael E. Porter and James E. Heppelmann, and their vision for IoT’s five-stage evolution in Harvard Business Review culminating in a ‘systems of systems’ model. In this model, diverse systems are orchestrated and optimized in the form of constructs like smart factories, smart homes and smart cities.

The five-stage model is now generally accepted and inspired me, DeLoach and Berthelsen to collaborate on a new book “The Future of IoT: Leveraging the Shift to a Data Centric World” (published by BookBaby and available from Amazon and other booksellers.

In the book we draw on our experience with live projects to put what’s happening on the ground today into the context of these five stages. The book also offers practical advice to enterprise IT and data leaders seeking to prepare their architectures for IoT’s future and gain as much value as possible from implementations.

The profound transformation to IoT and data-driven architectures will also involve new ways of working, new skills and resources, new types of contractual arrangements and significant cultural change up and down the supply chain. We explore all these in the final chapter of the book, but today, I’d like to share are top initiatives from the checklist that organizations will need to employ to further evolve their use of IoT:

1. Identify and prioritize IoT applications suitable and relevant for the organization, not just the product. – This practice helps organizations assess which business processes and products IoT can impact within a given organization.

2. Understand both technology infrastructures and architectures as well as data models and flows. – Understanding this will enable executives and further their organizations to generate transparency on what data flows from where and to whom and when. This can additionally assist in creating openness about how data is managed and secured within an organization.

3. Ensure that all enterprise data is managed through a single point of control from within the enterprise. – Use of a single point of data management within an organization aids the identification of preferred architectural models for the deployment of the first receiver concept.

4. Establish a secure and functioning publisher-subscriber first receiver approach to data management within the enterprise. – This practice enables organizations to implement the first receiver architecture as closely integrated with IoT initiatives.

5. Develop and share with your partner, suppliers and customers, clear guidelines on how data is managed and share between stakeholders in various processes. – Sharing this information allows executives to secure that data is not locked into single business processes, but instead open for use and sharing as decided on by the collective enterprise.

6. Collaborate with technology service providers promoting and encouraging open data systems rather than closed loop solutions. – By viewing market developments as a collaborative opportunity rather than a competitive environment, executives can advance the capabilities of IoT within an organization.

7. Continue developing and exploring IoT opportunities and implementations, and build successful data aggregation approaches, models and analytical tools. – Organizations can build on data from existing and newer and smarter connected products. They can also build on data by opening data aggregation to other data sources.

8. Make sure the entire organization understands the IoT objectives of the business, and how IoT transforms the industry. – Enterprise IT and data leaders can enable this understanding through educating the organization about IoT, and how it is changing the fundamental nature of everyday business operations.

We fully acknowledge that in realizing the system of systems model, technology architecture and governance is only one piece of the jigsaw. We also believe the benefits IoT offers to organizations and society at large massively outweigh the risks and that ultimately people will have the will to overcome the challenges to make this system of systems vision become reality.

More Information

Article

Second Generation Product Line Engineering for Systems and Software (Part 3)

Dr. Charles W. Krueger

BigLever Software CEO

ckrueger@biglever.com

Welcome to Part 3 of the newsletter series spotlighting Second Generation Systems and Software Product Line Engineering (2G PLE). The focus of this informational series is to provide insight into the latest product line engineering (PLE) approaches that have enabled companies across a diverse range of industries to more efficiently extend and evolve their product line portfolios, achieving new levels of competitiveness and profitability.

The PLE Lifecycle Framework and 3-Tiered PLE Methodology

In response to the needs of mainstream engineering organizations for a complete new generation PLE solution, BigLever Software created the PLE Lifecycle Framework and 3-Tiered PLE Methodology. This industry-standard PLE framework and pragmatic methodology provide the essential 2G PLE capabilities needed to shift from product-centric approaches to create an automated, optimally efficient means of production for systems and software product lines.

With a complete PLE solution – including software infrastructure, tools, integrations, methodology, and best practices – your organization can make a systematic and incremental transition to an operational PLE production line, as illustrated in this graphic (click image to enlarge). By focusing both your business and engineering teams on the operation of your production line, your organization can plan, develop, deploy and evolve your product line portfolio, seamlessly and efficiently, across every stage of the engineering lifecycle – from business case and analysis, to requirements, design, implementation, testing, delivery, maintenance and evolution.

The PLE Lifecycle Framework provides a set of common PLE concepts and constructs that augment your 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.
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 – to produce all of the assets and products in your product line, with the push of a single button.

A key capability of the PLE Lifecycle Framework is the integration of PLE concepts into your tools, assets and processes across the systems and software development lifecycle.

The PLE Framework is compatible off-the-shelf with many of the industry standards in programming languages and compilers, integrated development environments, requirements management, change and configuration management, build systems, quality management, model driven development, word processors and documentation. This graphic illustrates how the different PLE concepts and constructs expand your collection of tools and processes – making them product line aware – in three dimensions of distinct and synchronous PLE concerns:

Multi-product. The feature-based variation management and automated production line necessary to engineer and deliver the multiple products in a product line are provided directly by the feature model, variation point mechanism and product configurator.
Multi-phase. The tools necessary to support the multiple phases of a product line engineering lifecycle are the same tools you use today, augmented by the PLE Lifecycle Framework to provide consistent variation management and PLE operations.
Multi-baseline. Change management and configuration management for a product line are done on multiple evolving baselines of the PLE assets rather than on a multitude of individual product baselines.

The final piece of a complete PLE solution is the 3-Tiered Methodology, a practical tiered approach that allows you to remove barriers, make a non-disruptive transition and successfully operate your PLE production line. Each tier builds upon and is enabled by the previous tier:

Base Tier (1) – Feature-based Variation Management and Automated Production: Tools, integrations and infrastructure for engineering product line features, product feature profiles, product line hierarchy, feature-based variation points in assets, and automated feature-based configuration of product line assets into products and deliverables.
Middle Tier (2) – Feature-based Asset Engineering: Processes and organizational structures for engineering the full lifecycle of product line assets – from requirements to architecture, design, implementation and test – on multiple delivery streams in a production line.
Top Tier (3) – Feature-based Portfolio Management: Business-wide management of a product line portfolio by the features offered and the profile of features allocated to each product.

Article

Integrating Program Management and Systems Engineering

Dr. Ralph R. Young, Editor, SyEN

This month we provide a summary of Chapter 5, Key Concepts in Integration, in Integrating Program Management and Systems Engineering (IPMSE), 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).

Integration of program management and systems engineering is a critical issue for all systems engineers because the current approach of systems development and project management is not sustainable.

Integration is a reflection of the organization’s ability to combine program management and systems engineering practices, tools and techniques, experience, and knowledge in a collaborative and systematic approach in the face of challenges, in order to be more effective in achieving common goals and objectives in complex program environments.

Eisner^[3] characterizes a high degree of integration between project management and systems engineering by:

Strong and effective teams.
Commitment to “getting the job done”.
Deep interest in the technical issues.
Constructive problem solving.
Corporate support for the needs of the project.
Little or no complaining.
Short and productive meetings.
Rapid flow of information.
Effective computer support.
Involved and happy people.

Eisner argues that integration can be realized on different complementary levels: managers, teams, plans, the systems approach, methods and standards, information systems, and enterprises can act as integrators. These characteristics of integration between program management and systems engineering tend to focus on behaviors and observable outcomes and to not address the integration of the work itself – how tasks are structured and performed. That criticism could also be levied against organizational and management theories. Nevertheless, the similarities between these characteristics and those found in organizational theory and in the case studies in ‘The Book’ are confirmatory regarding the general characteristics and attributes to be emphasized in defining the integration between program management and systems engineering disciplines.

You might consider which of the above integration elements seems relevant in your experience. How would you gauge the level of integration between program management and systems engineering in your project, program, and organization? Does your organization have a formal and deliberate approach to integrating the program management and systems engineering disciplines? What new formal practices would you add to further strengthen and improve project and program success? Do you believe that true integration between disciplines results from applications of leading integrating practices or from an underlying orientation toward integration?

Part of the challenge in achieving integration is having as a starting point a useful, multifaceted understanding of what integration between these disciplines entails. It is more than just having and employing a set of accepted practices or standards. Integration reflects a state of and organization and its operations. As such it is not a simple concept, but rather a multidimensional indication of a number of attributes, activities, and orientations in operation within the organization. One can generate a list of practices associated with integration – many do – and such a list may be temporarily helpful, but perhaps ultimately distracting from the real work in organizations that is demanded by true integration.

The research indicated that integration positively impacts program outcomes.

The stakes are high – society desperately needs programs to be more successful than they are currently. In the future, the need for the programs that support and deliver these complex socio-technical systems to be successful may have societal impacts. Outcomes associated with the prevailing approaches to integrating these functions suggest that there remain significant opportunities for improvement. There are real reasons why integration is challenging, ranging from the way professionals gain, maintain, and update their skills, to the organizational environments and processes in which these professionals are engaged. The good news is that there are numerous examples of organizations that produce exceptional outcomes by operating in a more integrated fashion. They offer many lessons about how to achieve this level of performance by describing the strategies, policies, and methodologies used to achieve a higher level of integration, and thus better outcomes for the organization and its projects and programs.

I encourage you to get ‘The Book’ and to digest the discussion on pp. 69-76 concerning why the divergence between the Project Manager and the Chief Systems Engineer is a major problem. In my opinion, doing so will strengthen your capabilities and contributions.

Systems Engineering News

INCOSE Foundation

From the INCOSE web site:

Anticipate the Future – It is our goal to support programs that help the INCOSE Foundation fulfill our place in making this a better world to live in and that will continue to earn the confidence that our flagship donors have placed in us to promote the best practices of systems engineering. The future is extraordinary and challenging – and, with your help, we will continue to meet the challenge. – John Ross Snoderly, Foundation Chair

INCOSE Foundation Scholarships

The Directors of the INCOSE Foundation are committed to rewarding skills through the scholarships we bestow. With the help of our donors, we celebrate and reward those who are engaged in finding solutions to complex technical challenges at all stages of their education or career. The INCOSE Foundation offers possibilities for people to pursue goals that anticipate the future – for them and for the world.

ISEF, the International Science and Engineering Fair INCOSE Award to a pre-college student
The Chesapeake Chapter Award
The JHU Alexander Kossiakoff Award to a student in a Masters or Doctoral program
The Stevens Doctoral Award for Promising Research in Systems Engineering to a Ph.D. Candidate
The James E. Long Award for Post-Doctoral work.

Selected Projects

The INCOSE Foundation provides funding for selected projects. Current projects include the publication of Vision 2025 – A World In Motion; and the BKCASE project.

In 2017, the INCOSE Foundation awarded grants to 11 INCOSE Chapters and Working Groups. The Foundation is very glad to be able to support the activities of these 11 with grants that are made possible by donations to The INCOSE Foundation.

Greatest Young Systems Engineer of the Year Challenge – Competitors are given a systems engineering challenge, SE process training and MBSE Tool training. Winners receive a prize at the annual INCOSE SA 2017 Conference

STEM program in Indianapolis inner city schools: a collaboration between the INCOSE Crossroads Chapter and the 100 Black Men of Indianapolis organization. Three grade groups participate.

The evolution of a system model, capturing the overall architecture, identifying key interfaces, and establishing the control means and functional behavior of the energy microgrid in select counties of Cayuga Ohio. INCOSE Power and Energy WG

An Open Source Relational Data Base (RDB) on Systems Processes Theory & Systems Pathology: How Systems Work and Don’t Work Input of a vast amount of data into one, SE organized and useful RDB allowing multiple searches by SE engineers, in the pursuit of systems mimicry and practical engineering solutions to systems problems. SSWG (Systems Science WG) and NSWG (Natural Systems and Complex Systems WG)

Initiation of a New Professional Society -International Society for Systems Pathology (ISSP): a new professional society that unifies many different systems approaches to how systems fail to better inform SE design & delivery. SSWG (Systems Science WG) and NSWG (Natural Systems and Complex Systems WG)

Promotion of the systems engineering approach in Poland and promotion of the INCOSE Polish Chapter in different societies in Poland.

Starshine Academy beta test of the SySTEM Educator Initialization material and method. The effort focuses not on the students but on preparing educators to create excellent learning environments for youth, ages 5 through 16. Educator Initialization detects those who can get beyond teaching to serve as Leaders of Learning about STEM and Systems then encourages them to become an autonomous community of continuous innovation for promulgating the education. Jack Ring leads this project.

As INCOSE UK grows so does our responsibility to members to deliver a professional capability that is based on solid Systems Engineering principles. The aim of this project is, therefore, to define and develop a model of INCOSE that can be used to meet the mission of INCOSE by applying it to INCOSE. Initially, the scope of the project will be limited to providing a model that describes the INCOSE UK Chapter in the form of a Systems Engineering Architecture that will then be disseminated and, where appropriate, rolled out to other INCOSE Chapters.

Software Traceable API Standards: Develop a Process that can be repeated to produce traceable requirements from API standard(s) using software tools and the holistic requirements model. The project goal is to pioneer and transform an oil and gas (O & G) industry standard to a requirements holistic model compatible systems software module. INCOSE Texas Gulf Coast Chapter.

Foundation Board Chair John Snoderly, President of INCOSE 2002-2004, commented that two points impressed The INCOSE Foundation Board the most in reviewing these grant proposals: the breadth of the work and different geographic areas represented. These awards were announced at INCOSE IW in January and we look forward to reporting on the progress of the grant recipients as the year progresses.

Please consider providing a gift to the Foundation when you join INCOSE, renew your membership, and register for an event!

More information

2018 Engineers Week Planning Webinar

Watch this webinar to hear from experienced volunteers, learn about the 2018 Engineers Week theme in the USA, learn of new worldwide outreach resources, and more.

Featured Organizations

International Society for Systems Pathology (ISSP)

A new professional academic research association serving experts in a dozen domains of systems pathology.

More Information

Society of Asian Scientists and Engineers (SASE)

The Society of Asian Scientists and Engineers (SASE) was founded in the United States in November 2007 to help Asian heritage scientific and engineering professionals achieve their full potential. SASE is dedicated to the advancement of Asian heritage scientists and engineers in education and employment so that they can achieve their full career potential. In addition to professional development, SASE also encourages members to contribute to the enhancement of the communities in which they live.

SASE’s mission is to

Prepare Asian heritage scientists and engineers for success in the global business world.
Celebrate diversity on campuses and in the workplace.
Provide opportunities for members to make contributions to their local communities.

SASE membership is open to men and women of all ethnic backgrounds.

The SASE National Conference and Science, Technology, Engineering, and Math (STEM) Career Fair is the largest conference and career fair for Asian Americans in the US.

The SASE Scholarship Program recognizes and rewards deserving SASE collegiate members who demonstrate exceptional academic achievements and leadership through activities and the impact they make on campus and local communities. By awarding these scholarships, SASE helps to cultivate and develop the leaders of tomorrow.

More Information

STEM Education Coalition

The STEM Education Coalition works towards raising awareness in the United States Congress, the Administration, and other organizations about the critical role that STEM education plays in enabling the U.S. to remain the economic and technological leader of the global marketplace of the 21st century. Members of the STEM Coalition believe that our nation must improve the way our students learn science, mathematics, technology and engineering and that the business, education, and STEM communities must work together to achieve this goal.

Core Policy Principles:

STEM education must be elevated as a national priority as reflected through education reforms, policies to drive innovation, and federal and state spending priorities.
STEM education is closely linked with our nation’s economic prosperity in the modern global economy; strong STEM skills are a central element of a well-rounded education and essential to effective citizenship.
Our nation must expand the capacity and diversity of the STEM workforce pipeline to prepare more students for the best jobs of the future that will keep the U.S. innovative, secure and competitive.
Policymakers at every level must be informed about policy issues related to STEM education and their implications for the economy, national security, and continued American leadership in science and technology.
Effective policies to promote STEM education as a national priority should be bipartisan and evidence-based and must be backed up by a strong and united community of stakeholders and advocates in the business, professional, research, and education communities.

More Information

INCOSE Program Management-Systems Engineering (PM-SE) Integration Working Group

For many years, a cultural barrier has been growing between practitioners of systems engineering and of program management. While program management has overall program accountability and systems engineering has accountability for the technical and systems elements of the program, some systems engineers and program managers have developed the mindset that their work activities are separate from each other rather than part of an organic whole.

The leaders of INCOSE and PMI (Project Management Institute) believe this cultural barrier and mindset can and must be overcome and they decided to set-up a Strategic Alliance in 2011 to enhance, foster and enable collaboration between program managers and systems engineers.

A first joint INCOSE-PMI action was a white paper Toward a New Mindset: Bridging the Gap between Program Management and Systems Engineering (Langley, Robitaille & Thomas, 2011). This was followed by a series of works done in partnership with MIT Consortium for Engineering Programme Excellence (MIT CEPE) which paved the road for the creation of a dedicated INCOSE Working Group in 2016.

Charter (briefly)

Purpose –

Identify and promote opportunities associated with the effective integration of the Systems Engineering and Project/Program Management disciplines.
Explore the linkages necessary to create effective integration and collaboration between systems engineers and program managers.
Be the intersection point where systems engineers and program/project managers collaborate and integrate their efforts.

Goals –

Facilitate collaboration between systems engineering and program management communities.
Demonstrate the value of integrating systems engineering and program management to develop better solutions that drive strategic business results and outcomes.
Produce useful deliverables that support effective integration and practice of collaborative systems engineering and program management.
Provide thought leadership on open integration challenges between program management and systems engineering.
Bring external thinking into the systems engineering and program management communities to facilitate thinking outside of the box.
Represent a think tank for free thinking and engagement around critical issues associated with program management and systems engineering.
Draft guidelines and/or influence existing ones (e.g. PMBoK, SEBoK, etc.) based on experience and exchanges on PM/SE integration and collaboration.

Scope –

Our scope encompasses activities relating to defining, capturing, evolving, and communicating PM/SE integration best practices. This may include training material, guideline material, recommendations for industry best practices and standards, and shared output with industry working groups from other organizations.

Additionally, also in scope is joining efforts with other INCOSE working groups such as Requirements, Risks, Lean SE, Agile SE, etc. where appropriate, to ensure subject matter expertise is seamlessly integrated into various aspects of the systems engineering process. Exploration of common problems and/or practices also falls within scope, as wee as fundamentally necessary and sufficient INCOSE-relevant architectural concepts and concept-employment principles that enable any system or process to be agile.

More information

Editor’s Note: SyEN is providing a series of articles concerning the PM-SE Integration initiative. The series started in June 2017.

Conferences and Meetings

For more information on systems engineering related conferences and meetings, please proceed to our website.

Some Systems Engineering-Relevant Websites

Systems Engineering Masters Apprenticeship Program

The Systems Engineering Masters Apprenticeship Program is a 1-5 year program of blended vocational and academic learning at the master’s level, which will develop rounded systems engineer at the INCOSE (International Council on Systems Engineering) practitioner level and who should also be likely to be able to apply for a CEng. The program has been developed under the sponsorship of the Defense Growth Partnership in the UK. The objective of the apprenticeship is to become a systems engineering practitioner with rounded systems engineering knowledge and skills.

http://semap.co.uk/index.html

Top 20 Engineering Web Sites

Engineering is one of the fascinating and adventurous careers to choose from. It is more about the application of scientific knowledge and principles rather than the theories. Engineers like to sharp up their minds and do something creative. We provide some of the websites related to engineering that will be extremely useful for engineering students and professionals as well.

http://durofy.com/top-20-engineering-websites/

Overview of the Systems Engineering Process

Link to a free-to-download .pdf document providing an Overview of the System Engineering process as captured by the North Dakota Department of Transportation. Document outlines objectives of various SE activities along with inputs, outputs, processes and reviews for each of the main phases as captured in the widely used V Model.

https://www.dot.nd.gov/divisions/maintenance/docs/OverviewOfSEA.pdf

The Agile Manifesto Reworked for Systems Engineering

Blog article by Hazel Woodcock outlining changes that can be made to the highly popular Agile manifesto that would better equip the manifesto for Systems Engineering processes. The blog post describes (on a principle-by-principle basis) the reasons why the original Agile Manifesto is not applicable to general SE processes. Open discussion is invited on the blog to encourage process improvement in narrowing down the refined principles for the described SE-adapted process.

https://www.ibm.com/developerworks/community/blogs/07f4f478-c082-4196-8489-e83384d85a70/entry/agile_se_manifesto?lang=en

Managing Requirements

Web Page containing templates for Managing Requirements such as checklists, standards, guidance, plans and project document templates, free to download. The website also contains definitions of requirements management as well as discussions on requirements management techniques and traceability concepts.

http://www.jiludwig.com/Template_Guidance.html

Systems Engineering Publications

New INCOSE Publications and Presentations Library

The Papers & Presentations library is a search engine for the paper presentations made at the annual INCOSE symposia since 2010. For your convenience, links to the corresponding paper on the Wiley website are provided.

Reminder: You need to be an INCOSE member and logged-in to take full advantage of this service. Logged-in members can download the presentations and access the full papers for free. Non-members can still see the paper abstracts on the Wiley site and purchase the full paper if interested.

Second Edition of INCOSE Guide to Writing Requirements

This Guide for Writing Requirements is specifically about how to express textual requirements in the context of systems engineering. The main focus of this Guide is on how to express requirements clearly and precisely once they have been discovered, and in a form convenient for further analysis and implementation, independent of whichever process or Systems Engineering (SE) tool is used to capture and manage the requirements. This Guide defines key terms associated with requirements and characteristics that must be possessed by well-formed requirement statements and sets of requirements. The Guide includes a set of rules for writing requirement statements that, if followed, will result in the requirements having these characteristics. The Guide also includes a set of attributes that can be included with the requirement statements to form a complete requirement expression.

You can obtain the Guide from the INCOSE Store.

The Future of IoT

Leveraging the Shift to a Data Centric World

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 60 December 2017\Books\IoT.jpg$

Image source

Don DeLoach, Emil Berthelson, and Wael Elrifai

Book Description (from the Amazon web site):

The Future of IoT is written for executives and senior managers of both enterprise organizations and technology companies alike to better understand the progression of the Internet of Things; how and why the data from these systems is becoming the most important element of the equation, how to best leverage the data, and the opportunities that lie ahead for those who get it right. It guides the reader through how IoT has evolved from simple closed-loop alerting systems to ecosystems where the carefully orchestrated artifacts of the mountains of IoT data can drive insight and action previously unattainable. For leaders in any organization impacted by the Internet of Things, which is virtually any organization on Earth, this book provides clear insight into how to bolster their effectiveness and likely, their career and personal gratification. The book looks at the underpinnings of the technology world leading up to the Internet of Things, including advances in computing, storage, communications, and sensor technology, as well as the emergence of big data. It then examines certain considerations and impediments to IoT. The central thesis, developed fully in part three, looks at the importance of architecture and data primacy as a key element in leveraging the utility value of IoT data. Last, part four looks at some of the opportunities ahead for those who act to capitalize on these ideas. We worked together to write this book because we really believe that the Internet of Things, if leveraged effectively, not only will impact the bottom line of countless companies, but that it will truly change life on earth as we know it, both for those seeking economic advantages, and for those who, knowingly or not, will simply be able to live life better because of the Internet of Things.

More Information

How Technology Will Impact Our Future

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 60 December 2017\Books\Technology in the Future.jpg$

Image source

Rudy De Waele

Book Description (from the Amazon web site):

Shift 2020 gives you an understanding how technology is going to influence, shape and impact your daily life in the near future. Many different areas of how we will communicate, work and do business together in the immediate future are covered in depth. It’s a collaborative book including foresights by some of the world’s leading experts.

Topics include 3D Printing, AI, Apps, Biotech, Cloud, Connected Living, Consumers, Context, Crowdfunding, Data, Education, Entrepreneurship, Enterprise, Fashion, GreenTech, Health, Hyperconnectivity, IoT / IoE, M2M, Maker Movement, Media, P2P Money, Retail, Robotics, Sensors, Smart Cities, Social Media, Society, Surveillance, Transport, Wearables with global input as well as focused on emerging markets such as BRIC and Sub-Saharan Africa.

More Information

Systems Thinking for Peacebuilding and Rule of Law

$C:\Users\Ralph\Documents\SyEN 2017\SyEN 60 December 2017\Books\SystemsThinking.png$

Image source

Report from the U. S. Institute of Peace

Many peacebuilding interventions seeking to support rule of law get stuck. The reason they get stuck may have little to do with the law and its technical dimensions and more with a tendency to treat certain rule of law systems as if they were orderly, regular, and predictable. In reality, peacebuilding practitioners work with complex systems, namely systems that are disorderly, irregular, and unpredictable. This report draws upon several years of experimentation and research in the field of systems thinking and complexity at USIP. It suggests that practitioners may be better at managing confusion and uncertainty by adopting more flexible approaches as they support change in conflict affected environments.

This report invites peacebuilding practitioners to integrate principals of systems thinking and complexity theory into how they conceive, design, implement, and evaluate interventions. Based on research over the past ten years at the United States Institute of Peace (USIP) and drawing upon literature from other fields–such as organizational development, adaptive leadership, change management, and psychology–the authors argue for more adaptive and flexible approaches in peacebuilding and rule of law reform.

More Information

Product Line Engineering Newsletter

This newsletter provides current information concerning PLE. Some of the world’s largest forward-thinking organizations across a spectrum of industries are leveraging PLE to engineer their competitive advantage through order-of-magnitude improvements in productivity, time-to-market, portfolio scalability, and product quality. Access the newsletter here.

Editor’s Note: The article concerning PLE provided earlier in this issue is authored by Dr. Charles W. Krueger, BigLever Software CEO.

Configuration Management Resources

Gartner^[4] has published a 2017 report that provides extensive resources concerning configuration management.

More Information

Sociotechnical System Safety: Hierarchical Control versus Mindfulness

Gavan Lintern and Peter N. Kugler

Author to whom all correspondence should be addressed:

(email: glintern@cognitivesystemsdesign.net)

Published in Systems Engineering Vol. 20, No. 4, 2017, Wiley Periodicals, Inc.

Abstract

Both the hierarchical control model of organizational processes in a sociotechnical system and organizational mindfulness have been promoted, largely through independent lines of argument, as having potential to improve safety in large-scale sociotechnical systems. We review the arguments to assess the confidence we might place in these claims and to assess whether these views are necessarily incompatible or could be complementary. Our analysis reveals a lack of consistency in the arguments for hierarchical control. It remains unclear whether application of this model to sociotechnical system design will enhance safety or will even degrade it by promoting micromanagement. We conclude that the type of mindfulness that bolsters important safety-related cognitive processes is just what is missing from the hierarchical control model. The safety of large-scale sociotechnical systems with catastrophic potential poses an enormous challenge. A functional model with some hierarchical properties, when complemented with insights relating to organizational mindfulness, offers an innovative way of working toward resolving that challenge.

System: The Shaping of Modern Knowledge

$C:\Users\Ralph\Pictures\For SyEN\System of Knowledge.jpg$

Image source

Clifford Siskin

Book Description (from the Amazon Web site):

A system can describe what we see (the solar system), operate a computer (Windows 10), or be made on a page (the fourteen engineered lines of a sonnet). In this book, Clifford Siskin shows that system is best understood as a genre — a form that works physically in the world to mediate our efforts to understand it. Indeed, many Enlightenment authors published works they called “system” to compete with the essay and the treatise. Drawing on the history of system from Galileo’s “message from the stars” and Newton’s “system of the world” to today’s “computational universe,” Siskin illuminates the role that the genre of system has played in the shaping and reshaping of modern knowledge.

Previous engagements with systems have involved making them, using them, or imagining better ones. Siskin offers an innovative perspective by investigating system itself. He considers the past and present, moving from the “system of the world” to “a world full of systems.” He traces the turn to system in the seventeenth and eighteenth centuries, and describes this primary form of Enlightenment as a mediator of political, cultural, and social modernity — pointing to the moment when people began to “blame the system” for working both too well (“you can’t beat the system”) and not well enough (it always seems to “break down”). Throughout, his touchstones are: what system is and how it has changed; how it has mediated knowledge; and how it has worked in the world.

More information

Systems Engineering Tools News

Integrating Big Data Tools into Your Workflow

Dave Oswill, MATLAB product manager at MathWorks

Technologies such as smart sensors and the Internet of Things (IoT) are enabling vast amounts of detailed data to be collected from scientific instruments, manufacturing systems, connected cars, aircraft and other sources. With the proper tools and techniques, this data can be used to make rapid scientific discoveries and develop and incorporate more intelligence into products, services, and manufacturing processes.

While scientists and engineers have the domain knowledge and experience to make design and business decisions with this data, additional software analysis and modeling tools may be needed to take product differentiation to the next level. Using platforms that supports these big data needs offers scalability and efficiency, while providing companies with a competitive advantage in the global marketplace.

For some potential big data users, gaining access to and actually integrating analytics tools into a workflow may seem like an intriguing, yet daunting task. Fortunately, today’s software analysis and modeling tools have been enhanced with new capabilities to make working with big data easier and more intuitive. With these tools, engineers and scientists can become data scientists by accessing and combining multiple data sets and creating predictive models using familiar syntax and functions.

Accessing Large Data Sets

To efficiently capture and incorporate the benefits of big data, engineers and scientists need a scalable tool that provides access to a wide variety of systems and formats used to store and manage data. This is especially important in cases where more than one type of system or format may be in use. Sensor or image data stored in files on a shared drive, for example, may need to be combined with metadata stored in a database.

In certain instances, data of many different formats must be aggregated to understand the behavior of the system and develop a predictive model. For example, engineers at Baker Hughes, a provider of services to oil and gas operators, needed to develop a predictive maintenance system to reduce pump equipment costs and downtime on their oil and gas extraction trucks. If a truck at an active site has a pump failure, Baker Hughes must immediately replace the truck to ensure continuous operation. Sending spare trucks to each site costs the company tens of millions of dollars in revenue that could be saved if the vehicles were active at another site. The inability to accurately predict when valves and pumps will require maintenance underpins other costs. Too-frequent maintenance is wasteful and results in parts being replaced when they are still usable, while too-infrequent maintenance risks damaging pumps beyond repair. To strike a balance, engineers at Baker Hughes used MATLAB to collect terabytes of data from the oil and gas extraction trucks and then developed an application that predicts when equipment needs maintenance or replacement.

Analyzing, Processing, and Creating Models

As in the case of Baker Hughes, engineers and scientists looking to efficiently capture the benefits of big data need a scalable tool to sort through different formats and understand the behavior of the system before developing their predictive models.

Software analysis and modeling tools can simplify this exploration process, making it easier for engineers and scientists to observe, clean, and effectively work with big data and determine which machine learning algorithms should be used across large datasets to implement a practical model. After accessing the data and before creating a model or theory, it’s important to understand what is in the data, as it may have a major impact on the final result.

Often, when creating a model or theory, the software can help decipher the data and identify:

slow moving trends or infrequency events spread across the data
bad or missing data that needs to be cleaned before a valid model or theory can be established
data that is most relevant for a theory or model

Additionally, big data tools can assist with feature engineering in which additional information is derived for use in later analysis and model creation.

Exploring and Processing of Large Sets of Data

Let’s look at some of the capabilities that can help to easily explore and understand data, even if it is too big to fit into the memory of a typical desktop workstation.

Summary visualizations, such as binScatterPlot (Figure 2) provide a way to easily view patterns and quickly gain insights.

Data cleansing removes outliers, and replaces bad or missing data to ensure a better model or analysis. A programmatic way to cleanse data enables new data to be automatically cleaned as it’s collected. (Figure 3).
Data reduction techniques, such as Principal Component Analysis (PCA), help to find the most influential data inputs. By reducing the number of inputs, a more compact model can be created, which requires less processing when the model is embedded into a product or service.
Data processing at scale enables engineers and scientists to not only work with large sets of data on a desktop workstation, but use their analysis pipeline or algorithms on an enterprise class system such as Hadoop. The ability to move between systems without changing code greatly increases efficiency.

Incorporating Big Data Software for Real-World Solutions

To truly take advantage of the value of big data, the full process – from accessing data to developing analytical models to deploying these models into production – must be supported. However, incorporating models into products or services is typically done in conjunction with enterprise application developers and system architects and can create a challenge because developing models in traditional programming languages is difficult for engineers and scientists.

To alleviate this issue, enterprise application developers should look for data analysis and modeling tools that are familiar to their engineers and scientists. By leveraging certain software analysis and modeling tools, scientists and engineers can explore, process, and create models with big data using familiar functions and syntax, while providing the ability to integrate their models and insights directly into products, systems, and operations. Simultaneously, the organization is being enabled to rapidly incorporate these models into its products and services by leveraging production-ready application servers and code generation capabilities that are found in these tools.

Access to tools that provide scalability and efficiency enable domain experts to be better data scientists and give their companies a competitive advantage in the global marketplace. The combination of a knowledgeable domain expert who has been enabled to be an effective data scientist, along with an IT team capable of rapidly incorporating their work into the services, products and operations of their organization makes for a significant competitive advantage when offering the products and services that customers are demanding.

More Information

Education and Academia

Online Master’s Degree in Systems Engineering at George Mason University, Virginia, USA

This master’s degree program is ideal for engineers who strive to attain technical leadership positions in their organizations. Addressing a broad range of issues relevant to the design, implementation, analysis, and management of systems, this program prepares students for a professional career working with large complex systems of the future. Research activities include both fundamental and applied research, balancing an education in quantitative models and engineering tools with a proper understanding of the systems perspective.

More Information

Caltech (California USA) Opens New Center for Autonomous Systems and Technologies

Caltech’s Center for Autonomous Systems and Technologies (CAST) is an interdisciplinary research center focused on developing autonomous systems that think, act and assist independently, expanding the scope of human possibility to solve problems, as well as the range of exploration in extreme Earth and space environments.

The goal is to improve the ability of drones and robots to think and react independently. The more that happens, the more they will be able to help humans gather big data, respond to disasters and explore space, the deepest parts of the ocean and other unreachable corners of the world.

More Information

Standards and Guides

ISO/IEC TS 24748-6:2016: Systems and Software Engineering – Life Cycle Management — Part 6: System Integration Engineering

From the International Organization for Standards (ISO) web site:

Specifies activities and processes to be implemented for engineering the integration of systems-of-interest throughout the life cycle (systems made of products and/or services; see Note 1),
Provides guidance for the integration process and its relationships to other system life cycle processes as described in ISO/IEC/IEEE 15288,
Specifies the information items to be produced through the implementation of the integration engineering (integration process and its relationships to other system life cycle processes),
Specifies the contents of the information items, and
Provides guidelines for the format of the information items.

More Information

DefinitionS to Close On

Systems Engineering FAQ

Answers by Robert Halligan

PPI and cti News

Goodbye to a Valued Member of Staff

After 8 wonderful years, it is with great sadness that we now say goodbye to Andrew Moerenhout, a very valued member of our team. As we all came to know, Andrew has never shied away from any task that got thrown at him from time to time and before long we realised his tremendous capabilities. We wish Andrew the very best of luck in pursuit of his passion and a new career in Osteopathy.

Keynote Speaker at the INCOSE Italia Conference

INCOSE Italia Conference hosted its annual conference over 23 – 25 November 2017 in Naples, Italy. PPI’s Professional Development Manager, Suja Joseph-Malherbe had the privilege to deliver a keynote on the last day of the conference. The talk was titled, “The leadership imperative and cultivating it.”

Melbourne Year-End Function

On Wednesday, December 6, those of our Melbourne team who were not travelling enjoyed barefoot bowls for our end of year get together. A lot of fun was had and brought out competitive sides.

We’d like to wish you all a SAFE & MERRY CHRISTMAS and a HAPPY NEW YEAR!

We are all looking forward to working with you and achieving great things in 2018.

Upcoming PPI and CTI Participation in Professional Conferences

PPI will be participating in the following upcoming events.

INCOSE IW2018

20 – 23 January 2018

Jacksonville, Florida, USA

INCOSE IS2018

7 – 12 July 2018

Washington, DC, USA

PPI and CTI Events

Systems Engineering 5-Day Courses

Upcoming locations include:

Las Vegas, NV, United Stated of America
Amsterdam, the Netherlands
Melbourne, Australia

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:

Stellenbosch, South Africa
Amsterdam, the Netherlands
Pretoria, South Africa

Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses

Upcoming locations include:

Amsterdam, the Netherlands
Melbourne, Australia
Pretoria, South Africa

Architectural Design 5-Day Course

Upcoming locations include:

Pretoria, South Africa
Adelaide, Australia
London, United Kingdom

Software Engineering 5-Day CoursesUpcoming locations include:

Amsterdam, the Netherlands
Melbourne, Australia
London, United Kingdom

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:

Laurel, MD, United States of America
London, United Kingdom
Las Vegas, NV, United States of America

Kind regards from the SyEN team:

Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com

Dr. Ralph Young, Editor, email: ryoung@ppi-int.com

Suja Joseph-Malherbe, Managing Editor, email: smalherbe@ppi-int.com

Project Performance International

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: contact@ppi-int.com

Tell us what you think of SyEN. Email us at syen@ppi-int.info.

Furthermore, a better word might be “response”, because aspects of the response that do not match the need cannot strictly be called “solution”. Readers are asked to overlook this technicality for now. ↑
SyEN readers may not agree on the distinctions between verification and validation, but for the purposes of this article that is immaterial as long as both are covered! ↑
Eisner, H. Essentials of Project and Systems Engineering Management (3^rd ed.). Hoboken, NJ: John Wiley & Sons, 2008. ↑
Gartner, Inc. is the world’s leading research and advisory company. Gartner provides a suite of services that provides strategic advice and best practices to help clients succeed in their mission-critical priorities. Gartner is headquartered in Stamford, Connecticut, USA, and has more than 13,000 associates serving clients in 11,000 enterprises in 100 countries. For more information, see www.gartner.com. ↑

Recent Editions

PPI SyEN 60

Subscribe to PPI SyEN

PPI SyEN 141

PPI SyEN 140

PPI SyEN 139

PPI SyEN 138

FREE Original SE Articles and Industry News?

MORE About Us