Home » SyEN Newsjournal » PPI SyEN 65

PPI SyEN 65

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 65

In This Edition

1. Quotations to Open On

2. Feature Article

Quality as an Emerging Attribute in Lean Organizations by Rainer Grau

3. Article

The Creation and Evolution of INCOSE BRASIL, by George W. L. Sousa
What is Ethics in Systems Engineering? by René King
What the Future Looks Like for Engineers, by René King
Integrating Systems Engineering Series: Integrating Program Management and Systems Engineering, by Ralph R. Young

4. Systems Engineering News

INCOSE UK Launches a New Interest Group
Reliability Leadership Game Launch
Recommendations for Maintaining Cyber Security after Triton Cyber Security Incident

5. Featured Organization

Software Engineering Decision Support Laboratory

6. Conferences and Meetings

7. Some Systems Engineering-Relevant Websites

8. Systems Engineering Publications

Model-based System and Architecture Engineering with the Arcadia Method
Systems Architecture Modeling with the Arcadia Method: A Practical Guide to Capella
The State of the American Manager: Analytics and Advice for Leaders
International Journal of the Analytic Hierarchy Process
System Dynamics: Soft and Hard Operational Research
Enabling Systems Thinking to Accelerate the Development of Senior Systems Engineers

9. Software Tools Supporting Systems Engineering News

Siemens Teamcenter Product Lifecycle Management
Accertify, Inc. Launches Next Generation of Risk Management Tools

10. Education and Academia

Charles Sturt University (Australia) Named One of the World’s Best Engineering Schools
Developing Systems Engineering Competencies in Undergraduate Students for Industrial Placement

11. Standards and Guides

Best Practices for Using Systems Engineering Standards: ISO/IEC/IEEE 15288, IEEE 15288.1, and IEEE 15288.2

12, Definitions to Close On

System Engineering Competency Framework

13. PPI and CTI News

14. Upcoming PPI and CTI Participation in Professional Conferences

15. PPI and CTI Events

1, Quotations to Open On

“Identify feasible solution alternatives. Pick the best. It’s not space science!”

Robert John Halligan

“Don’t ever settle for average. Average is where the best of the worst and the worst of the best meet.”

James L. Dunn

“Difficult-to-manage relationships sabotage more business than anything else – it’s not a question of strategy that gets us into trouble; it’s a question of emotions.”

John Kotter, Harvard Business School

2. Feature Article

Quality as an Emerging Attribute in Lean Organizations

Rainer Grau

Juropera GmbH

rg@juropera.com

Abstract

Lean and agile organizations are organized as teams. Agile teams act, in well-defined constraints, as autonomously as possible. The team is self-organized and self-responsible for the outcome of the team. The outcome of the team delivers value for users and stakeholders. Since teams are self-responsible for the outcome, this includes the quality definition, verification, and validation of the outcome. A product or system as integration of the outcome of agile teams inherits its quality as a distributed and emerging attribute of its elements – the outcome of the teams. This article discusses the interesting topic concerning how to provide quality assurance within an agile organization without establishing a central quality department.

Introduction

Quality is a frequently misunderstood term. Quality in a product, service (^[1]) or process (2) does not necessarily imply that the product is first-class or expensive. The engineering interpretation of quality is the definition of a set of testable and verifiable requirements. These requirements are derived from quality attributes of a product or process. Although the agile community is skeptical concerning classical definitions, IEEE and DIN/ISO^[2] standards provide a good foundation in understanding quality attributes.

Unfortunately, many companies fail to define requirements based on quality attributes for their products and processes. The author has noted in several situations that it requires a critical issue to bring attention to a particular quality attribute. Examples include severe security issues of systems when identities or user profiles had been stolen by hackers.

Companies interested in providing well-defined quality of their products invest proactively in an activity called “quality assurance”. Quality assurance (QA) is any systematic process of determining whether a product or service meets specified requirements. QA establishes and maintains set requirements for developing or manufacturing reliable products. A quality assurance system is meant to increase customer confidence and a company’s credibility, while also improving work processes and efficiency, and it enables a company to compete better (^[3]).

In regulated markets, the mechanism of standards, regulations, norms and certificates requires that a product must be compliant in order to addresses quality assurance proactively. Assuming that a company understands the term quality and is willing to or must address quality proactively, a company must address how to implement quality assurance effectively.

In classical companies, a central quality department is responsible to define and audit quality assurance means for products and processes. In lean and agile companies this responsibility is moved into autonomous teams. The interesting question is how to assure, test, and verify a well-defined product and process quality when a quality attribute such as security is an emerging attribute – the sum of the outcome of a set of teams plus organizational or process requirements in operative usage.

Understanding quality

Before discussing how to assure, test, and verify well-defined product and process quality, we need to understand the nature of quality. Quality is the level of fulfilment of a well-defined and quantified set of measurable attributes with which a product must comply. An example will clarify:

The response time of a dialog may be complicated. The definition for the quality attribute response time, for example, is: “Given the customer triggers dialog function F of dialog D, the system presents the answer within one second to the customer”. In agile, such a statement is treated as an acceptance criterion for dialog D. The acceptance criteria can be verified by the team in the form of measurements.

A more complicated example is the definition for the quality attribute “confidentiality” (see DIN/ISO 25010 for more information) expressed by two requirements: 1. “The customer payment information data are authorized for access by the customer only”; and 2. “For usage within a payment transaction, the minimal required payment information data set of a customer is authorized in execution of the payment transaction”. This definition of confidentiality is beyond the acceptance criteria level of a single team. Various elements including organizational and process definitions are required to ensure that the defined confidentiality is met. In this article the term emerging quality attribute is used for this type of quality attribute. The concrete definition of an emerging quality attribute is met only as the combination of the implementation outcome of more than one team plus additional organizational and process constraints for operational use that must be ensured by the overall system.

Analyzing the two examples above, a well-defined quality of a product is a combination of the following:

A set of quality attribute definition (= requirements) that can be verified by a team.
A set of emerging quality definitions (=requirements) that requires the synchronized outcome of more than one team.
A set of organizational definitions.
A set of process steps with which a business process must be compliant.

As noted above, emerging quality attributes in classical organizations are validated by a central quality assurance department. Does that imply that even in agile organizations, a central quality assurance organization is required, even if this is contradictory to the agile and lean mindset?

Quality responsibility on team level

The team is the core in an agile development environment. Value generation is the responsibility of multi-disciplinary teams. In Scrum, the role “Product Owner” is, in addition to other responsibilities, responsible to define the quality of the product; and that the outcome of the team as increment of the product meets the defined quality. The team is responsible to build this outcome.

To define quality, an agile team in agile environments has two well-established instruments: acceptance criteria and the “Definition of Done” (DoD). All work within an agile team is executed in the context of a backlog item. A backlog item is a small unit of work. The outcome of an agile team is the sum of the outcome of the work packages managed as backlog items. Acceptance criteria are an essential part of a backlog item. A backlog item specifies the value of the outcome and the acceptance criteria specifying the quality of the outcome. Agile good practices provide template phrases to specify the value and acceptance criteria. For example, the following well-known templates are:

User story (^[4]) template (^[5]) (= the value): As a <role> I want <an action> so that <the rationale of this action> <meets the users’ needs>
Acceptance criteria template (= the quality): Given <the context or required pre-condition> when <the action is carried out> then <the observable or measurable result is achieved>

As noted above, a backlog item typically references a set of acceptance criteria. Acceptance criteria are one important capability in agile environments to verify and validate quality. Actually, one acceptance criterion refers to one well-defined quality attribute. In agile environments, acceptance criteria are often executable test routines, thus building a regression-enabled test suite. Acceptance criteria are a key means to validate quality attributes. The limitation of acceptance criteria is that the validation is limited to those quality attributes that a team influences directly. The example of the quality definition provided above: “Given the customer triggers dialog function F of dialog D, the system presents the answer within one second” can raise an issue for the team in the situation that the development team must use a predefined and standardized technology stack with limitation with respect to the response time of a dialog. In this case, the Product Owner is responsible to identify and clarify this issue outside of the team itself. Possible solutions are to change the quality definition (probably a two-second instead of one-second response time) or to demand an improvement of the technology stack in order to shorten the platform specific response time (which is under the responsibility of another team).

The Definition of Done (DoD) is the second well-established instrument. The DoD holds (in addition to other definitions) the definition of all quality attributes the team can directly influence and validate. The DoD covers all quality attribute definitions that apply to all backlog items equally (or at least to the majority of them). This is not restricted to product quality attributes. Organizational or process quality attributes are addressed as well. For example, with respect to the organizational quality attribute that a specific portion of the documentation must be updated, a compliance record must be created for a certification authority or the source code must be checked in at the end of the day, all test suites must run successfully, and the automatic build process must be able to handle the source change.

The combination of acceptance criteria and DoD represents an essential component of quality assurance in agile environments. The limitation of acceptance criteria and DoD is the restriction to quality attributes a team influences directly. Quality attributes a team influences directly are addressed by the team. It is the responsibility of the Product Owner and the team to define appropriate verification and validation procedures. Typical good practices are automated test suites complemented by data analytics measurements, A/B testing (^[6]), or even manual testing.

Understanding emerging quality attributes

Emerging quality attributes are the result of the collaboration of the outcome of two or more teams and require additional quality assurance means. Verification and validation are beyond the area of accountability of a single team. The outcome of more than one team assembles the emerging attribute. For example, the outcome of several teams, plus technical, organizational, and process definitions, provide the desired level of confidentiality.

A very specific competence is required to identify the requirements, build the elements, and verify and validate an emerging attribute. In the case of confidentiality, a sound security knowledge is the essential competence. In the case of performance, the essential competence most likely is system or enterprise architecture. As we discover from an abstract point of view, an emerging attribute often is related with a competence.

Guilds as an organizational instrument to address emerging quality attributes

Growing and dissemination of competences is a subject of agile frameworks such as Scaled Agile Framework (SAFe), Large Enterprise Scaled Scrum (LeSS) or the Spotify Model by Henrik Kniberg. All of these frameworks recommend establishing some organizational structure to grow, maintain, and disseminate knowledge for relevant competences. Representatives owning and responsible for a specific (set of) competence(s) across multi-disciplined teams form informal groups fostered by the organization. For example, software architects out of all multi-disciplined development teams form the so-called architecture guild, or all procurement experts in different functional areas of the company form a procurement guild. Different frameworks use different terms for “guild” (as used in this article), such as “center of competence” or “interest group”. Guilds are not reflected in the line organization. Rather, guilds are informal structures, either instantiated intentionally by the organization or self-instantiated by a bottom-up initiative of a group of individuals.

Guilds are an important and interesting mechanism to create, institutionalize, and validate quality in scaled agile organizations. Unfortunately, the instrument of guilds has not yet found its way into the operational departments of companies and is restricted to the IT department. Often guilds are treated by management as tea party groups, having fun, and wasting time. With an agile mindset, fostering continuous improvement, guilds are the instrument of choice. Quality guilds are responsible for the following:

Skill acquisition for the related competences owned by the guild.
Feedback loops to the teams in the organization that carry out the competences.
Development, institutionalization, and standardization of good practices, methods, and techniques that implement a competence in the context of the organization.
Dissemination of good practices into the organization.
Consulting and coaching of verification and validation mechanism for artifacts and the outcome of development activities within the organization.

Guilds are an orthogonal structural element in organizations. The core engagement of an employee is within a multi-disciplinary team. The team is as stable as possible over a longer period and is responsible to realize business value for the company. The multi-disciplinary nature of the teams has the drawback that important competences are spread over teams, since the skilled employees of a specific competence are members in different teams. Without a correcting instrument, risks exist that important competences are missed.

Let’s construct an example for a security guild. A security guild is responsible to define authorization and authentication rules and, in many cases, to define standard implementations of these rules and define test procedures that validate the correct usage of the implementations. The implementation of the standards and test procedures is typically performed by a development team.

If we use the confidentiality quality attribute that was mentioned in the introduction to this article, “The customer payment information data are authorized for access for the customer only”, this might include a set of rules as follows:

A customer must authorize by a two-factor authorization to execute a payment transaction.
A customer must authorize by a two-factor authorization to edit payment information in her customer profile.
Customer payment information is encrypted in a way so that only the customer can create, read, change, or delete payment information when authorized to edit her payment information.
Etc.

In addition to these rules, the security guild defines validation procedures, for example, as use cases. Development teams translate these use cases into an integration test that will be executed against a system implementation. It is even possible that the implementation task of an integration test procedure is added as a backlog item to a product backlog. An integration test is a test that verifies the outcome of more than one team by a test procedure. This is where the quality circle is closed – and even the responsibilities for definition and implementation of emerging quality attributes are separated.

Development teams implement the rules in the form of running software (^[7]) or in the form of manual test procedures (^[8]). The teams develop integration tests that verify the use cases defined by the security guild. In agile organizations, this is done collaboratively. Team members of development teams are also members of the security guild, thus closing the feedback circle between definition of quality attributes and implementation of the means for assuring quality. Synchronization between development teams assures that integration test suites that act on the outcome of more than one team exist and are fed by the development teams.

A conceptual agile approach to address emerging quality attributes

Utilizing the ideas discussed above, the following conceptual elements address quality assurance on emerging quality attributes beyond the team level:

Guilds as knowledge owner for a competence area have the responsibility to define the requirements for emerging quality attributes.
Teams implement the requirements following the definitions and guidelines provided by guilds. Typically, more than one team is involved in the implementation of a requirement.
Guilds have the responsibility to define validation procedures to verify the correct implementation of the requirements.

The implementation of the verification procedures depends on the nature of the emerging attribute. Ideally, the verification is an automatic integration or acceptance test. In case the requirements result in the implementation of an operational process, an audit definition of the implemented process is required.

In agile environments, the collaboration between guilds and teams is extensive. Members of guilds are also members of teams. This ensures that definition and implementation of emerging quality attributes goes hand in hand with careful feedback and is based on a continuous information flow.

In the example of the emerging quality attribute of confidentiality, the requirements that specify confidentiality are a set of rules and a set of validation use cases. Additional requirements for emerging quality attributes include optional complementary definition of organizational constraints or (quality) process steps. Guilds coach and support teams to implement the requirements in the form of software, organizational, and process changes.

Using this approach, a company should undertake a discussion concerning which emerging attributes are relevant to the business. The reason is that a company must proactively create, foster, and coach the appropriate guilds responsible for definition and validation procedures of the emerging quality attributes. This aspect may be the most challenging activity in companies. Good sources to start a discussion about what emerging attributes are relevant to the business include issues tracking systems, point of sales, and other touch points that generate direct customer feedback. Modern issue tracking systems like Zendesk (^[9]) allow searching and classifying customer feedback from all customer touch points in a company. This allows identification of the business-critical aspects in service delivery and the opportunity to derive and identify the relevant emerging quality attributes.

Addressing process quality

The quality measures listed above address product quality attributes (reminder: “product” in the meaning of a physical product or an SLA-based service offered to customers). Measures to address the quality of the development process are still missing. In classical companies, either process maturity certifications or internal audit organizations are responsible to define and verify development process quality. Process maturity certifications include CMMI, TQM, ITIL, Spice, PRINCE2, and Standards such as ISO 15505, BS 7850-1:1992, ISO 9000:2015. Since the area of process maturity classifications is a field of its own, it is out-of-scope to discuss value and implementation of maturity models in the context of agile development in this article. However, a way to address and improve process quality is a capability called “retrospectives”. Agile communities make a distinction between a “review” and a “retrospective”. The responsibility of reviews is to validate the quality of the product against defined quality attributes. This is what has been discussed in this article thus far. The responsibility of retrospectives is to validate the quality of the development process and to define and provide continuous improvement opportunities. The responsibility for implementation of the measures is then again given to development teams or guilds.

Scrum (^[10]), for example, addresses the Scrum Retrospective explicitly as the Scrum Event of the Scrum development frame. Since Scrum addresses the development process as applied by one team, additional means are required for an organization with many collaboration teams. As in product quality, emerging quality attributes exist as well for the development process, especially with respect to information flow, communication, and synchronization between teams. Scaling the idea of the retrospective in Scrum, a company must define and institutionalize retrospectives on different levels in the organization. The definition of retrospectives includes the definition of the participating member group, the context of the observed part of the development process, and the target teams and guild(s) as implementation units of corrective measures. Retrospectives are a powerful instrument to address quality assurance and continuous improvement – if applied in a lean manner and focused, as are all other agile instruments.

Investigating existing scaled agile frameworks such as SAFe or LeSS with respect to continuous improvement, retrospective and process quality assurance are not fully effective. SAFe establishes means such as an Agile Project Management Office (Agile PMO) or a Lean-Agile Center of Excellence (^[11]), LeSS addresses continuous improvement (^[12]) on a more abstract and value based level of discussion, leaving it to companies to define concrete good practices.

In summarizing, with respect to current and existing approaches to address emerging quality attributes of the development process, the governance aspect of agile is still under-developed and requires additional research and application.

Summary

The maturity of lean and agile allows product quality to be addressed in all dimensions. Many interacting and complementary good practices exist to establish appropriate measures throughout a company as discussed in this article.

The maturity of lean and agile to address process quality is still under development. Agile maturity models do not yet exist or do not offer sufficient practice experiences to derive evidence. This is a subject for further studies and a topic of keen interest. In particular, the contradictory character of an agile mindset and the perceived need for additional control provide an interesting opportunity for future research and practice improvement.

List of Acronyms Used in this Paper

Acronym Explanation

A/B Testing A/B testing is a way to compare two versions ^[13]

CMMI Capability Maturity Model Integrated

CoP community of practice (or guild)

DIN die international norm

Extrinsic motivation when an activity is done in order to attain some separable outcome

IEEE Institute of Electrical and Electronics Engineers

Intrinsic motivation people’s spontaneous tendencies to be curious and interested

ISO/IEC International Organization for Standardization/International Electrotechnical Commission

ITIL A set of practices that focuses on aligning services with the needs of the business

LeSS An organizational design framework for agile development with Scrum

MMP minimum marketable product

MVP minimum viable product

PMO Project Management Office

PRINCE2 A project management method used and developed by the UK government, widely recognized and used in the private sector worldwide

QA Quality Assurance

SAFe the Scaled Agile Framework

Scrum An agile framework for effective team collaboration applied in the development of complex products

SLA Service Level Agreement

S.M.A.R.T. Acronym for specific, measurable, achievable, results-focused, and time-bound

SPICE Industry-specific standard derived from the new ISO 15504 International Standard (IS) for software process assessments, published by the Special Interest Group Automotive

TQM Total Quality Management

WIP work in progress

Acknowledgement

A sincere thank you to SyEN Editor, Dr. Ralph Young for his extensive and very helpful collaboration with me.

References

BS 7850-1:1992, Total Quality Management (TQM) Guide to Management Principles.

Derby, Ester, Diana Larsen, and Ken Schwaber, Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, August 5, 2006, ISBN-13: 978-0977616640.ISO 15505, Standard for Telecommunications and Information Exchange between Systems.

ISO9000:2015, Quality Management Systems — Fundamentals and Vocabulary complemented by ISO 9001:2015.

ISO 9001:2015, Defines quality management principles including a strong customer focus, the motivation and involvement of top management, the process approach, and continual improvement.

Larman, Craig and Bas Vodde. Scaling Lean and Agile Development. Addison Wesley, 8 Dec 2008. ISBN-13: 978-0321480965.

Kniberg, Henrik, Spotify Engineering Culture (Part I), March 27, 2014, all subsequent parts are as well available at that site: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/.

Reinersten, Donald G. The Principles of Product Development Flow. Celeritas Publishing, 29 May 2009, ISBN-13: 978-1935401001.

Schwaber, Ken. Agile Software Development with Scrum. Prentice Hall, 18 Feb 2002, ISBN-13: 978-0130676344.

Schwaber, Ken and Sutherland, Jeff: The Scrum Guide, Version November 2017: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Young, Ralph R. Project Requirements: A Guide to Best Practices, Chapter 10, The Project Manager’s Role Concerning Quality. Vienna, Virginia USA: Management Concepts, 2006. ISBN-13: 978-1567261691.

3. Article

The Creation and Evolution of INCOSE BRASIL

George W. L. Sousa, PhD

Engeflux Engenharia de Sistemas Ltda

Email: george.sousa@engeflux.com

Abstract

This article provides a brief history of the origins of the Brazilian Chapter of the International Council on Systems Engineering (INCOSE BRASIL). The rationale that led to the creation of an official organization is described, as well as some of the challenges it faced in its early years. The achievement of important milestones is also presented, especially regarding the establishment of Regional Directorates. Although the Chapter is still quite young and relatively small, the difficulties surpassed thus far have led to the evolution of an aggressive growth strategy that is now in progress. Stakeholder expectations are high and so is the potential for expansion nationwide with additional impact for the presence of INCOSE in South America.

Introduction

The history of engineering in Brazil, as in all other places in the world, is rooted in the history of humanity and civilization itself. In addition to the rich legacy of ingenuity created by the people who inhabited its territory for millennia, significant influence from Europeans and other people has been recorded since the 16^th century. In the late 18^th century the Military Institute of Engineering was created in the city of Rio de Janeiro, one of the pioneering engineering schools in the Americas. Since then, the number of engineering academic programs in the country has increased significantly and is currently in the thousands (MEC, 2018), including all engineering specialties.

Various life changing engineering feats are traced directly to this country, including the works of aviation pioneer Alberto Santos-Dumont (as well as an entire aerospace industry that followed), record deep water oil and gas explorations, the creation of the Itaipu Hydroelectric Dam (which for decades ranked as the world´s biggest), the massive country-wide management of clean automotive biofuels and other renewable energy sources, and the evolution of one of the largest and most diverse agricultural ecosystems on the planet, to note a few. Through practice, theory, and systematic experimentation, a significant body of engineering knowledge evolved.

By the late 1990s, a select community of engineers with a systemic mindset initiated involvement with the International Council on Systems Engineering (INCOSE) through various venues, particularly through graduate-level academic work involving international collaboration. These efforts contributed to growing awareness of systems engineering in the country, and nurtured a group of people willing to embrace and evolve a more advanced and integrated systems approach. In the years that followed, many meetings, seminars, trainings, and other gatherings occurred over the country with the help and engagement of many; especially in the city of São José dos Campos area – which has evolved as an aerospace technology center.

A conscious attempt towards establishing an INCOSE Chapter had been born and was quite active despite various difficulties and an initial low adoption rate. Nevertheless, by 2010, a few INCOSE ambassadorships had been issued to residents in Brazil which then established a direct communication channel with INCOSE´s international board of directors. This shared communication enabled a few communities in geographically distant regions of this large country to become aware of each other and connect. The movement towards establishing a Chapter strengthened, and people felt more confident and motivated.

A core group of organized leaders emerged. A more advanced plan was traced. Decisions on desired emergent behaviors, functional, and formal elements were made. Legal aspects and administration were addressed, and by 2012 a group of people came together on the premises of the National Institute for Space Research in São José dos Campos to have a public say in the creation of a professional organization with established principles and bylaws aligned and recognized by INCOSE. This gathering led to a successful outcome. INCOSE BRASIL was then officially established and became the first INCOSE Chapter in Latin America. Later, as a sign of fortunate cosmic conspiration, the three co-founders who led the writing of the original Brazilian Chapter bylaws found out that they were born on the same day of the month: the very same May 11^th of different years!

Creation and Achievements

INCOSE BRASIL was consciously conceived as a national entity, to serve simultaneously as the Brazilian section of INCOSE as well as the Brazilian National Association of Systems Engineers. The idea was to create a single, designated point of contact and a mechanism for coordinating the systems engineering community. The overall concept has been well accepted and is working effectively.

The operational concept was carefully established to be as much as possible an emulation of the international INCOSE organization with the intent to ensure cohesiveness of purpose. The idea was to remove unnecessary administrative barriers that could create incompatibility of procedures or prevent the flow of value in the Chapter operations. For instance, its mission statement was purposefully set as the same as INCOSE´s, and the same classification of member types and overall policies regarding membership management was adopted (INCOSE BRASIL, 2012). Considerations regarding a narrower geographical context and collaboration with the remainder INCOSE international community were incorporated.

In terms of governance, the Chapter was designed to function with a Board of Directors charged with making the executive decisions; a Deliberative Council responsible for nurturing guiding principles, policies and a code of ethics, providing strategic direction and legal infrastructure; a Fiscal Council acting as an internal auditing agent; and a Corporate Advisory Board to organize the participation of institutional members, their voice and expectations.

The first three years of operation tested and refined this structure and saw a membership pool increase from 25 members to 40 members and then stabilizing at this level. By the fourth year of operation the Board of Directors decided it was time to put in place the efforts to establish its Regional Directorates. Regional Directorates are extensions of the National Board of Directors in charge of INCOSE BRASIL´s operations in specific geographical regions of interest. They are a governance component capable of providing a sense of identity and a professional home for communities of individuals.

Regional Directorates were conceived as part of the original bylaws and at that time a decision was made to have cities as the identifying geographical scope, rather than states or other larger geographical regions. The rationale driving this decision was the understanding that although modern remote communication technology is quite advanced and very welcome, there is an essential social component related to camaraderie, stewardship, and pride that emerges through face-to-face interaction. INCOSE BRASIL wanted to promote just that face-to-face based learning and growth while maintaining an overall sense of unity and national and international identity.

With that in mind, at the end of 2016, an effort to implement Regional Directorates was initiated. By the end of 2017, Regional Directorates had been created in seven cities: São José dos Campos-SP, Belo Horizonte-MG, Rio de Janeiro-RJ, Goiânia-GO, Montes Claros-MG, São Carlos-SP and São Paulo-SP. The first phase of expansion was carefully planned so that it could be implemented effectively and efficiently. Figure 1 provides an illustration of the Regional Directorates located in the larger Brazilian and South American context. The intention was to facilitate experimentation and learning concerning how to accommodate and manage an arrangement involving an overarching national Board of Directors and various dispersed semi-autonomous Regional Directorates. In little over a year, the membership level doubled, having currently reached approximately 75 members.

An additional anticipated outcome was confirmed with this experiment. Although certain Chapter products have required centralization and direct coordination from the national Board of Directors (for instance, the editing of the INCOSE BRASIL eNote uniting news from all Brazilian regions), it is at the Regional Directorates levels that many important developments occur. There, people meet face-to-face providing significant value to one another. The core of Regional Directorates production includes different kinds of gatherings and content sharing. As an example, the São José dos Campos-SP Regional Directorate created the Systems Talks where interviews with subject matter experts, typically from the local booming aerospace industry, are recorded and shared via a YouTube channel. This way such knowledge is accessible to all. As another example, the Goiânia-GO Regional Directorate led the creation of a program named Transformation Race through which significant cases of systemic change at the enterprise level were identified, documented, and presented.

Products created at one Regional Directorate become part of the INCOSE BRASIL ecosystem, enriching the Chapter portfolio and serving as references to be adopted by other Regional Directorates. Such collaboration is already taking place, as intended. The original intention, which is being gradually confirmed, is that regional production is to the extent possible shared openly with all members of the Chapter, strengthening the overall system, and inspiring other regions to create their own original productions and proceed in an ever-evolving productive cycle.

Figure 1

Location of Current INCOSE BRASIL Regional Directorates in the South American Context

As this reinforcing cycle manifests its early signs of existence, some additional outcomes can already be perceived in terms of institutional integration. Certain products, especially the Transformation Race, have evolved in collaboration with other professional associations and required INCOSE BRASIL to assume an orchestration role. In this case, over the execution of more than a dozen real case presentations, significant integration has been established with the Association for Business Process Management Professionals (ABPMP), the Project Management Institute (PMI), and more recently also with the System Dynamics Society (SDS). Local industrial and systems engineering academic programs such as the one at the Federal University of Goiás (UFG), as well as the State of Goiás Planning Agency (SEGPLAN), have also become involved. The integration also led to approximation of INCOSE BRASIL to the Brazilian Association of Production Engineering (ABEPRO) as well as the Institute of Industrial and Systems Engineers (IISE).

As these developments at the Regional Directorate levels took place, and as INCOSE BRASIL´s identity got stronger within the larger community, the need to define a mature and professional visual identity became evident. Such a strategic imperative led INCOSE BRASIL to seek marketing and design advice from INCOSE. A joint effort resulted in the development of a logo and other visual identity elements in accordance with the new international INCOSE guidelines. A standard was developed to provide for the identity of the national entity and for the identity of each Regional Directorate in an integrated manner. The idea was to have a unique identifier for each region, and, at the same time, explicitly relate to the national and international identities. The solution developed at INCOSE BRASIL ended up being adopted by INCOSE as one standard directive to other chapters in the world with similar organizational arrangements and needs. Figure 2 provides an illustration of these logos.

Figure 2

National Organization Logo (left) and an Example of one Regional Directorate Logo (right)

The experiences described so far have generated significant learning for the chapter. They contributed to an evolved understanding of the value that INCOSE BRASIL has as an integrated national entity. Chapter leadership, volunteers, supporters and other stakeholders are now quite interested in carefully screening priorities and defining a high-quality plan to guide the use of scarce resources through the next steps in the chapter evolution.

INCOSE BRASIL 2020 Vision

In addition to embracing INCOSE´s overall vision, INCOSE BRASIL has been carefully maturing the understanding of its deployment and the implications in the context of its own operations. Efforts so far have resulted in an INCOSE BRASIL 2020 vision that involves dealing with basic Chapter infrastructure as well as several ambitious goals. By the year 2020 the Chapter expects: (1) to have formally introduced itself in all twenty six states and the federal district of the Federate Republic of Brazil; (2) to be recognized and valued as the authoritative reference for sharing, promoting, and advancing systems engineering in the country; (3) to have the practice of Systems Engineering Professional (SEP) certification known and valued country-wide; (4) to increase its member base in a few orders of magnitude, perhaps achieving the ambitious mark of one thousand members nationally and becoming one of the biggest INCOSE Chapters in the world; and (5) to have acted as a relevant integratory forum for the union of professionals from various fields of knowledge, all making use of a systems approach for solving complex problems.

Conclusions and the Way Forward

INCOSE BRASIL has a clear understanding of the future state it desires to achieve. It is now ready and motivated to tackle new frontiers of challenges, including the mastering of its financial sustainability, so that it can safely engage in more complex undertakings leading to very significant expansion.

Several structuring initiatives are currently being conducted, including: (1) the establishment of its financial governance and the flow of financial resources amongst INCOSE and INCOSE BRASIL, as well as its use across its Regional Directorates; (2) the definition and construction of a high-quality website capable of serving as a country-wide integratory and managerial backbone; (3) the official introduction of INCOSE BRASIL to thousands of engineering academic programs, hundreds of government agencies, as well as hundreds of industrial sector representatives in Brazil; (4) the preparation of a second and much larger phase of expansion of Regional Directorates across the country; and (5) the construction of a stable and well organized communication link with the INCOSE Americas Sector Directorate, to provide strategic alignment at all INCOSE levels and consolidate the Brazilian Chapter as a basis for INCOSE expansion in other countries in South America.

Expectations and motivation are quite high. Very fortunately, such organizational context also appears to be solidly grounded in the real world and constantly corroborated by evidence of success and failure. We intend that INCOSE BRASIL will continue to evolve wisely, nurturing its guiding principles, ethically managing the expectations of its stakeholders, and adequately celebrating every victory while always maintaining a deep sense of appreciation, holism, and respect regarding the challenges ahead.

Acknowledgements

The author wishes to acknowledge the support of Geilson Loureiro, Carlos Lahoz, and Ralph Young in the creation of this article. Their careful review and sensible suggestions have added important value to this text.

References

INCOSE BRASIL. Estatuto – Conselho Internacional de Engenharia de Sistemas – Seção Brasil: 1º Oficial de Registro Civil de Pessoa Jurídica de São José dos Campos-SP, número 23678, folhas 7 a 27. July 2012.

MEC – Ministério da Educação. Instituições de Educação Superior e Cursos Cadastrados. http://emec.mec.gov.br/. Consulted on March 2018.

About the Author

George Sousa is Co-founder and Past President of INCOSE BRASIL. He served as INCOSE BRASIL´s first President-elect in 2012-2013, President in 2014-2015 and in 2016-2017. Previously, he had served as INCOSE Ambassador in Brazil from 2010 to 2012. In 2003 he co-founded and served as first President of the INCOSE Student Chapter of the Virginia Polytechnic Institute and State University (VIRGINIA TECH), an affiliate of the Washington Metropolitan Area Chapter in the United States of America (USA). George co-founded and directs Engeflux Engenharia de Sistemas Ltda, a systems engineering company that promotes systems thinking, system dynamics, and the systems approach for problem solving, and researches and develops enterprise transformation technology. He is a professionally educated and certified Systems Engineer from the Massachusetts Institute of Technology (MIT) and he obtained a PhD degree in Industrial and Systems Engineering from VIRGINIA TECH in the USA, as well as Master of Science and Bachelor degrees in Industrial Engineering from the University of São Paulo (USP)´s São Carlos Engineering School (EESC) in Brazil.

What is Ethics in Systems Engineering?

René King

Project Performance International

Systems engineers (SEs) are involved in the development of communications, power generation, transportation, technology, and other systems in modern society, systems that play an instrumental role in the daily activities of people worldwide. If any of these systems fails, the failure could lead to severe financial, social or environmental impact. Ethical dilemmas arise when there is malpractice in agreements or in the execution of work, such that a company or person may be placed at risk for events leading to this damage.

Systems Engineering (SE) competency involves knowledge, skills, abilities, and attitudes-KSAAs. Part of this dimension is the ethical framework that guides the systems engineers’ actions so that ultimately the actions do more good than harm. SEs have ethical responsibilities in capturing the needs and desires of the stakeholders through defining and managing requirements. This means that SEs have an obligation to ensure that the problem being solved addresses the interests of the customer first, and not those of the systems engineer or the consulting company. In addition, systems engineers typically integrate and oversee the work of people from a multitude of specialties. Systems engineers have the responsibility to take it upon themselves to acquire knowledge and seek competent advice to inform decisions and guide developments.

The INCOSE Code of Ethics stipulates ethical principles such as honesty, impartiality, supporting educational and professional organizations, integrity, and striving to increase competence. These principles result in the following duties of every systems engineer:

guard the public interest and protect the environment and welfare of those impacted on by engineering activities;
accept reasonability for one’s actions and results for engineering work, with an openness to ethical scrutiny and assessment;
proactively reduce unsafe practices;
manage risk using knowledge gained by applying a systems viewpoint through understanding systematic interfaces and experience; and
promote the implementation and understanding of judicious SE measures.

A systems engineer should exhibit personal and professional ethical standards in order to gauge correctly how to respond to situations whereby he or she may become involved in unethical practice or know of people who may placing others in jeopardy. Ethical standards are closely linked to one’s personal integrity, an amalgamation of how one wants to be viewed by others (trustworthiness and reputation) and the internal principles by which one lives. Personal ethics involve serving the customer and being cognizant of how the person treats one’s team members while abiding by one’s values and morals. Professional ethics are demonstrated when a systems engineer acts on something believed to be wrong. Professional ethics amongst employees may stem from the culture of corporate. Companies of course pursue commercial interests. It is the responsibility of the company to put measures in place so that commercial pursuits do not have significant negative impacts on the environment and social well-being. Ethical programs may be set up to foster a culture of sound ethical practice, so that employees are encouraged to act in favor of the greater good for the company and society, and to speak up if others are not doing so.

Upon discovering an activity that one feels is illegal or unjust, it is important to take a step back and analyze the situation. One should always consider several aspects such as the law, one’s motives, and the company’s ethical policies.

The laws of most countries state that as an employee, one should act in the best interests of the employer, including refraining from revealing confidential information. However, it is not required by law to follow through with these guidelines in the event of illegal or immoral behavior. Most professions have societies that offer legal protection or support to employees in the event that they are wrongfully accused of malpractice.

One’s motives behind wanting to “blow the whistle” will shed light on whether to go forward with the ‘ethical’ action or not. If the reason is for some personal financial gain or revenge, clearly this is not good motivation.

The company’s ethical policy is an important consideration before taking action. One thing to bear in mind is that once an issue is reported, regardless of what the policy on ethics is, one’s position in the company may be jeopardized and it may be only a matter of time before one is ousted. Although one may take legal action against this, it is essential to recognize the risk.

So how does one go about solving an ethical problem?

Analyze the situation, taking into account the fact that the activity to be reported may be illegal and that there may be a requirement to legally file a complaint to enforce the law. Sometimes the transgression could be wrong but not illegal, so the next step is to determine what the desired outcome is, for example, to stop the illegal acts, to right the wrong, or to get retribution for the affected parties.
Identify the lessons learned from the past in similar situations to try to understand what happened to people in the various roles in past situations.
Develop alternative decisions and outcomes by thinking about what the options are ranging from saying nothing to reporting the situation within and outside of the organization. With each alterative, determine the possible outcome of going this way and if you can live with the possible consequences of the action. Things to consider include: perception of loyalty, family, friends and finances.
Evaluate the alternatives, through thinking critically about the consequences that will be faced in each of these outcomes. Perhaps it may be helpful to consult a specialist such as an attorney or therapist if there are legal or psychological factors involved.
Make a decision on how to follow through. If you decide to report the issue, gather information and follow correct procedures so that technicalities do not thwart the intent of the action.

What the Future Looks Like for Engineers

René King

Project Performance International

Engineers have always turned products of the imagination into reality through a close relationship with science and technology. Typically this has always been a lagging relationship where engineers make decisions based on the availability and knowledge of technology and science. As the world evolves and the competition between producers for the business of consumers increases, engineers will have to anticipate rather than await changes and developments, as development cycles and product life cycles get shorter and shorter. Although the general future is uncertain, technological innovation will continue at a rapid pace around the world in fields such as energy, medicine, robotics, transportation, and artificial intelligence. As these advances unfold, engineers will play a massive role in the transition to the future as technological products rely on engineering work to be fulfilled.

At the IEEE Vision, Innovation, and Challenges Summit, James Plummer, Professor at Stanford University stated that engineers of the future will differ from those of the past since computers will do more of the work previously done by engineers and jobs will favor those who can do engineering work that computers cannot do. In this competitive environment, setting up students to deal with failure and ill-defined problems from the outset will be most beneficial, as engineers adjust to this fast-paced world and anticipating changes to a greater degree rather than being purely responsive to them. Plummer goes on to say that universities should focus on teaching things that will not become obsolete by the time the student has left university, and that life-long learning in conjunction with a ‘just-in-time’ approach to gaining knowledge, as it becomes necessary, is the way forward. This view is in line with that of the National Academy of Engineering, which makes recommendations regarding how engineering education should evolve by 2020. These recommendations include producing engineers who are lifelong learners and who can adequately define and solve problems^[14]. Plummer suggests that this will be the best response to dealing with rapid market changes.

For these reasons, engineers will be expected to demonstrate strong analytical skills, ingenuity, business and management knowledge, good communication skills, leadership, professionalism, high ethical standards, flexibility, dynamism, resilience, agility and pursuit of lifelong learning (as stated by the National Academy of Engineering). These qualities will be valuable when dealing with the Grand Challenges for the 21^st century to be addressed by engineers as defined by by a group of 40 countries. The Grand Challenges include:

make solar energy economical;
enhance virtual reality;
develop carbon sequestration methods;
provide energy from fusion;
manage the nitrogen cycle;
restore and improve urban infrastructure;
reverse-engineer the brain;
advance health informatics;
provide access to clean water;
engineer better medicines;
engineer the tools of scientific discovery;
secure cyberspace;
advance personalized learning; anf
prevent nuclear terror.

In order to address these challenges, interdisciplinary collaboration between the various engineering fields is required. Therefore, an important question is, what will these respective engineering fields look like? Engineers Australia has created its outline of what they believe each of the engineering areas will be required to focus on over the next few years. A high-level summary of the Engineering Australia view for mechanical, aeronautical, and industrial engineers is presented below^[15]:

Mechanical engineers need to focus on:

designing and building robots to help make the life of humans easier;
providing the workforce with more free time by increasing the automation of tasks;
helping to keep cities clean with autonomous waste management.

Aeronautical engineers need to focus on:

designing and producing aircraft that travel faster and operate on a new type of fuel;
developing propulsion systems that make flying cheaper and safer;
refining technology to allow for vertical takeoff and landing.

Industrial engineers need to focus on:

managing the transition of manufacturing from larger fabrication machines to smaller 3D printing solutions;
distinguishing between tasks that should be automated and tasks that should be human-performed;
being at the forefront of entirely new industries as technology and capability advance.

It is impossible to accurately predict the future. However, in the face of increasing competition, a growing population, and rapidly advancing technology, engineers will need to harness entrepreneurial, technology-based, and people-related skills in order to continue to play their necessary role in the transformation of ideas into solutions.

INTEGRATING SYSTEMS ENGINEERING SERIES

Integrating Program Management and Systems Engineering

by

Dr. Ralph R. Young

This month we provide a summary of Chapter 10, Developing Integration Competencies in People, 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). This is our twelfth article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this new book that took place over a five-year period and has provided new knowledge and valuable insights that will serve to strengthen performance of complex programs. “The Book” is highly recommended as professional development for all systems engineers and is available to members of INCOSE at a discount.

Competency is an underlying characteristic of program management and systems engineering that includes a set of skills, attributes, and knowledge that results in effective performance.

This chapter focuses on building of competencies by addressing the following questions:

What are the individual competencies that program managers and systems engineers should have to lead complex programs to successful outcomes?
How does an organization identify and develop these competencies?
How do organizations integrate the skill sets into effective teaming relationships on a consistent, repeatable basis?

Several recent studies are referenced that report on various dimensions of leadership. From a program management perspective, ethical considerations impact every aspect of a program’s operations. Ethical behavior is foundational to trust; teams do not work without trust. Other dimensions of leadership considered essential are critical thinking, influence, communications, systems thinking, and requirements management.

Leaders must have the ability to create a vision, provide a sense of purpose, and foster productive tension that unleashes creativity. They understand that teams are required to achieve challenging outcomes. In complex project environments, highly experienced systems engineers are required.

Research undertaken for The Book found that unproductive tension can be overcome by applying the following factors:

Develop an integrated career path for program managers and systems engineers.
Promote formal education and training in both disciplines so they can learn from each other.
Recognize the value of multidisciplinary teams – multiple competencies and skills.
Create and communicate an overarching vision of the program – its challenges and goals.
Overcome personal assumptions, listen carefully, and value one another’s experience and knowledge.

A key finding of The Book is that the definition of “integration” should be formalized by each organization. To achieve integration, roles and responsibilities must be clearly defined based on experience and competency.

Another key recommendation is that organizations should develop integrated engineering program assessments. The lack of an integrated planning process was found to be the largest source of unproductive tension in the execution of complex programs. Integrated planning can be inhibited when a program team is pushed to start development prematurely (before technical requirements and components are validated through systems engineering). Detailed performance assessments and evaluations should be required throughout the program.

The presence of emotional intelligence distinguishes outstanding leaders and is linked to strong performance.

Organizations should focus on shared responsibility among individual and organizational competencies rather than search for the “perfect leader” (“hero”).

Creative tension is considered necessary for world-class program execution.

Chapter 10 concludes with three examples of competency models for integration that have proven successful in the training of highly successful teams:

The aviation industry’s Crew Resource Management (CRM) program. Two characteristics of CRM are germane to program management and systems engineering integration CRM training focuses on situational awareness, communications skills, teamwork, task allocation, and decision-making within a comprehensive framework of standard operating procedures.
Having a set of standards is a prerequisite to team-based learning.
Control Theory Talks about the goal daily to keep it at the forefront of team members’ minds.
Reviews performance regularly to ensure information is shared.
Recognizes the value contribution of individual team members. Decision Theory and the Observing, Orienting, Deciding, and Acting (OODA) Loop.
Creative energy is derived from the gap between current reality and a compelling vision.
Creative energy is used to align strategic goals through partnership and teaming efforts that provide benefits for all.

Applying aspects of integration discussed in this chapter, you might consider:

What is a source of creative energy in your organization and how can it be used to release creative energy?
What is systems thinking and how can it be used to better integrate the roles of the systems engineer and the program manager?
Describe three “shared spaces” where systems engineers and program managers can collaborate and drive programs forward?

References

Gallup, Inc. State of the American Manager: Analytics and Advice for Leaders. 2015. Retrieved from www.gallup.com/services/182216/state-american-manager-report.aspx.Goleman, D. “What Makes a Leader?” Harvard Business Review, 76(6), 93-104, November/December 1998.International Council on Systems Engineering (INCOSE). Systems Engineering Competencies Framework 2010-0205. San Diego, CA, 2010.

International Council on Systems Engineering (INCOSE). Pathways to Influence: The Emerging Role of the Systems Engineer in an Increasingly Complex World. A Report on the 2012 INCOSE International Symposium Executive Summit, San Diego, CA USA, 2012.

Kim, Daniel H. “Introduction to Systems Thinking.” Systems Thinking Journal. 1999, by Pegasus Communications, Inc. Available at https://thesystemsthinker.com/wp-content/uploads/2016/03/Introduction-to-Systems-Thinking-IMS013Epk.pdf

4. Systems Engineering News

INCOSE UK Launches a New Interest Group

Aim is to Share Knowledge and Promote Whole Systems Thinking in the Energy Sector

Michael Gainford, a long-standing member of INCOSE UK who works with the Energy Systems Catapult, suggested that INCOSE UK consider creating an Energy Systems Interest Group. Around 50 people from a variety of organizations had expressed interest in participating in the group and 19 attended the inaugural meeting, which took place at the Institute of Directors (IoD) headquarters on 10 April 2018.

Attendees at the meeting elected Michael Gainford as Chair of the group, and Professor Jianzhong Wu of Cardiff University was elected as co-Chair. Tony Byrne of MMI Engineering was elected as Secretary. The group will meet three times a year at different locations around the country.

The objectives of the group are to:

discover the exemplars of systems engineering and systems thinking in the UK energy systems sector;
promote opportunities for sharing best practices within the energy sector; and
find opportunities for bringing best practices from other sectors into the UK energy systems space.

Michael Gainford, Chair of the INCOSE UK Interest Group for Energy Systems, said: “Our ability to employ a systems engineering approach to a given project is, without doubt, directly linked to overall project performance, particularly in more complex settings such as the energy systems space.”

“There are many experts in the energy domain and indeed in systems engineering, but the fundamental purpose of this new Interest Group is to provide an opportunity for the two to come together to greater promote whole systems thinking in the energy sector. This is key if we are to unlock the significant benefits of a decarbonized energy system across the UK, and beyond.”

Kirsty Akroyd-Wallis is the President-elect of INCOSE UK and oversees the various groups. She said: “The members of INCOSE UK are keen to promote systems engineering across all domains, and from our council’s point of view, it is always exciting when a member steps forward to start a new group with clear objectives to engage in a new domain. I would like to wish Michael and the other members of the group every success and look forward to learning of their progress.”

More Information

Reliability Leadership Game Launch

At the 13th annual Reliability conference in Las Vegas from 23-27 April, the Reliability Leadership® game was launched. Terrence O’Hanlon, CEO of Reliabilityweb.com states that organizations approach reliability as a technical product but that the approach fails over 70% of the time. In addition, although $14 billion is spent on leadership development in the US every year, the leadership failure rate is 50% amongst senior executives. This game is designed to put leadership skills in practice by demonstrating the teamwork aspect to handling challenges within an organization. 1 and 2-Day versions of the game are available and will be a main feature at upcoming Reliability and Maintenance Conferences.

More information

Recommendations for Maintaining Cyber Security after Triton Cyber Security Incident

On the 4^th of August 2017, there was a cyberattack on a Triconex safety system which was dubbed TRITON. The safety controller which had triple-redundant safety feature was injected with malware by hackers who clearly have access to instrumentation and specialized knowledge. This was an alert for the industry that end users, standard bodies, government agencies and vendors need to come together to fight the threat of hackers. This incident was a result of multiple cyber security lapses whereby a remote attacker managed to log onto a machine and make changes to the code. This was made possible by an individual who made an error in the design of the code that was not specific to the controller. Although human error enabled this error, this incident has forced the rethinking of security systems worldwide.

Mark T. Hoske, content manager of Control Engineering recommends that individuals and organizations make a commitment to elevate industry standards and exercise transparency. Hoske suggests the following best practices:

Commit to educate by addressing processes and technology with a drive to standardize the best practices
Use common standards across all providers and provide feedback and guidance to whomever is involved
Ensure that there is collaboration by exercising transparency and never assume that processes or information are secure. It is important that there is transparent knowledge of the system so that in the case of an incident, people can figure out what was done and how to correct it.

More information

5. Featured Organization

Software Engineering Decision Support Laboratory

(University of Calgary)

The Software Engineering Decision Support Laboratory (SEDS) improves understanding controlling and managing of the software development process, in different stages of software analysis, design, construction, testing and evolution, with an emphasis on delivering support for all kinds of human decision-making.

More Information

6. Conferences and Meetings

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

7. Some Systems Engineering-Relevant Websites

Agile and Scrum applied to large product development projects

The Agile Manifesto was widely known to be applicable to agile development for small groups. Bas Vodde and Craig Larman became interested in Agile and Scrum for large product developments and combined their experience in Nokia Siemens Networks to create the LeSS Framework. LeSS has been applied to teams ranging 2 to 2500 in size and in a variety of types of products. The site gives access to various learning and training resources related to Agile and Scrum including graphical resources and games developed by Bas and Craig.

https://less.works/resources/graphics/index.html

Kitchen Soap – Thoughts on systems safety, software operations and sociotechnical systems

This is a blog about a range of software, systems, and human factors-related topics including engineering management and cognitive systems engineering. The blog created by John Allspaw contains access to talks, books, and various materials on complex systems and web operations. A useful resource for anyone involved in the above mentioned fields and in web operations or capacity planning, particularly.

https://www.kitchensoap.com/

Systems Engineering & Electronics – Links & Resources

This website is home to Design and Technology Teachers Association (DATTA) Victoria containing a page with access to links and resources on robotics, further study in Systems Engineering, teacher resources, and university project ideas for hand-on approach to problem solving.

http://www.datta.vic.edu.au/content/systems-engineering-electronics-links-resources

8. Systems Engineering Publications

Model-based System and Architecture Engineering with the Arcadia Method

Image source

Jean-Luc Voirin

Book description (from the ELSEVIER Website):

This book describes the fundamentals of the method and its contribution to engineering issues such as requirements management, product line, system supervision, and integration, verification and validation (IVV). It provides a reference for the modeling language defined by Arcadia.

Key features:

Offers a comprehensive examination of systems engineering, including the use of models to support it
Not only yet another book on modeling, but rather a journey in systems engineering, enlightening the use of models to support it
Focuses on solitary modeling tasks while also covering prime collaborations between engineering stakeholders
Examines modeling techniques to capture and share architecture and to early verify it against need and non-functional constraints
Addresses subjects not usually covered by model-based system engineering (MBSE) methods, such as co-engineering with specialties, system/sub-system co-engineering, integration verification and validation
Features a powerful, dedicated tool (Capella)
Covers a range of topics, including an introduction to system engineering issues, an introduction to MBSE, a presentation of the method for beginners and a handy reference manual for advanced users

More Information

Systems Architecture Modeling with the Arcadia Method

A Practical Guide to Capella

Image source

Pascal Rogues

Book description (from the ELSEVIER Web site):

This book is an illustrative guide for the understanding and implementation of model-based systems and architecture engineering with the Arcadia method, using Capella, a new open-source solution.

More than just another systems modeling tool, Capella is a comprehensive and extensible Eclipse application that has been successfully deployed in a wide variety of industrial contexts. Based on a graphical modeling workbench, it provides systems architects with rich methodological guidance using the Arcadia method and modeling language. Intuitive model editing and advanced viewing capabilities improve modeling quality and productivity, and help engineers focus on the design of the system and its architecture.

Key features:

Describes the tooled implementation of the Arcadia method
Highlights the toolset widely deployed on operational projects in all Thales domains worldwide (defense, aerospace, transportation, etc.)
Emphasizes the author’s pedagogical experience on the methods and the tools gained through conducting more than 80 training sessions for a thousand engineers at Thales University
Examines the emergence of an ecosystem of organizations, including industries that would drive the Capella roadmap according to operational needs, service and technology suppliers who would develop their business around the solution, and academics who would pave the future of the engineering ecosystem

More Information

The State of the American Manager: Analytics and Advice for Leaders

Gallup, Inc.

From the Introduction to the Report:

The State of the American Manager: Analytics and Advice for Leaders report provides an in-depth look at what characterizes great managers based on over four decades of extensive talent research. This is a study of 2.5 million manager-led teams in 195 countries, featuring analysis that measures the engagement of 27 million employees. The report examines the crucial link among talent, engagement and vital business outcomes, including profitability and productivity.

Download File of This Report

International Journal of the Analytic Hierarchy Process

$C:\Users\Ralph\Documents\SyEN 2018\SyEN 65 May 2018\SE Pubs\IJAHP_Cover_generic_20162.png$

Image Source

Special Issue Editor

Rozann W. Saaty

From the Web site of the International Journal of the Analytic Hierarchy Process:

The International Journal of the Analytic Hierarchy Process (IJAHP) is a scholarly journal that publishes papers about research and applications of the Analytic Hierarchy Process (AHP) and Analytic Network Process (ANP), theories of measurement that can handle tangibles and intangibles; these methods are often applied in multi-criteria decision-making, prioritization, ranking, and resource allocation, especially when groups of people are involved. The Journal encourages research papers in both theory and applications. Empirical investigations, comparisons, and exemplary real-world applications in diverse areas are particularly welcome.

Any visitor to this site can browse the abstracts but to read the contents and download the PDF files, you need to be a registered user and log in. Registration is free for authors, reviewers, and readers in general, and your contact information will only be used to inform you when a new issue is published. Most importantly, there is no article processing charge for the authors; publications are free of charge since IJAHP production is subsidized by the Creative Decisions Foundation, established in 1996 by Thomas L. Saaty and his wife Rozann Whitaker Saaty with a purpose of educating people in the world to help them make more rational decisions.

More Information

System Dynamics: Soft and Hard Operational Research

$C:\Users\Ralph\Documents\SyEN 2018\SyEN 65 May 2018\SE Pubs\System Dynamics Cover.jpg$

Image Source

Martin Kunc

From the Publisher’s Web Site:

This book published by Springer presents some of the most important papers published in Palgrave’s Journal of Operational Research relating to the use of System Dynamics (SD) in the context of Operational Research (OR). Giving the reader an in-depth understanding of significant features of the research area which have grown over the last 20 years: applications in the management field; methodologies; policies at industry level; and healthcare, this book is an invaluable read for those who do not have any prior expertise in the field. Split into four parts, the collection covers the broad use of SD in the field of management, focuses on the use of modelling in supply chains and at industry level, and presents an analysis of the use of SD in its most promising area, healthcare. Not only does this work provide a detailed overview of the field of SD, but it will also offer vital insights into potential research avenues for the future considering the use of SD as a soft OR and hard OR method.

More Information

Enabling Systems Thinking to Accelerate the Development of Senior Systems Engineers

PhD thesis by

Heidi L. Davidz

Abstract

As engineering systems become more complex, the roles involved in developing and managing such systems also become more complex. Thus, there is increasing interest in educating and training engineering professionals to think more systemically. In particular, there is an increasing need to accelerate the development of senior systems engineers. As new educational degree programs in systems rapidly emerge and as companies scurry to establish systems training programs to meet this need, fundamental questions still remain about how systems thinking develops in engineers. Increased understanding of the mechanisms that develop systems thinking will enable effective and efficient development of senior systems professionals. After reviewing related literature, an exploratory and inductive study was designed to gather data on enablers, barriers, and precursors to systems thinking development in engineers. In a field study conducted primarily in the United States aerospace sector, 205 interviews were conducted in 10 host companies. Senior systems engineers were studied to better understand how they developed systems thinking, and information was collected on company procedures for developing systems engineers. Using interview and survey data, comparisons were made of two control groups and senior systems engineers. (cont.) Proven stellar systems thinkers were also interviewed. To summarize the results, even though systems thinking definitions diverge, there is consensus on primary mechanisms that enable or obstruct systems thinking development in engineers. In order to reconcile the divergent definitions observed, a systems thinking framework, definition, and accompanying conceptual illustration are given. The data show that the primary mechanisms that enable systems thinking development include experiential learning, specific individual characteristics, and a supporting environment. This document defines the research space on this topic and suggests applications for the results. Better understanding of systems thinking development provides a foundation for educational interventions and employee development in systems thinking for engineering professionals across industry, government, and academia.

Definition of Systems Thinking

The author states: “I define systems thinking as the ability to understand technical interdependencies in a system, the ability to understand social interdependencies in a system, the ability to think about feedback dynamics in a system, and the ability to understand multi-level/enterprise dynamics.”

Mechanisms that Enable Systems Thinking Development

The data show that the primary mechanisms that enable systems thinking development include experiential learning, various individual characteristics (one respondent said that these people are “always looking for the bigger picture. They are curious people”), and a supporting environment.

Recommendations include: (1) Provide incentives to promote strong systems thinking, (2) Adjust policies to emphasize experiential learning for systems thinking development, (3) Change acquisition strategy to provide more programs and opportunities for engineers to develop systems thinking, (4) Promote research on the mechanisms for effective systems thinking development, and (5) Encourage systems programs that teach systems skills and systems thinking.

Download the Thesis (PDF)

9. Software support for systems engineering tools news

Siemens Teamcenter

Product Lifecycle Management

One of the basic principles of systems engineering is that it is a life-cycle oriented approach. It therefore follows that this process generates product data of a life-cycle nature and if you are interested in controlling your product data, you need tools that can support it. Those that have been in the manufacturing industry have long known the so-called PLM tools that initially came about to support the manufacturing process and data, but these tools have expanded to really cover the whole of the product life cycle, from requirements analysis all the way to phase-out. One such a tool is Siemens Teamcenter.

Teamcenter enables the user to start with a basic PLM solution that enables design data and simulation management, combining a variety of mechanical computer-aided design (MCAD), electronic CAD (ECAD), software development, and simulation tools from multiple vendors.

Teamcenter further provides integration with the MCAD, ECAD, software development, and simulation tools and processes design teams typically use every day. For the host of formal documentation that normally are generated throughout the product life-cycle, Teamcenter manages documents and technical publications in the same product lifecycle management (PLM) system to keep your product design and documentation aligned with product changes. Teamcenter also provides a common source of BOM information across your organization. Managing and tracking all of the PLM processes allows for focussing people on the right tasks, with the right data, to make the right decisions at the right time.

This short article is only scratching the surface. There are lots more on Requirements Management, Service Lifecycle Management (SLM), Manufacturing Process Management, Supplier Integration, Systems Engineering and the list goes on.

More Information

Accertify Launches Next Generation of Risk Management Tools

Accertify, Inc. has launched a set of machine learning capabilities that include dynamic risk vectors. This technology amalgamates information from a set of various sources in order to identify emerging fraud risks and attacks. Early performance testing of the dynamics risk vectors technology in the airline industry saw an increase of 80% in the amount of fraud prevented within two months and a reduction of40% in manual-reviewing of transactions. The company’s tools have been used for fraud prevention, payment gate solutions and chargeback management for decades by merchants, financial institutions and airlines.

More information

10. Education and Academia

Charles Sturt University (Australia) Named One of the World’s Best Engineering Schools

The Massachusetts Institute of Technology (MIT) commissioned report canvassed opinions from a wide range of international experts, and Charles Sturt University (CSU) was chosen among a small group of universities as an emerging leader in engineering education. It puts CSU’s new engineering program alongside renowned engineering education names such as University College London, Singapore University of Technology and Design and University of Technology Delft.

CSU Engineering is the only Australian Engineering Degree hosted in a business facility. The course started in 2016 and the first Bachelor of Technology/Master of Engineering (Civil Systems) graduates will complete the degree in 2021. The first three semesters are on campus, followed by four years of paid work placements, with students mentored by a diverse academic team drawn from Australia and the world.

The MIT report describes CSU Engineering as creating a ‘new chapter in engineering education’ by offering a radically different approach to undergraduate engineering education. With a focus on human-centered engineering and diverse opportunities, students are able to explore authentic problems using state-of-the-art technology.

CSU’s Master of Networking and Systems Administration develops expertise in the design, implementation and management of computer networks.

There are 37 universities in Australia offering engineering degrees, with 12,000 graduates a year.

More Information

Developing Systems Engineering Competencies in Undergraduate Students for Industrial Placement

Dr. Ella Hubbard

Loughborough University

Email: E.Hubbard@lboro.ac.uk

This paper reports on a project investigating the impact of industrial placements on the development of Systems Engineering competencies. It is widely acknowledged that engineering students can develop valuable transferable skills during industrial experience. This paper goes on to identify a set of Systems Engineering specific and transferable soft skills which students should develop before any industrial experience, in order to make the best out of the opportunities provided to them and also to improve return for the industrial organizations involved. Paper available to members of INCOSE here Note: Users will need to create a Wiley Online Library password that complies with their specifications.

11. Standards and Guides

Best Practices for Using Systems Engineering Standards

ISO/IEC/IEEE 15288, IEEE 15288.1, and IEEE 15288.2

Prepared by

The United States Office of the Deputy Assistant Secretary of Defense for Systems Engineering

Background

The United States Department of Defense (DoD) and the defense industry have found that applying systems engineering (SE) processes and practices throughout the system life cycle improves project performance, as measured by the project’s ability to satisfy technical requirements within cost and schedule constraints. Projects that use effective SE processes perform better than those that do not. Given this knowledge, it is in the best interest of both acquirers and suppliers to ensure that defense acquisition projects use effective SE processes as the core of the technical management effort. In addition, the use of standards in key technical disciplines, such as SE, can enhance project performance and provide a common framework for communicating best practices.

DoD has adopted the voluntary consensus standard ISO/IEC/IEEE8 15288, “Systems and Software Engineering–System Life Cycle Processes,” for use by acquisition projects. The standard establishes a common process framework for describing the life cycle of man-made systems and defines a set of SE processes and associated terminology typical for the full system life cycle, including conception, development, production, utilization, support, and retirement. DoD has also adopted the companion standards IEEE 15288.1, “Standard for the Application of Systems Engineering on Defense Programs,” and IEEE 15288.2, “Standard for Technical Reviews and Audits on Defense Programs,” that define requirements for SE processes, technical reviews, and audits for defense projects. These three standards are referred to collectively as the 15288 Standards.

Purpose

The purpose of the April 2017 Best Practices document is to assist:

• Acquirers in tailoring the 15288 Standards to meet and communicate project needs.

• Acquirers in incorporating appropriate language into a Request for Proposal (RFP) to invoke the standards and express relative importance of the standards in proposal evaluations.

• Offerors in developing their proposals to leverage existing organizational processes, or propose alternative value-added tailoring, to support the RFP requirements and comply with the standards as tailored.

• Acquirers in evaluating an offeror’s ability and commitment to effectively implement SE processes compliant with acquirer’s requirements based on the proposed Systems Engineering Management Plan (SEMP), project plan, master schedule, and past performance.

• Acquirers in monitoring and enforcing a supplier’s compliance with the contract and delivery of the product/service/system.

Overview

To establish a project with an effective SE approach in the competitive environment of most DoD acquisitions, the system acquirer should:

1. Stress the importance of SE within the scope of the overall acquisition.

2. Define the acquirer’s expectations, generally expressed in requirements, for a supplier’s SE processes (outcomes, activities, and/or outputs) and technical reviews and audits.

3. Levy requirements on the supplier, via the contract, to perform effective SE.

4. Ensure the supplier’s SE efforts are appropriately funded and resourced.

5. Ensure a means for the supplier to demonstrate compliance with those requirements.

The 15288 Standards provide one method to define the acquirer’s expectations and requirements for the supplier’s performance of SE processes and technical reviews and audits. Thoughtful and proper use of these standards can enhance communication and understanding between the acquirer and supplier throughout the solicitation process and contract execution.

Acronyms

CDRL Contract Data Requirements List

DAL Data Accession List

ID Identifier

IMP Integrated Master Plan

IMS Integrated Master Schedule

RFP Request for Proposal

SE Systems Engineering

SEMP Systems Engineering Management Plan

SEP Systems Engineering Plan

SOW Statement of Work

TIM Technical Interchange Meeting

Source: Best Practices for Using Systems Engineering Standards

Prepared by the United States Office of the Deputy Assistant Secretary of Defense for Systems Engineering

April 2017

HTML version of document available here

12. Definition to Close On

Systems Engineering Competency Framework

The Systems Engineering Competency Framework was developed in 2010 by INCOSE UK ‘to have a measurable set of competencies for Systems Engineering which will achieve national recognition and will be useful to the enterprises represented by the INCOSE UK Advisory Board’. It provides a common language with which to describe and discuss the competencies that are required to conduct good Systems Engineering. The competencies are consistent with ISO 15288, EIA 632, and the INCOSE Systems Engineering Body of Knowledge (BOK).

In addition to the Systems Engineering Competency Framework document, a “Guide to Competency Evaluation” is available. The PDF and hardcopy have been split into two color-coded parts, the framework itself and Annex A Guide to Competency Evaluation Issue 2. The color-coding provides a quick easy way to cross-reference different areas of the Framework with the Annex. These documents may be purchased at the INCOSE UK store.

More Information

13. PPI and CTI News

SyEN has a new Managing Editor – thank you Suja, welcome René

After two years of stewardship of the final editorial and production side of SyEN, Suja Joseph-Malherbe has handed the Managing Editor baton to René King. Thank you, Suja, for an outstanding job.

René King, a graduate in Mechanical Engineering and current Master’s student at Wits University, Johannesburg, South Africa, recently joined PPI in an engineering role. She has already contributed to Team PPI in the fields of project risk management, the application of systems engineering in the infrastructure sector, systems engineering software tools and the design of submersibles!

Meanwhile Dr. Ralph Young continues as the editorial lynchpin of the SyEN effort. Ralph has earned my never-ending gratitude for his leadership role in securing and editing high standard articles month by month, to which can be added his own excellent articles on Integrating Program Management and Systems Engineering, and his major role in the systems engineering news content of SyEN. Thank you, Ralph, you have a lot to be proud of!

Robert Halligan FIE Aust CPEng IntPE(Aus)
SyEN Editor-in-Chief
Managing Director PPI

SETE 2018

PPI exhibited at SETE in early May. Set in Sydney, Australia’s beautiful and iconic harbor, the SETE (Systems Engineering, Test and Evaluation) conference 2018, combined with the Conference on Railway Excellence (CORE), was a huge success. The conference drew large crowds. Rail in Australia is in a massive growth phase and there is no better time for systems engineering to play a major role in this development. The SETE conference, though smaller in numbers than CORE, benefited from the exposure to those in rail who may not have otherwise attended a stand-alone systems event.

PPI Launches The PPI Academy

Team PPI has just launched an exciting new initiative, the PPI Engineering Academy. PPI has been acutely aware since our formation in 1992 of the need for hands-on application of the tools and techniques that we teach; systems engineering needs to be internalized to become the individual’s and the team’s preferred method of developing systems, small and large, simple and complex. Through this vision, the Engineering Academy Program has been borne. The Academy provides a program for clients that is structured around the delivery of a set of existing PPI courses and the provision of on-site and off-site mentoring in the application of the systems engineering approach. The program uses a project that is related to the business of the client as a vehicle with which to apply the tools and techniques taught in the classroom. Clients are invited to use this program to foster individual, team and company success through a community approach to learning. More information is here.

Upcoming PPI and CTI Participation in Professional Conferences

PPI will be participating in the following upcoming events.

INCOSE IS2018

(Exhibiting)

7 – 12 July 2018 Washington, DC, USA

The International Symposium on Military Operational Research

(Sponsoring)

17 – 20 July 2018

Surrey, UK

Swiss Systems Engineering Day (SWISSED18)
(Sponsoring)

3 September 2018

Zurich, Switzerland

Land Forces 2018

(Exhibiting)
4 – 6 September 2018
Adelaide, Australia

INCOSE Western States Regional Conference

(Sponsoring)

20 – 22 September 2018

Ogden, Utah, USA

INCOSE SA 2018

(Exhibiting & Sponsoring)

3 – 5 October 2018

Pretoria, South Africa

PPI and CTI Events

Systems Engineering 5-Day Courses

Upcoming locations include:

Bristol, UK
Utrecht, the Netherlands

Requirements Analysis and Specification Writing 5-Day Courses

Upcoming locations include:

London, UK

Systems Engineering Management 5-Day Courses

Upcoming locations include:

Pretoria, South Africa
Las Vegas, Nevada, USA

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

Upcoming locations include:

Melbourne, Australia
Pretoria, South Africa

Architectural Design 5-Day Courses

Upcoming locations include:

Pretoria, South Africa
Adelaide, Australia

Human Systems Integration 5-Day Courses

Upcoming locations include:

Melbourne, Australia

CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)

Upcoming locations include:

Amsterdam, the Netherlands
Austin, Texas, USA

Other training available for on-site only include the:

Project Risk and Opportunity Management 3-Day Course
Managing Technical Projects 2-Day Course
Integrated Product Teams 2-Day Course
Software Engineering 5-Day Course

Kind regards from the SyEN team:

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

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

René King, Managing Editor, email: rking@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood, Vic 3134 Australia Tel: +61 3 9876 7345 Fax: +61 3 9876 2664

Tel Brasil: +55 12 9 9780 3490

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.

This article uses the term “product” for any offering of products and/or services to customers. ↑
See for example DIN/ISO 25010, which replaces ISO/IEC 9126 Software Engineering. The fundamental objective of the ISO/IEC 9126 standard was to address some of the well-known human biases that can adversely affect the delivery and perception of a software development project. See https://blog.codacy.com/enterprise-software-a-summary-of-iso-25010-software-quality-model-7100575d6f6 for detail information concerning ISO 25010. ↑
See http://searchsoftwarequality.techtarget.com/definition/quality-assurance ↑
A user story is a specific type of backlog item representing the implementation of a user interaction with a system. ↑
The following blog discusses the advantages of using a user story template: https://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template ↑
A/B testing is a controlled experiment with two variants A and B used in a two-sample hypothesis test approach against a statistically relevant test group. A/B testing is often used in user intensive applications to compare two distinct implementations of a feature offered to users. ↑
This is the recommended approach. ↑
This is the more classical approach, but manual testing is a valid testing approach in agile environments. ↑
See https://www.zendesk.com/ for more information concerning Zendesk. ↑
Scrum is one of the most common agile development frameworks. ↑
See https://www.scaledagileframework.com/lace/ for more information. ↑
See https://less.works/less/adoption/continuous-improvement.html for more information. ↑
See https://www.adobe.com/experience-cloud/topics/ab-testing.html?s_cid=70114000002CaIgAAK&s_iid=70130000000kYe0AAE&sdid=51TC8ZYZ&mv=search&edtamo=true&s_kwcid=AL!3085!3!{creative}!e!{placement}!o!!A%2FB%20Testing&ef_id=V40bFQAAARy@MxqD:20180319114026:s for more information. ↑
For more information on recommendation for the engineer of 2020 by NAE, visit https://www.raisethebarforengineering.org/future-engineer ↑
For other engineering fields visit Engineers Australia’s site: https://www.engineersaustralia.org.au/For-Students-And-Educators/Engineering-Careers/Future-Of-Engineering ↑

Recent Editions

PPI SyEN 65

Subscribe to PPI SyEN

1, Quotations to Open On

2. Feature Article

Quality as an Emerging Attribute in Lean Organizations

3. Article

The Creation and Evolution of INCOSE BRASIL

What is Ethics in Systems Engineering?

What the Future Looks Like for Engineers

INTEGRATING SYSTEMS ENGINEERING SERIES

Integrating Program Management and Systems Engineering

by

4. Systems Engineering News

5. Featured Organization

6. Conferences and Meetings

7. Some Systems Engineering-Relevant Websites

8. Systems Engineering Publications

9. Software support for systems engineering tools news

10. Education and Academia

11. Standards and Guides

12. Definition to Close On

13. PPI and CTI News

PPI SyEN 134

PPI SyEN 133

PPI SyEN 132

PPI SyEN 131

FREE Original SE Articles and Industry News?

MORE About Us