Home » Resources » SyEN Newsjournal » PPI SyEN 44

PPI SyEN 44

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 44

WHAT’S INSIDE:

Quotations to Open On

Executive Summary

Developing systems that function properly in their operating environments can be a long and expensive process. This is true whether the system is a Personal Data Assistant (PDA) intended for use in the commercial sector or a satellite weather sensor in the public sector. The key to successful deployment and operation (i.e. within allocated cost and schedule) lies in the ability of the developer to accurately assess the likelihood of success at the earliest possible stage of the development process – preferably at the requirements stage before actual development begins. Accurate assessment in this context means a quantitative, not qualitative, assessment of the cost and schedule impacts of the risks associated with the development process. Arguably, the most significant risk to a development program (among those which can actually be controlled) is technical risk – particularly related to the maturity of the technology to be employed. It is the assessment of this risk from a systems perspective that this paper addresses.

Within the private sector, the system development process is typically aided by a tightly integrated process from R&D through product deployment. This is true even in the case where multiple companies are involved in the development, due to the fact that the profit motive (i.e. success or failure of the companies as well as the products) provides considerable incentive to the participants to make sure that such assessments are accurate. In spite of this incentive, frequent product recalls attest to the fact that such accuracy is often not the case. There are obviously many companies that have demonstrated phenomenal success in bringing products to market, and while the details of the assessment processes are closely held, they in all probability rely on a systematic process such as the stage gate process to be discussed later in this paper [Cooper, 2003].

Within the public sector, in general, there is a much looser connection between R&D and development. R&D and development are typically performed by different, often unconnected, and sometimes competing organizations from the private as well as the public sector. Although the profit motive may be alive and well within the individual private sector organizations, the absence of an overall profit motive within the public sector dominates the assessment process and makes it even more problematic. Within the U.S. public sector there have been many attempts over the years to simulate the profit motive and/or to develop various methodologies that would provide a more accurate assessment of the risks associated with a given development, which would lead to effective mitigations ensuring successful developments within allocated budgets and schedule. For the most part these have been unsuccessful.

This paper summarizes a number of methodologies developed for determining the readiness of a system to be taken into production, addressing both strengths and weaknesses. While the stage gate process used in many private sector organizations will be discussed in brief, the concentration will be on the myriad of methodologies developed and used in the public sector. These include: System Readiness Levels (SRLs); Technology Readiness Levels (TRLs); Integration Readiness Levels (IRLs); Risk Identification, Integration & ‘ilities (RI3); Advancement Degree of Difficulty (AD²); and Systems Engineering Checklists (SEC). There are a number of possible permutations and combinations of these tools and processes that could be successfully employed to improve accuracy in determining system readiness, but there are a few key points that should be considered in the decision of which tools and processes to use:

• An integrated total system assessment approach should be used that addresses technology, manufacturing, integration, etc. from the system of systems level down to the individual component level;

• Current status should be augmented by a predictive assessment that addresses the combined risk, schedule, and cost to completion;

• While risk and cost assessments are currently undertaken, they are often only loosely connected to each other and often not at all to Technology Readiness Assessments;

• Program risk assessments are typically qualitative in nature (e.g. the risk cube/matrix [NASA, 2007]) and therefore do not contribute substantively to the ability to determine the impact on program cost and schedule;

• Cost risk assessments, while quantitative in nature, typically do not take into consideration technical risks, or at best consider them to be implicitly accounted for, and thus do not adequately represent the cost and schedule impacts attributable to the technical risks.

• A system readiness process should be standardized through the use of tools – this facilitates independent assessments as well as comparisons between programs;

• The use of the tools and processes/methodologies selected should be mandatory: if they are not mandatory, they may never be used and therefore never be improved. Program managers are already faced with so many demands that they will never voluntarily utilize yet another “helpful” process or tool;

• In the end, whatever approach is chosen, there needs to be a balance between “comprehensiveness” and ease of use. It is possible to generate 10,000 or more questions to cover everything imaginable; however, it is impractical from the point of view of the resources available to answer so many questions – and given the lack of omniscience among most engineers and program managers, they still are not likely to capture everything;

In summary, system readiness assessment must rely on the systems engineering process and be performed by the systems engineering community consistently, systematically and most important of all – quantitatively.

Introduction

As was stated in the Executive Summary, the following discussions will focus on methodologies developed for assessing systems developed for the public sector. This is not to say that the private sector could not benefit from incorporating various aspects of the tools and processes discussed – in the end, systematic, common sense approaches are applicable to both.

Within the U.S. federal government, program failures and cost and schedule overruns over the last two decades have made more urgent the need to focus on specific issues in order to improve performance. Initial focus was on Technology Readiness, soon to be followed by Manufacturing Readiness and, more recently, on a renewed emphasis on system engineering, including specifically, integration. In addition, there have been repeated acquisition reforms which also have led to little, if any, improvement. The most recent such reform has resulted in a significant roll-back of Technology Readiness Assessment (TRA) requirements. The impact of this roll-back is yet to be determined, but in all probability it is a fairly safe bet that future TRAs will be less likely to produce accurate assessments.

There is no question that attempts to use immature technology (both hardware and software) and lack of manufacturing capability have significantly contributed to the problems of cost and schedule overruns, as have integration issues, particularly in today’s complex interrelated systems. However, it can be argued that all of these issues have arisen from failures in the system engineering process and, if a solution is to be found, it must be approached from a total system engineering perspective. A summary of tools and processes currently available follows.

Available Tools & Processes

Stage-Gate^®

The Stage-Gate^® process had its origins in a study of how companies bring their products to market – the answer being – not very well! [Cooper, 1976] The Stage-Gate^® process relies on following a systematic approach to bringing products to market by breaking the process into phases, or stages. Each stage in the life cycle has a set of prescribed activities and is preceded by a gate that opens or closes the path to that stage depending upon a set of predetermined criteria. [Cooper, 2003] The concept is simple, the execution is not. It requires discipline, consistency, and rigor to be successful.

Technology Readiness Level (TRL)

Technology Readiness Levels (TRLs) originated in the late 1980’s as a means of reducing schedule slips and cost overruns associated with using immature technology in NASA’s programs [Sadin, et.al., 1989]. TRLs describe the phases in the technology development lifecycle and consequently can be considered as very similar to the Stage-Gate^® process. Technology Readiness Assessment (TRA) uses TRLs to specify the maturity level of the technology being assessed. TRAs can (and arguably should) be performed on a system or even System of Systems basis as well as subsystem and component. This is particularly true in consideration of the fact that using legacy hardware or software in a new system/environment frequently results in technology development. When a TRA is conducted at the system level all issues including integration are addressed. I.e., if a system level prototype is tested in a relevant environment, it must have been integrated first. Two tools exist for standardizing the TRA assessment – the AFRL TRL Calculator and the NASA-AFRL TRL Calculator. The latter calculator is specifically structured to perform assessments as a function of the program Work Breakdown Structure (WBS). It has 259 questions for the nine levels in three categories (hardware, software, and manufacturing). A web-based version of the AFRL TRL Calculator currently under development will also include a WBS capability.

The strength of the TRA approach (when used with a calculator tool) is that it provides a standardized means of making a comprehensive system assessment from the top down as well as from the bottom up. The weakness is that it only provides a status at the time of the assessment and does not address what is required for successful completion.

It should be noted that since April, 2011, the United States DoD uses TRLs as a helpful knowledge-based standard whereas previously the TRLs were required metrics. [TRA Guidance, 2011]

An International Standard on Technology Readiness Level Definitions and their criteria for assessment is under development. [Bilbro, et al, 2011]

Advancement Degree of Difficulty (AD²)

AD² is designed to be done in conjunction with a Technology Readiness Assessment (TRA). The AD² process is focused on determining the “tall tent pole” issues in cost, schedule, and risk that are associated with the various elements (systems, subsystems, components) deemed to be below the desired level of maturity by the TRA. It is structured around the Work Breakdown Structure (WBS) and asks a series of questions regarding the element under investigation concerning whether or not it can be designed, manufactured, tested, or operated. E.g., do you have the necessary models with the requisite accuracy and if not, what is the cost and schedule required to obtain them and what is the risk that they cannot be obtained? The results are portrayed in the form of identifying the weakest link, i.e., greatest risk, highest cost, longest time. AD² is not intended as a replacement for a formal cost analysis nor risk analysis; rather it looks to provide quantified indicators for more detailed examination. The AD² tool currently consists of 57 questions in 5 categories: Design & Analysis, Manufacturing, Software Development, Test, and Operations. Categories may be changed and questions may be changed or additional questions added. The strength of the AD² process is that it is predictive and can (and should) be used from the system of system level down to the component level. The weakness is that it is only as good as the questions asked and they must be refined continually.

U.S. DOD Systems Engineering Checklists

There are 18 System Engineering Checklists covering all program phases intended to supplement the U.S. Armed Services’ individual processes/methodologies. The TRA checklist for example consists of 69 questions in eight areas: Timing/Entry Level, Planning, Program Schedule, Program Risk Assessment, Critical Technologies Identification, TRA Panel, TRA Preparation and Event, and Completion/Exit Criteria. Each question is to be assessed with respect to risk categories of Red, Yellow, Green, Unassigned, or Not Applicable. The strength of the checklist approach as a whole is its comprehensiveness which, as was the case with the UK approach (below), is also one of its weaknesses because of the time required to apply it. The questions are also of a programmatic nature concerning whether or not a process has been completed without regard to how well it was done. The checklist approach also is only a status. While it does make a risk characterization, it does not provide any quantification of what remains to be done. It appears that while these checklists are recommended for DOD as a whole, only NavAir (the developer) makes much use of them.

Risk Identification, Integration, and ‘ilities (RI3)

RI3 is a methodology designed to provide a concise set of questions that highlight key areas that have historically been overlooked, particularly in areas related to the integration of new technologies, and the “ilities.” It is intended to be used in conjunction with formal risk assessment processes, not as a replacement. It consists of 105 questions in nine categories: Design Maturity and Stability, Scalability & Complexity, Integratability, Testability, Software, Reliability, Maintainability, Human Factors, and People Organization and Skills. The questions are formulated in terms of “best practices” and if the answers are negative, the responder is asked to indicate a likelihood of the “best practice” not occurring and the subsequent consequence to the program. The results are captured in a conventional 5X5 risk matrix and in linearized likelihood and consequence charts. It is recommended that the linearized charts be used, due to the stigma associated with having “red” areas in a conventional 5X5 risk matrix which often results in risks being under reported. The strength of the RI3 methodology is that it is applicable to any level – from system of systems to components and that it focuses on issues that have most frequently been missed. The primary weakness of the RI3 method is that when the questions are examined, they are frequently dismissed as being common sense issues which “of course” are already being addressed. This can lead to the methodology being deemed unnecessary and therefore not utilized. Questions, of course, must continue to be refined and if maximum benefit is to be achieved from the methodology, should be incorporated into formalized cost assessments.

System Readiness Level (SRL) (Stevens Institute, U.S.A.)

The SRL in this case is defined through the combination of the TRL of a given technology with the Integration Readiness Level (IRL) of each of the elements with which it will be integrated. The computation of SRL is considered as a normalized matrix of pair-wise comparisons of normalized TRL and IRL. The strength of this approach is that it recognizes that integration plays a major role in successful program completion and offers the opportunity to define a system readiness by a single number. One weakness of this approach is that representing a system readiness by a single number has the unwanted potential for masking major problems. A more limiting weakness is that it requires the use of Integration Readiness Levels which at this point are too ill-defined to result in practical application. This approach provides for status only and does not provide any means of quantifying what is left to be done. Substantial work remains to be done on quantifying IRLs if this methodology is to be successful.

System Readiness Level (SRL) (UK Ministry of Defense)

The UK MOD SRL methodology is an attempt to take a comprehensive look at all aspects of a program. It is used in conjunction with TRL assessments. The SRL self assessment tool has nine top level categories: System Engineering Drivers, Training, Safety & Environmental, Reliability & Maintainability, Human Factors, Software, Information Systems, Airworthiness, and Maritime. Each of these nine areas has a set of questions for each of the nine levels of the SRL for a total of 399 questions. Affirmative answers to a complete set of questions for a given level determines the SRL for that area. The composite SRL is displayed as a matrix of areas against individual SRLs, resulting in a particular signature at a given point in the program. The strength of this methodology is its comprehensiveness, which is also its major weakness: it is incredibly time consuming to perform this assessment and there has been some indication (not confirmed) that the UK MOD has discontinued use of this methodology. It is worth noting that the UK MOD attempted to utilize Integration Readiness Levels (IRLs) and Design Readiness Levels (DRLs) before settling on this approach.

Conclusion

Ensuring that a system is ready for prime time requires performing a quantitative assessment of the risks that are likely to be encountered in the development process. This starts with the identification of technical risks in the areas of technology maturity, software maturity, integration, etc. and continues with assigning cost and schedule impacts associated with making certain that those risks are sufficiently mitigated. This is in contrast to the current practice of using the risk cube in risk management plans. The risk cube is a management depiction that actually hinders true assessments by encouraging qualitative measures that in reality are of little use beyond making program managers feel good (whose programs never have any red areas by definition or by fiat.) I would like to suggest that the Systems Engineering community relegate the risk cube to a dark and dusty corner!

In summary, any of the tools and processes discussed in this paper can be combined and/or tailored to fit the needs of any organization, and their rigorous, systematic use can go a long way towards ensuring that a system is indeed ready for prime time!

Bibliography

Bilbro, James; Dennehy, Cornelius; Desai, Prasun; Holzer, Jenny; Kramer, Corinne; Nolte, William; Widman, Richard; Weinstein, Richard; ” ISO TRL Definitions and Assessment Criteria – Status,” 14th Annual Systems Engineering Conference Hyatt Regency Mission Bay – San Diego, CA October 24-27, 2011.

Cooper, Robert G., “Winning the new product game: an empirical study of successful product innovation in Canada,” Montreal: Faculty of Management, McGill University, 1976.

Cooper, Dr. Robert G., “Winning at Product & Technology Innovation with Stage-Gate^®,” Copyright 2003 Product Development Institute, ” Process for Assessing Technology Maturity and Determining Requirements for Successful Infusion into Programs, NASA Conference, Washington D.C., Sep 16-18, 2003. http://www.stage-gate.com/news_021003.php

NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev 1, 2007

Nolte, William L., Did I Ever Tell You About The Whale – Or Measuring Technology Maturity, Information Age Publishing, 2008.

Ramirez-Marquez, J.E.; Sauser, B.J., “System Development Planning via System Maturity Optimization,” IEEE Transactions on Engineering Management, Vol. 56 Issue: 3 pp. 533 – 548 Aug. 2009

Sadin, Stanley T.; Povinelli, Frederick P.; Rosen, Robert, “NASA technology push towards future space mission systems,” Space and Humanity Conference Bangalore, India, Selected Proceedings of the 39th International Astronautical Federation Congress, Astronautica, pp 73-77, V 20, 1989.

Web Resources

AD2 Tool along with integrated TRL tool available at: http://www.jbconsultinginternational.com
AFRL TRL Calculator is available at:

https://acc.dau.mil/Search.aspx?id=157372&m=6&tfp=1&tfk=1&tfd=1&q=trl

DOD Engineering Checklists are available at:

https://acc.dau.mil/CommunityBrowser.aspx?id=144143&lang=en-US

DoD Technology Readiness Assessment (TRA) Guidance April, 2011, revised 13 May 2011: http://www.acq.osd.mil/ddre/publications/docs/TRA2011.pdf
Integrated TRL/AD² Tool:

http://www.jbconsultinginternational.com

Manufacturing Readiness Level Deskbook:

http://www.dodmrl.com/MRL_Deskbook_V2.01.pdf

Manufacturing Readiness Level Tool: https://acc.dau.mil/CommunityBrowser.aspx?id=18231
NASA TRL Calculator:

https://acc.dau.mil/communitybrowser.aspx?id=25811

NASA TRL Descriptions (NASA Research and Technology Program and Project Management Requirements Appendix J)

http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7120&s=8

NASA Technology Readiness Assessment Process (NASA Systems Engineering Handbook (SP-6105), Appendix G)

http://education.ksc.nasa.gov/esmdspacegrant/Documents/NASA%20SP-2007-6105%20Rev%201%20Final%2031Dec2007.pdf

RI3 Tool and Guidebook are available at: http://www.afit.edu/cse/page.cfm?page=164&sub=95
Stage-Gate^®

http://www.stage-gate.com/

Stevens SRL Tool is under development at:

http://www.systemreadinesslevel.com/

UK MOD Tool is available at: http://www.aof.mod.uk/aofcontent/tactical/techman/index.htm

For more information:

JB Consulting International

4017 Panorama Drive SE Huntsville, AL 35801

Phone: 256-534-6245 Fax: 866-235-8953 Mobile: 256-655-6273 Skype: 256-513-6625 E-mail: jbci@knology.net

Websites: http://www.JBConsultingInternational.com

http://www.linkedin.com/in/jameswbilbro

Systems Engineering News

TASC Report: U.S. Defense Budget Austerity Calls for Renewed Emphasis on Systems Engineering and Integration

A new report published by TASC, Inc. makes the case that systems engineering and integration (SE&I) is essential to manage United States defense budget constraints without jeopardizing national security, and that it would be a mistake to reduce funding for SE&I at the same time that national security programs in general are being reduced.

“Twenty-first century acquisition is more complex than national security acquisitions of the past. Today’s systems need to be more capable and agile than before, and they need to be built more quickly and at less cost,” says Rich Rosenthal, Chief Technology Officer of TASC. “Engineering the big picture to accommodate these demanding requirements is the responsibility of systems engineering.”

More Information http://www.marketwatch.com/story/tasc-report-defense-budget-austerity-calls-for-renewed-emphasis-on-systems-engineering-and-integration-2012-04-23

INCOSE’s UK Chapter is Developing a Series of Guides to Assist System Engineers

Following the success of the Z Guides (see http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications), INCOSE UK has decided to develop a series of “How to Guides”, called the Omega Guides, aimed at members, which provide guidance concerning how to use a variety of tools and techniques that can assist systems engineers in their day to day work. The first two of these guides are now available and a third is in production. If you would like to see an Omega guide on a particular topic or feel that you could help then please contact Hazel Woodcock (series editor) for more details.

More information http://www.incoseonline.org.uk/Program_Files/Publications/Omega_guides.aspx?CatID=Publications

Biggest FIRST(R) Robotics Championship Ever

The FIRST Robotics Competition is an international high school robotics competition organized by FIRST (For Inspiration and Recognition of Science and Technology). Each year, teams of high school students compete to build robots weighing up to 54 kg (120 pounds), not including battery and bumpers, that can complete a task, which changes every year. Teams are given a standard set of parts and the game details at the beginning of January and are given six weeks to construct a competitive robot, that can operate autonomously as well as when guided by wireless controls, to accomplish the game’s tasks.

The 2012 competition, the biggest FIRST Robotics Championship ever featured a U.S. National Basketball Association (NBA) Hall of Famer, a reigning World Series champion, a Pop Superstar, a Celebrity Chef, inventors, and Government officials.

An impressive 12,000 students from 32 countries and their robots compete in the championship, over April 25-28, 2012. Supporters included Avnet; the U.S. Central Intelligence Agency; the International Council on Systems Engineering (INCOSE); and the United States Army’s Rapid Equipment Force.

Three teams from Stuart, FL., Mountain Home, AK, and North Brunswick, NJ won the final showdown, earning the coveted FIRST Robotics Competition Championship Winning Alliance. Several other U.S. and international FIRST student robotics teams earned honors for design excellence, competitive play, research, business plans, website design, teamwork, and partnerships. A not-for-profit organization founded in 1989 by inventor Dean Kamen, FIRST strives to inspire young people’s interest and participation in science and technology.

More than 600 teams from 32 countries competed in the three levels of 2012 FIRST: FIRST(R) LEGO(R) League (FLL(R), grades 4 to 8, 9 to 14-year-olds in the U.S, Canada, and Mexico; 9 to 16-year-olds outside the U.S, Canada, and Mexico); FIRST(R) Tech Challenge (FTC(R), grades 9 to 12, 14 to 18-year-olds); and FIRST(R) Robotics Competition (FRC(R), grades 9 to 12, ages 14-18). In addition, 40 teams of 6 to 9-year-olds participated in the Junior FIRST(R) LEGO(R) League (Jr.FLL(R), grades K-3), showcasing their science and technology smarts in the Jr.FLL World Festival Expo.

In 2010, the 19th year of competition, 1,808 high school teams from Australia, Brazil, Canada, Turkey, the Netherlands, Israel, the United States, the United Kingdom, and Mexico were involved. In 2011, 2,075 teams participated in competitions in the United States, Canada, and Israel.

More Information: http://www.usfirst.org/

INCOSE Spain Chapter Informational Meeting in Madrid

The emerging Spain Chapter of INCOSE is organizing an informational meeting to be held in Madrid at the EOI, C/Gregorio del Amo 6, Madrid, on June 13, 2012. The meeting is open but registration is required.

More information http://www.eoi.es/portal/guest/evento/2068/constitucion-de-international-council-on-systems-engineering-incose-en-espana?goback=.gde_1218517_member_118531287

Ask Robert

Question: What is the difference between a requirement and a specification?

Answer:

In general, a requirement is an order, or demand, or imperative; something that someone requires, a need that must be met. In an engineering context, we have requirements concerning things to be engineered, giving us system requirements, software requirements, and requirements concerning other things. A system requirement, for example, is a characteristic of a system that any system solution is required to possess.

Requirements exist independently of their expression. When a requirement is written down in some language, it becomes a specified requirement.

When a set of specified requirements on a system, for example, is brought together, we have a requirements specification for that system (a system requirements specification). Many public domain and proprietary standards exist for system requirements specifications, software requirements specifications, interface requirements specifications, etc.

Design is solution description. When a specific record is made of design, we have a design specification.

In some industry sectors, for example medical, defense, and aerospace, the word “specification” is normally used to mean “requirements specification”. In other industry sectors, for example white-goods, or construction, the word “specification” is normally used to mean “design specification”. To avoid confusion and error, it is best to be explicit – that is, refer to requirements specification or design specification, as applicable.

Robert Halligan, FIE Aust

Featured Society

USC Center for Systems and Software Engineering (CSSE)

The University of Southern California, U.S.A. (USC) Center for Software Engineering was founded In June of 1993 by Dr. Barry W. Boehm, to provide an environment for research and teaching in the areas of large-scale software design and development processes, generic and domain specific software architectures, software engineering tools and environments, cooperative system design, and the economics of software engineering. The Center took on the mantra of systems engineering in October, 2006.

The Center has established partnerships with leading U.S. public and private sector organizations through their participation in the CSSE’s CSE General Affiliates’ and COCOMO™ II Affiliates’ programs. These organizations help fund the Center’s research.

One of the main goals of the CSSE is to perform research and development of practical software technologies that can aid its Affiliate members in reducing cost, customizing designs, and improving design quality by doing concurrent software and systems engineering, while also meeting the requirements of the CSSE for research topics that will facilitate the training and education of skilled software leaders, armed with Ph.D. degrees.

Evidence of the Center’s success in balancing its own academic needs and the needs of its Affiliates is the fact that, since it’s founding in 1993, the Center has graduated at least 26 individuals with doctorates, while at the same time attracting the continued and on-going support of over two-dozen leading international industrial partners.

More recently, the CSSE has directed considerable effort towards System of Systems Engineering (SoSE).

System of systems (SoS) is a term used to describe a set of related net-centric, sometimes software-intensive systems that are used to provide capabilities that cannot be accomplished by any single system in the set. Each system that is part of an SoS is often referred to as a constituent system. In recent times, SoSs have become more complex and difficult to manage, due in part to the fact that SoS capabilities can conflict with single system requirements and plans and, for systems that belong to more than one SoS, conflicts between the various SoSs’ changes for a given constituent system.

Recent U.S. Department of Defense research has identified how engineering teams have adapted engineering activities to better manage and evolve SoSs. USC CSSE and the SERC SoS research to date has focused on:

Analysis of SoS characteristics (USC-CSSE-2007-717)
Analysis of Lead System Integrator (LSI) role (USC-CSSE-2007-725 and USC-CSSE-2008-803)
SoSE incremental commitment and evolution (ICM .5 version)
Comparison of SoSE management strategies (Lane dissertation)
Cost model to support the estimation of SoSE effort (USC-CSSE-2007-716 and USC-CSSE-2009-503)
Reference SoS to support SoSE research and analysis (CSCI 577b guest lecture for 4/14/2010)
SoS SySML modeling to support SoSE (USC-CSSE-2010-506)
Analysis of SoSE with respect to lean principles (USC-CSSE-2010-504)
SoS test and evaluation (MIT PATFrame and USC-CSSE-2010-507)
SoS engineering artifacts (USC-CSSE-2010-505).

Research continues in each of the above areas. In particular, CSSE is seeking industry partners to further refine and evolve the SoSE cost model. In addition, more recent U.S. DoD-lead research is analyzing SoSE artifacts developed and evolved during the various SoS engineering activities.

More information: http://csse.usc.edu/csse/about/

INCOSE Technical Operations

Two New INCOSE Working Groups Have Been Formed

Future of Energy Working Group

Dr. Alex Pavlak is setting up a Future of Energy (FoE) working group. A paper he will be presenting at IS2012 in Rome this July describes the task, a classic concept definition phase. The proposed effort is unique in two respects. First it will focus on whole systems, the delivery of energy that is cheap safe sustainable and secure. Second it will focus on the destination, the long term goal. Given what is known today, what would post fossil fuel energy systems look like? The product will be technically feasible alternatives. Through publications and lectures, the FoE working group will raise public awareness of these factual constraints on social value choices. If you are interested in participating, please email Dr. Pavlak at alex@pavlak.net

Systems Engineering – Project Management (SE – PM) Working Group

Dave Fadeley, ESEP, is forming a Systems Engineering – Project Management (SE – PM) Working Group with the intent of working with PMI Baltimore chapter members in order to enhance overall program success through the improved integration of practices between the two communities. At the international level, INCOSE and PMI have jointly released a statement in September 2011, “PMI and INCOSE Align to Help Organizations Improve Program Success” that outlines the partnership. They have also produced a white paper, “Toward a New Mindset: Bridging the Gap between Program Management and Systems Engineering”. If you are interested in participating in this new working group, please send Mr. Fadeley an email at dbfadeley@verizon.net

Systems Engineering Tools News

GoedelWorksPortal for System Engineering

Altreonic has announced the availability of GoedelWorks, an internet-based portal for safety and systems engineering. It is made available under a SaaS (Software As A Service) business model.

Based on a formalized approach, GoedelWorks is a technology platform for collaborative systems and safety engineering project delivery. Developed for use by global and distributed teams, GoedelWorks is designed to facilitate how people work together to build systems and products, making project delivery more collaborative, productive, and transparent. One can think of GoedelWorks as an extensible framework that dynamically integrates and synchronizes people, processes, and resources associated with systems engineering development projects. From very small chips to large networked systems, GoedelWorks is represented as a platform that facilitates teamwork and project management.

GoedelWorks aims in particular at safety engineering projects. Therefore, the platform supports not only the project development, but also the development of functional safety engineering processes, allowing them to integrate with the organization specific processes. Using a formalized approach, the team is guided from early requirements through final product release. Every change is recorded and project artifacts (such as those needed for safety certification) are created or updated while performing development.

A first functional safety engineering process flow is aimed at the automotive and related sectors. GoedelWorks achieves this by importing a generic process flow supporting standards including IEC61508, IEC62061, ISO26262, ISO13849, ISO25119, ISO15998, CMMI and automotive SPICE. The latter is the result of a joint project with Flanders Drive, a regional knowledge cluster in the automotive sector. Users can customize these processes and integrate their own processes. Once created, GoedelWorks acts like a wizard and on-line repository, recording any project change.

The GoedelWorks platform enables collaboration among all stakeholders, domain experts, and anyone who plays a role in the successful delivery of the system. A central repository keeps track of all dependencies and project artifacts.

The following graphic facilitates an understanding of the potential use of this tool:

$G:\SyEN\SyEN 44\GoedelWorks.png$

More Information www.altreonic.com

Siemens PLM Software Introduces Teamcenter 9 – Enables Better Decision Making in Product Development

Siemens PLM Software, a business unit of the Siemens Industry Automation Division and a global provider of product lifecycle management (PLM) software and services, has announced the latest release of Teamcenter(R) software, a widely used PLM system. Teamcenter 9 delivers solutions and enhancements across the portfolio in support of Siemens PLM Software’s HD-PLM vision, which was established to help companies make better informed decisions more efficiently and with a higher level of confidence. The Teamcenter 9 release adds a new integrated systems engineering solution and tightens the integration across the unified architecture so companies can make smarter decisions with better visibility into the impact of those decisions. Enhancements across the entire Teamcenter portfolio improve productivity and reduce the total cost of ownership.

More Information http://www.marketwatch.com/story/siemens-plm-software-introduces-teamcenter-9-enables-better-decision-making-in-product-development-2012-04-24

Ryma Licenses Process Impact’s Requirement Templates for FeaturePlan

Ryma Technology Solutions Inc., a company in product management solutions, has announced a partnership with Process Impact that will see the consultancy’s requirements engineering templates integrated into Ryma’s FeaturePlan product management solution. “Defining requirements is a critical step in product development that plays heavily on the success of any release,” said Michel Besner, President and CEO of Ryma. “Through this partnership, customers from Ryma and Process Impact will be able to streamline the process of defining requirements by leveraging comprehensive templates that are integrated into FeaturePlan’s Document Center module, allowing them to create comprehensive market and product requirements documents using analytics from the product database in a greatly reduced timeframe.”

More Information http://www.sfgate.com/cgibin/article.cgi?f=/g/a/2012/04/19/prweb9419169.DTL#ixzz1uJ9StHtn

To register for a webinar: https://cc.readytalk.com/r/qw69ncmspvc5

Product How-To: Taking control of requirements specification for smart energy embedded systems

Visure Solutions, a Spain-based company states that it plays a central role in the requirements context with its Requirements Engineering Lifecycle Solution, IRQA. IRQA is said to be a flexible requirements engineering lifecycle solution capable of streamlining requirements processes, allowing more effective collaboration, increasing quality, supporting requirements capture, analysis, specification, validation and verification, management and reuse. More specifically, with IRQA, embedded systems developers is said to establish and enforce a requirements engineering process that everyone can follow in one single platform. They can engage all relevant stakeholders and achieve collaboration between them. Designers are also able to respond to changes, avoid pitfalls and mitigate risk every step of the way. Finally, they can improve quality through more effective change management and reuse, according to the company.

More Information http://www.eetimes.com/design/smart-energy-design/4370969/Product-How-To–Taking-control-of-requirements-specification-for-smart-energy-embedded-systems

Rational Rhapsody Enlightenment Webinar Series

IBM is offering a series of free informational webinars on IBM Rational Rhapsody for systems engineering or embedded software development. The webinars are over the period June to December, 2012.

More Information http://www-01.ibm.com/support/docview.wss?uid=swg27025140&goback=.gde_3682475_member_117308710

Artisan Studio 7.4 Delivers All New Systems Simulation Plus Additional Modeling Features

Atego™, a world leading software tools and professional services supplier for complex, mission- and safety-critical systems and software engineering, has launched Artisan Studio 7.4, an important new version of its flagship model-driven development tool.

Emphasizing system level simulation, this release includes the optional add-on, Artisan Studio SySim. This new tool enables system engineers to find problems earlier in the design cycle when they are much cheaper to fix. Artisan Studio SySim augments OMG SysML models, making them executable, testable and verifiable. It allows systems engineers to visualize multi-scenario, complex system behavior and combines different execution engines. This first release of Artisan Studio SySim simulates and co-simulates behavior designs in Artisan Studio SysML, Atego Structured Action Language, VB.NET and Simulink.

“We are very pleased to announce the launch Artisan Studio 7.4, with its new and innovative approach to systems simulation,” said Hedley Apperly, Atego’s Vice-President of Product & Marketing. “Artisan Studio SySim’s simulation of SysML models dramatically improves verification, leading to real reductions in overall project cost.”

Artisan Studio 7.4 also incorporates a range of new capabilities including extensions to its IDL3/IDL3+ modeling & generation, model explorer auto-bookmarks, plus user interface enhancements for model versioning and the automation API. With Artisan Studio 7.4 you can now also reconcile sibling sandboxes, refactor state machines and difference the same package used in different models, according to Atego. Finally, the Artisan Studio Publisher now provides HTML package browser export.

More Information http://www.atego.com/pressreleases/pressitem/launch-of-artisan-studio-7.4

Constructive Cost Model for Software Intensive Systems-of-Systems (COSOSIMO)

Efforts by the University of Southern California, U.S.A. (USC) Center for Systems and Software Engineering (CSSE) are underway to develop a Constructive Cost Model for Software Intensive Systems-of-Systems (COSOSIMO).

Today’s need for more complex, more capable systems in a short timeframe is leading more organizations towards the integration of existing systems into network-centric, knowledge-based system-of-systems (SoS). Software and system cost model tools to date such as COSYSMO have focused on the software and system development activities of a single system. As CSSE views the new system-of-systems architectures, it finds that the System of Systems Engineering (SoSE) effort associated with the definition of the overall SoS architecture and then the integration of these system-components is not handled well, if at all, in current cost models. Efforts are currently underway to better understand SoSE effort and to use this information to develop a cost model, COSOSIMO, to estimate this effort.

More Information http://csse.usc.edu/csse/research/COSOSIMO/index.html

Vitech Corporation Releases ‘A Primer for Model-Based Systems Engineering’

David Long, president of Vitech Corporation, announced on May 22, 2012 the availability of the second edition of Vitech Corporation’s A Primer for Model-Based Systems Engineering, written by Long and co-author Zane Scott, Vitech’s vice president of professional services. The book, ISBN #978-1-105-58810-5, is one of the model-based systems engineering (MBSE) references Vitech uses in its training courses and in the Vitech University Program. It is targeted to systems engineering practitioners working for government entities, for private and public companies, and for universities, or anyone interested in learning more about the basics of MBSE.

More information http://www.marketwatch.com/story/vitech-corporation-releases-a-primer-for-model-based-systems-engineering-2012-05-22

Systems Engineering Books, Reports,

Articles and Papers

Systems Thinking and Systems Engineering

College Publications

Series Co-editors: Harold “Bud” Lawson and Jon P. Wade

This series publishes books and proceedings that are related to Systems Thinking or Systems Engineering or both subjects. The series is a cooperative enterprise between College Publications and the School of Systems and Enterprises at Stevens Institute of Technology, USA.

Systems Thinking has grown during the 20^th century into highly useful discipline independent theories and practices. Systems Thinking focuses upon understanding the holistic properties of complex systems and, in particular, the dynamic relationships that arise in the interactions of multiple systems in operation.

Systems Engineering has gained momentum during the latter part of the 20^th century and has led to engineering related practices and standards that can be used in the life cycle management of complex systems. Systems Engineering focuses upon transforming the need for a system into a set of capabilities, requirements, functions or objects, that guides production of products and services that meet the need in an effective manner.

The combination of Systems Thinking and Systems Engineering is of particular interest in establishing the capability to “think” and “act” in terms of systems.

http://www.collegepublications.co.uk/images/sts00001s.jpg

Volume 1:

A Journey Through the Systems Landscape

Harold ‘Bud’ Lawson

978-1-84890-010-3

http://www.collegepublications.co.uk/images/sts00002s.jpg

Volume 2:

A Discipline of Mathematical Systems Modelling

Matthew Collinson, Brian Monahan, David Pym

978-1-904987-50-5

A Journey Through the Systems Landscape – Harold ‘Bud’ Lawson

Review from the publishers:

5.0 out of 5 stars A must read for systems engineering professionals and systems thinkers, March 9, 2012

We finally have a book on Systems Thinking that a systems engineer can relate to. Harold `Bud` Lawson has written an exceptional book that provides a holistic view of the systems landscape.

The journey through the systems landscape exposes the paradoxes in the world of system development. The pursuit of solutions in response to problems and opportunities are often conflicted. Narrowly defined boundaries of a system, or problem, result in overly restrictive problem descriptions. Systems’ thinking provides a practical framework for thinking outside these restrictive processes and to think and act in a holistic manner that is conscience of the extended system and its implications. Having a comprehensive view of complex system problems and opportunities is the single most important transitional step towards building a learning organization that distinguishes itself from its competitors. We refer to this as systems thinking.

Lawson offers a practical rubric for incorporating Systems thinking into the organizational problem solving process. Systems’ thinking fosters a holistic approach to problem solving which is attentive to all stakeholder needs that would otherwise go unnoticed and lead to unintended consequences. Lawson reminds the reader that organizations are themselves cybernetic systems. Enterprises use people, process, and tools to solve problems. How well these elements mesh are influenced by many interdependent factors that are easily overlooked and often lead to systematic shortfalls.

Lawson provides expert insights into the differences between Data, Information, Knowledge and Wisdom. The reader cannot help but be reminded of war stories where individual knowledge is not automatically understood at the team level. Lawson illustrates how Systems’ thinking offers insight into building a learning organization that is equipped to deal with system complexity and the management of information in a changing environment.

I give the book an outstanding rating because it gives the reader a comprehensive overview of systems thinking and supporting literature to extend ones understanding of problem solutions and opportunities in the broader context of social systems.

Why New Systems Fail

(Revised Edition)

Phil Simon

$G:\SyEN\SyEN 44\New Folder\81jEvhKNb8L._SX320_SY240_CR0,0,0,0_[1].jpg$

Published by: Course Technology, a part of Cengage Learning

ISBN: 978-1-4354-5644-0
Publication Date: February 23, 2010
Binding(s): Softcover

Abstract: (from Amazon.com)

A Fortune 500 manufacturing company spent millions attempting to implement a new enterprise resource planning (ERP) system. Across the globe, a 150-employee marketing firm built and tried to implement a proprietary customer relationship management (CRM) system. For two very different companies doing two very different things, the outcomes were identical. In each case, the organization failed to activate and utilize its system as initially conceived by senior management. And these two organizations are hardly alone. On the contrary, research indicates that more than three in five new IT projects fail. Many miss their deadlines. Others exceed their initial budgets, often by ghastly amounts. Even systems activated on time and under budget often fail to produce their expected results and almost immediately experience major problems. Although the statistics are grim, there is at least some good news: these failures can be averted. Organizations often lack the necessary framework to minimize the chance of system failure before, during, and after beginning IT projects.

Why New Systems Fail provides such a framework, with specific tools, tips, and insight from the perspective of a seasoned, independent consultant with more than a decade of related experience. The book examines in great detail the root causes of system failures. Detailed case studies, examples, and lessons from actual system implementations are presented in an informative, straightforward, and very readable manner. More than a theoretical or technical text, this book offers pragmatic advice for organizations both deploying new systems and maintaining existing ones.

The book focuses on the largely neglected topic of buying and installing large, complex software packages from third-party vendors.

Editor’s note: This book has a rating of 4.9 out of 5 stars based on reviews by 27 readers.

More Information http://www.amazon.com/Why-New-Systems-Fail-Successful/dp/1435456440/ref=sr_1_1?s=books&ie=UTF8&qid=1336507516&sr=1-1

The Human and Organizational Causes of the Gulf of Mexico Blowout

Andrew Hopkins

Published by:

FutureMedia Pty Limited
3rd Floor
75 King Street
Sydney NSW 2000

Ordering Information: http://www.futuremedia.com.au/order.cfm?id=267&type=PRODUCT&enq=

Publication Date: May 25, 2012

Abstract:

On 20 April 2010, a huge floating drilling rig, the Deepwater Horizon, had just completed drilling an ultra-deep well in the Gulf of Mexico when it suffered a blowout. The subsequent explosions and fire led to the loss of 11 lives, the sinking of the rig, and untold damage to the environment and to the livelihood of Gulf residents.

In this, his latest book – Disastrous Decisions: The Human and Organizational Causes of the Gulf of Mexico Blowout – leading disaster analyst, Professor Andrew Hopkins, takes the reader into the realm of human and organizational factors that contributed to this disaster, going beyond all previous commentary on this topic. He acknowledges that it is important to know what people did, but even more important to know why they did it.

The decision-makers invariably thought they were doing the right thing, when in fact their decisions were taking them, a step at a time, on a path to disaster. This book, therefore, attempts to “get inside the heads” of decision-makers and understand how they themselves understood the situations they were in. It also seeks to discover what it was in their organizational environment that encouraged them to think and act as they did.

Hopkins provides a sophisticated analysis of the accident that first identifies a series of critical defenses that failed and then goes on to explain why they failed. Disastrous Decisions: The Human and Organizational Causes of the Gulf of Mexico Blowout is an essential reference for all work, health and safety professionals.

Contents of the April 2012 Issue

Systems Engineering, The Journal of INCOSE

April 2012

Volume 15, Issue 1

Note: Access to INCOSE member resources and the searchable member directory is provided by using an INCOSE Connect account that provides Collaboration Workspace for the INCOSE Community. See https://www.incose.org/cc_orders/joinINCOSE.cfm for information concerning how to access INCOSE Connect.

Requirements management within a full model-based engineering approach (pages 119–139)

Yves Bernard

Article first published online: 15 NOV 2011 | DOI: 10.1002/sys.20198

Constructing a general framework for systems engineering strategy (pages 140–152)

Clement Smartt and Susan Ferreira

Article first published online: 10 OCT 2011 | DOI: 10.1002/sys.20199

Sensitivity analysis for multi-attribute system selection problems in onshore Environmentally Friendly Drilling (EFD) (pages 153–171)

O.-Y. Yu, S. D. Guikema, J.-L. Briaud and D. Burnett

Article first published online: 15 NOV 2011 | DOI: 10.1002/sys.20200

An empirical methodology for human integration in the SE technical processes (pages 172–190)

Nicholas Hardman and John Colombi

Article first published online: 13 FEB 2012 | DOI: 10.1002/sys.20201

A systems framework for distance learning in engineering graduate programs (pages 191–202)

Adedeji B. Badiru and Rochelle R. Jones

Article first published online: 15 NOV 2011 | DOI: 10.1002/sys.20202

Overcoming barriers to transferring systems engineering practices into the rail sector (pages 203–212)

Bruce Elliott, Anne O’Neil, Clive Roberts, Felix Schmid and Ian Shannon

Article first published online: 15 NOV 2011 | DOI: 10.1002/sys.20203

Risk to cyberinfrastructure systems served by cloud computing technology as systems of systems (pages 213–224)

Yacov Y. Haimes and Clyde C. Chittister

Article first published online: 9 FEB 2012 | DOI: 10.1002/sys.20204

System-Aware Cyber Security architecture (pages 225–240)

Rick A. Jones and Barry Horowitz

Article first published online: 13 FEB 2012 | DOI: 10.1002/sys.21206

INCOSE INSIGHT

INSIGHT is the newsletter of International Council on Systems Engineering. It is published four times per year (January, April, July, and October). INSIGHT features status and information about INCOSE’s technical work, local chapters, and committees and boards. Additionally, related events, editorials, book reviews, trends, and how-to-do articles that are pertinent to the many aspects of a systems engineer’s job are also included, as space permits.

The April 2012 Issue is available on INCOSE Connect at https://connect.incose.org/INSIGHT%20Library/vol-15-issue-1.pdf

Following is the Table of Contents for this issue:

From the President

Special Feature – Meet the INCOSE Authors

Forum

Getting Past Face Value

Technical Operations

INCOSE Working-Group Awards Presented at the

2012 International Workshop

Systems and Software Engineering Standards for

Very Small Entities

Papers and Posters for the 2012 International Symposium:

A Great Variety of Topics

Ontology and Systems Engineering

INCOSE Operations

INCOSE’s Finances and Operations: Review of 2011

INCOSE Certification Reaches a Milestone

INCOSE Certification Agreements Signed

INCOSE Events

Green Growth and Systems Engineering in South Korea

17th Annual Conference of the International Test and

Evaluation Association

Reflections from the 2012 International Workshop

INCOSE Foundation

INCOSE Spotlight

In Memoriam

William W. Schoening

Book Reviews

Final Thoughts

Challenges in Complex Systems Science

The Cornell University Library provides a paper of great interest and importance.

FuturICT foundations are social science, complex systems science, and ICT. The main concerns and challenges in the science of complex systems in the context of FuturICT are laid out in this paper with special emphasis on the Complex Systems route to Social Sciences. This include complex systems having: many heterogeneous interacting parts; multiple scales; complicated transition laws; unexpected or unpredicted emergence; sensitive dependence on initial conditions; path-dependent dynamics; networked hierarchical connectivities; interaction of autonomous agents; self-organisation; non-equilibrium dynamics; combinatorial explosion; adaptivity to changing environments; co-evolving subsystems; ill-defined boundaries; and multilevel dynamics. In this context, science is seen as the process of abstracting the dynamics of systems from data. This presents many challenges including: data gathering by large-scale experiment, participatory sensing and social computation, managing huge distributed dynamic and heterogeneous databases; moving from data to dynamical models, going beyond correlations to cause-effect relationships, understanding the relationship between simple and comprehensive models with appropriate choices of variables, ensemble modeling and data assimilation, modeling systems of systems of systems with many levels between micro and macro; and formulating new approaches to prediction, forecasting, and risk, especially in systems that can reflect on and change their behavior in response to predictions, and systems whose apparently predictable behavior is disrupted by apparently unpredictable rare or extreme events. These challenges are part of the FuturICT agenda.

The authors are Maxi San Miguel, Jeffrey H. Johnson, Janos Kertesz, Kimmo Kaski, Albert Díaz-Guilera, Robert S. MacKay, Vittorio Loreto, Peter Erdi, and Dirk Helbing

More Information http://arxiv.org/abs/1204.4928

Conferences and Meetings

Conference Title (use SyEN Conference Titles)