Dear Colleague,

SyEN, an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at www.ppi-int.com.

Systems engineering can be thought of as the problem-independent, and solution/technology-independent, principles and methods related to the successful engineering of systems, to meet requirements and maximize value delivered to stakeholders in accordance with stakeholder values.

If you are presently receiving this newsletter from an associate, you may elect to receive the newsletter directly in future by signing up for this free service of PPI, using the form at www.ppi-int.com. If you do not wish to receive this SE eNewsletter, please reply to this e-mail with “Remove” in the subject line, from the same email address. Your removal will be confirmed.

We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email to: contact@ppi-int.com.

What’s Inside:

Featured Article

Cognitive Work Analysis & Cognitive Systems Design – Gavan Lintern

Handling the Complexity of Large, Technology-based Business Ventures – Erik W. Aslaksen

… READ MORE

Systems Engineering News

Graph-Based Tools Contest 2009: Call for Cases Reforming US Weapon Systems Acquisition

PMI Opens Request for Sponsored Research Proposals DHS (U.S.A.) to Establish New Research Centers

University of Maryland, Baltimore County’s Engineering Management & Systems Engineering Info Session, April 15, 2009

CALL FOR PAPERS: IEEE Transactions on Industrial Informatics

… READ MORE

Featured Society

NDIA Systems Engineering Division

… READ MORE

INCOSE Technical Operations – Resilient Systems Working Group Systems Engineering Software Tools News

Artisan Software Tools: Artisan announces Artisan Workbench Geensys announces Reqtify 2009-1a

Cassbeth Releases a New Version of the Specification Analysis Tool (SAT)

LDRA TBreq v3.0 Launches Next-Generation Requirements Traceability Automation Sparx Updates Enterprise Architect to 7.5

ParaMagic™ plugin 16.0 is Released by No Magic News from Vitech

… READ MORE

Systems Engineering Books, Reports, Articles and Papers

System of Systems Engineering

Soft Computing Based Modeling in Intelligent Systems Business Object Modeling – an Introduction

Thinking in Systems: A Primer

Discovering Requirements: How to Specify Products and Services Requirements Engineering for Software and Systems

The Foundations & Pragmatics of Cognitive Work Analysis

The Engineering Design of Systems: Models and Methods, 2nd Edition Availability of Standards for Purchase

Using Agile to Deliver Value – Kanban, Flow and Cadence Report on Systemic Root Cause Analysis of Program Failures

… READ MORE

Conferences and Meetings

… READ MORE

Education and Academia

New Training Program to Prepare Systems Engineers for the INCOSE Certified Systems Engineering Professional (CSEP) Designation

… READ MORE

Some Systems Engineering-Relevant Websites

… READ MORE

Standards and Guides

ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes ISO/IEC TR 24748 Guide for ISO/IEC 15288:2008 and ISO/IEC 12207:2008

ISO/IEC 15026 System and Software Assurance ISO/IEC 16326 Project Management

… READ MORE

Some Definitions to Close On – IPT and IPT

… READ MORE

PPI News

… READ MORE

PPI Events

… READ MORE

A Quotation to Open On

“In defining engineering terms, a good place to start is the Oxford or Merriam-Webster’s English Dictionaries” – Robert Halligan

Feature Article

Cognitive Work Analysis and Cognitive Systems Design

Gavan Lintern

Dayton, Ohio 45431-1289, USA

glintern@CognitiveSystemsDesign.net

Reprise

In the first of a series of articles for this newsletter, I defined Cognitive Work, Cognitive Systems Engineering, Human Systems Integration and Human Factors Engineering. In the second, I outlined some important features of the practice of Cognitive Systems Engineering, discussed the distributed nature of cognitive systems, introduced my personal perspective on design and introduced two popular frameworks (Cognitive Task Analysis and Cognitive Work Analysis) for Cognitive Systems Engineering. In the third I outlined the framework of Cognitive Task Analysis. In this fourth article, I will outline the framework of Cognitive Work Analysis and contrast the two frameworks I have discussed. In the fifth and final article, I will illustrate how each of these two frameworks can complement existing Systems Engineering processes used in the design of large-scale socio-technical systems.

Cognitive Work Analysis

Cognitive Work Analysis is a multi-stage analytic framework for identifying the human-relevant work constraints in a socio- technical system (Vicente, 1999) in the form of:

The Hierarchical Structure of work in terms of the activity-independent constraints of the work domain at several levels of abstraction and decomposition (Work Domain Analysis)

The Partitioning and Organization of work in terms of Work Situations and Work Problems (Work Organization Analysis) The Cognitive States typically established in the execution of work problems and the cognitive processes used to transition through states (Work Task Analysis)

The cognitive strategies, defined as the categories of cognitive processes, used to transform one cognitive state into another (Work Strategies Analysis)

The coordinative processes that support management and collaboration of work (Organizational Coordination Analysis) Categories of human cognitive processing in terms of skill, rules and knowledge (Cognitive Processing Analysis)

The foundational assumption of Cognitive Work Analysis is that workers in a complex system operate within a large number of constraints. They remain free to act flexibly within those constraints and free, therefore, to act flexibly in response to unanticipated situations. The purpose of Cognitive Work Analysis is to identify and map out those constraints so that design efforts can take explicit account of them.

The products of Cognitive Work Analysis are theory-based Knowledge Representations (Figure 4) of the work domain, of individual and collaborative activities undertaken in the work domain, and of processes involved in the execution of those activities. These representations are developed from information gathered by use of cognitively oriented Knowledge Acquisition tools. The goal of Cognitive Work Analysis is to identify the basic sources of regularity or constraint, both contextual (technological, social, environmental) and human (intentional, perceptual, cognitive, active) that shape human action in a workspace.

Functional Interfaces, Functional Workspaces

Although Cognitive Work Analysis is not a method of design, its analytic products can be used to support any design method.

Those who undertake Cognitive Work Analysis typically adhere to the principles of Ecological Interface Design (e.g., Dinadis & Vicente, 1999). An ecological interface is one in which information is structured in a manner that reflects the structure of the cognitive work (Tufte, 1997) so that it is readily assimilated and so that there are natural transitions between information elements. An ecological interface reveals to the operator the operation of underlying system processes, the interactions between system states, and the constraints on control actions.

A conventional interface displays the status of sensed system states as independent parameters. The operator then has the task of integrating those parameters into a meaningful interpretation of system function, a task that is cognitively demanding and that may be impossible under tight time constraints. While an ecological interface presents more information than a conventional one, it does not overload the operator because that information is integrated across levels of abstraction and the display supports a natural and compatible navigation that allows the operator to converge naturally on currently important constellations of information. Thus, an ecological interface reduces complexity of activity but it does not do that by reducing the complexity of the information but rather by managing it.

This strategy is commonly referred to as Ecological Interface Design because of its allegiance to the principles of Ecological Psychology. In my work, I have referred to this design process as Functional Interface Design (Lintern, Waite & Talleur, 1999) because the emphasis is on meaningful information that supports functional action versus data that must be interpreted. The most direct way of providing meaningful information is through display of affordances, where an affordance is defined as the ratio between what is required and what is possible (Lintern, 2000). For example, instead of showing fuel quantity, an affordance-based display will show the ratio between the distance that must be traveled and the distance that can be traveled given the remaining fuel. As might be obvious, if this ratio is not > 1.0, the required distance cannot be covered with the available fuel. The interpretation of such a display is direct and immediate.

In systems engineering however, we are less concerned with pieces of information than we are with constellations of information as they support cognition and action. Functional displays must be assembled into functional interfaces where the displays are not merely placed in a convenient arrangement but the information from the variety of sources is integrated to encourage seamless navigation to and foregrounding of that particular and specific constellation of information that bears on the current problem. As suggested above, the goal is not to reduce the complexity of the information space but to manage it in a manner that reduces the complexity of the activity or, at least, reduces the overhead work of finding and organizing within a complex set of information.

Additionally, if information is to be at all useful, it must lead to action. To that end, functional interfaces must be integrated with action support systems so that the interplay between analysis and execution is seamless. For example, a predictor display for aircraft control (Lintern, Roscoe, Koonce & Segal, 1990) will alert the pilot when action is required, will reveal the nature of the corrective action, and will show whether any action taken will return the aircraft to the desired flight path. This view of functionally integrated interfaces and controls leads naturally to the conceptualization of a functional workspace.

Cognitive Systems Design

Within the context of large-scale socio-technical systems, interface (or workspace) design constitutes only a part of the problem and in that broader context I prefer to speak of Cognitive Systems Design. We know well that individuals as cognitive systems perform at diverse levels of effectiveness. Furthermore, a committee of disparate individuals is also a cognitive system but many committees are not particularly effective; they often develop a mediocre product. Systems Engineers design distributed collaborative systems as in, for example, a net-centric command system. In the terms I describe here, a net-centric command system is a cognitive system. Whether by default or intent, we are designing cognitive systems and we should be designing effective ones. The framework of Cognitive Work Analysis identifies the full range of properties that need to be considered in the design of an effective cognitive system.

An effective cognitive system, whether it be an individual, a team or an organization, will make good decisions and plans and will execute courses of action in a timely and effective manner. That requires access to suitable information and to suitable action capabilities as would be provided by a well-configured functional workspace, but it also requires functional structures and coordinating capabilities that encourage effective cognition (and that discourage the opposite). Team and organizational cognition emerge via the coordinated collaboration of individuals and the effective use by participants of technological artifacts. Design of such systems requires cognitively oriented analyses of information processing and coordinative functions. At the very least, where the individuals are geographically distributed, the communications systems must support the types of interactions that are essential to functional coordination.

Frameworks for Cognitive Analysis; Task or Work?

Remarkably, interest in these two frameworks, Cognitive Task Analysis and Cognitive Work Analysis, emerged within the same time period. The work in the Cognitive Task Analysis commenced largely with the insights generated by Klein (1989). It has, however, become evident that these early insights were addressing only a part of the problem and so Cognitive Task Analysis has continued to evolve over the past 20 years from that powerful insight about recognition-primed decisions. It currently constitutes a more comprehensive suite of methods that can be used to address diverse cognitive functions. In contrast, Cognitive Work Analysis was first presented as a comprehensive system (Rasmussen, 1986) and although considerable work has been undertaken throughout these past 20 years on refining it and extending its application areas, its structure remains

largely as it was first described.

At their inception, neither framework addressed design explicitly but considerable work has been undertaken through the past decade to address this neglect, resulting in the strategies of Decision Centered Design for Cognitive Task Analysis and Ecological Interface Design for Cognitive Work Analysis.

Those working with the framework of Cognitive Task Analysis have developed innovative methods of Knowledge Elicitation but their approach to Knowledge Representation has been opportunistic. Many of these representations have been developed with an eye to linking directly to the design problem. In contrast, those working in the framework of Cognitive Work Analysis have been opportunistic in their approach to Knowledge Elicitation but the approach to Knowledge Representation has been more principled and systematic, with many of the representations reflecting the structure of underlying theory although linking less directly to the design problem.

As might be imagined from my earlier comment that those with experience in the use of the critical decision method prefer to work with actual rather than hypothetical incidents, Cognitive Task Analysis has largely been directed towards improving existing systems. In contrast, the literature on Cognitive Work Analysis emphasizes the design of future systems. Nevertheless, there is no principled distinction between the two frameworks on this dimension; those working within the framework of Cognitive Task Analysis do sometimes apply their methods to the design of future systems by generalizing lessons construed from their analysis of current systems while Vicente (1999), in his treatment of Cognitive Work Analysis, allows that the study of current practice can inform an analysis oriented towards the design of future systems.

Finally, the framework of Cognitive Task Analysis is geared towards identifying points of leverage for design and towards designing cognitive support systems. In contrast, the framework of Cognitive Work Analysis takes a comprehensive systems perspective in emphasizing the design of functional interfaces and cognitive systems.

None of the characterizations I offer here should be taken as criticisms. Each of these frameworks has particular strengths and while Cognitive Systems Engineers tend to be somewhat parochial, there is considerable potential benefit in bringing these two frameworks together. However, the primary purpose of this series of articles is to illustrate how these frameworks can support acquisition of complex socio-technical systems and it is that issue I turn to in the next article.

Summary

In this article, the fourth in the series, I have outlined the framework of Cognitive Work Analysis and compared it to Cognitive Task Analysis. In the fifth and final article, I will illustrate how each of these two frameworks can complement existing Systems Engineering processes used in the design of large-scale socio-technical systems.

References

Dinadis, N., Vicente, K.J., 1999. Designing functional visualizations for aircraft system status displays. International Journal of Aviation Psychology 9, 241-269.

Klein. G. A. (1989). Recognition-primed decisions. In W. B. Rouse(Ed.).Advances in man-machine systems research (Vol. 5, pp. 47-92). Greenwich, CT: JAI.

Lintern, G. (2000). An affordance-based perspective on human-machine interface design. Ecological Psychology, 12, 65-69.

Lintern, G., Waite, T., & Talleur, D. A. (1999). Functional interface design for the modern aircraft cockpit. The International Journal of Aviation Psychology, 9, 225-240.

Lintern, G., Roscoe, S. N., Koonce, J. M., & Segal, L. D. (1990). Transfer of landing skill in beginning flight training. Human Factors, 32, 319-327.

Rasmussen, Jens (1986). Information processing and human machine interaction: an approach to cognitive engineering. New York: science publishing, North Holland series in system science and engineering, volume 12. ISBN 0-444-00987-6

Tufte, E.R., 1997. Visual Explanations: Images and Quantities, Evidence and Narrative. Graphics Press, Cheshire, CT.

Vicente, Kim J. (1999). Cognitive Work Analysis: Towards safe productive and healthy computer based work. Mahwah, NJ: Lawrence Erlbaum.

Handling the Complexity of Large, Technology-based Business Ventures

Erik W. Aslaksen Sinclair Knight Merz

100 Christie Street, St. Leonards, NSW 2065, Australia

It is argued that the systems engineering methodology, now increasingly accepted as the preferred approach to complex

projects also outside defense and aerospace, should be extended into the front end of commercial business ventures, in order to assure that the engineered solution fully meets the business objective.

Many business ventures involve the creation of large, technology-based facilities, such as transport and storage facilities, mines, power stations, and process plants, and their success depends, among other factors, on the degree to which these facilities support the business objectives. That can be seen as the result of a two-stage process; first the conversion of the objectives into requirements on the facilities, and then the design of facilities to meet those requirements. Both of these processes are prone to inadequacies and even outright errors, as is the transmission of the information across the interface between them. It is an interface between two different cultures, business and engineering, and it is not helped by the fact that the means of transmission, a contractual document of some sort, is developed by a third group, the legal profession, which has a different perspective again.

The problems associated with this process are magnified by the increasing complexity of the requirements. There are several reasons why the complexity is increasing: Most obvious reasons are the size and multi-disciplinary nature of the projects, as well as the technological sophistication made possible by the rapid development of new technology. Another group of reasons arises from the more stringent regulations and requirements with regard to environmental impact and safety. But the most recent and perhaps the most rapidly growing reason is the involvement of community groups of all kinds, made possible by the ready information exchange offered by the Internet. As an example, the design of a high voltage transmission line takes maybe six months, but the community consultation may take several years.

To handle this increasing complexity, the engineering profession has developed systems engineering as a process additional to the traditional, discipline-based (i.e. civil, mechanical, electrical, etc.) design processes and associated management processes. It is perhaps best thought of as a pre-process that reduces the complexity prior to applying the traditional design processes, but it remains involved throughout the whole project. How does it manage to reduce the complexity? By leveraging an observable aspect of how the human brain handles complexity. And it is important to note that complexity is relative to the capabilities of the brain; what is complex to the brain is not complex to a computer, and vice versa. You can instantly recognize your mother on a photograph, something that is a complex task for a computer, but try the cube root of a six-digit number! The observable aspect is that when something has too many variables for the brain to perceive and process it as a unit, we automatically subdivide it into more manageable elements, or chunks. Nowhere is this more obvious than in organizations, e.g. in the military, with the number of soldiers in a platoon, the number of platoons in a company, and so on. This aspect was first made explicit by Prof. George A. Miller in his seminal paper The magical number seven, plus or minus two: Some limits on our capacity for processing information.Psychological Review, 63, 81-97(1956), and a very simple model that provides a possible explanation for why this is so can be found in one of my earlier books, The Changing Nature of Engineering, McGraw Hill (1996).

Systems engineering is the consistent application of this insight to large engineering projects. Such projects contain two complex entities; the physical object to be created, and the work required to create it. Both are treated as systems, i.e. as collections of interacting elements, each organized in a hierarchical structure, so as to maintain the “chunking” introduced above. In the case of the object, the elements are modules, equipment, and subsystems and the structure is called the System Breakdown Structure (SBS) or also system architecture; in the case of the work, the elements are tasks and work packages, and the structure is the Work Breakdown Structure (WBS). In the case of the SBS, the interactions between the elements take the form of a transfer of matter or energy; in the case of the WBS the interactions are in the form of information. Systems engineering consists of a number of processes for developing and managing these structures throughout the project lifecycle, and is documented in such standards as ISO 15288 and EIA 632 or in handbooks, such as the Systems Engineering Handbook published by the International Council on Systems Engineering (INCOSE).

While systems engineering was, for obvious reasons, first developed and employed within the defense and aerospace industries, it is now being increasingly accepted throughout the engineering community as the preferred approach to complex projects, and there is mounting evidence, albeit mainly qualitative and anecdotal, of the benefits that can be achieved. Eric C. Honour, President of Honourcode Inc, has collected data on 44 projects as part of his ongoing efforts to document the value of systems engineering, and one illuminating result is a quantity called Development Quality (DQ) as a function of the proportion of the systems engineering effort spent on a project, as shown in Fig. 1 (reproduced with permission from Understanding the Value of Systems Engineering, in Proceedings of the 14th Annual International Symposium, available online at www.incose.org

Figure 1: Development quality as a function of systems engineering effort.

In this figure, DQ is defined as the inverse of the average of the actual cost (AC) to planned cost (PC) and actual schedule (AS) to budgeted schedule (BS), or

and the systems engineering effort is the product of the actual cost of performing the traditional systems engineering task and a measure of the quality of that performance, expressed as a percentage of the project cost up to delivery of first article, not including production costs.

However, even though systems engineering has improved the success rate of large engineering projects, there are still projects where the proponents of the business venture are less than satisfied with the outcome. Based on my own experience and through discussions with colleagues, in most of these cases the problem has not been in the engineering as such; the facilities have performed exactly as they were designed to do, in accordance with the requirements. On closer inspection, the cause of the dissatisfaction could be traced to the requirements in the first place; i.e. to the expression of the business objectives as requirements on a particular facility. And it is not so difficult to see how this can quite easily happen. From the business point of view, the project is primarily an investment opportunity based on providing a service (in the widest sense, including goods) to meet a perceived market need. The characteristics of the service, its cost, reliability, flexibility in the face of changing market needs, environmental impact, etc, are all of great interest and the subject of detailed modeling and analysis, but how the service is provided is of secondary interest. If it could be provided by a fairy waving her wand (for an acceptable price), that would in principle be equally as satisfactory as building a facility. The facility is, in essence, the engineer’s solution to producing the service, and so the interface between the two parts of the development process, the business process and the engineering process, should ideally be the definition of the required service, without tying it to any particular facility.

The purpose of an engineered object is an abstract concept, describing only the service it is intended to provide, completely disassociated from how it does it and from any physical aspects of the object. This is best illustrated by means of a simple example – removing the cork from a bottle of wine. That is the service required by the user; the physical solution provided by engineers may take many different forms, such as a simple cork screw, a cork screw combined with some mechanism for extracting the cork using a smaller amount of force, a thin, hollow needle attached via a valve to small pressurised gas cylinder, a two-pronged device which is inserted between the cork and the bottle, and so on. For any one of these we can give a description of what the object is, by means of drawings, etc., that would allow it to be manufactured without any knowledge of what its purpose is. We could also give a description of how it works, e.g. in the case of the simple corkscrew by means of such parameters as how many turns are required, what torque is required, how much force is required to extract the cork, etc., and this would allow us to determine if it actually fulfils its purpose, i.e. meets the service requirements. These two descriptions would, of course, both be different for different solutions, but all the solutions have in common their purpose, the service they are intended to provide, also called their functionality. I emphasize the inclusion of the word “intended” here; functionality is not a property of any object; it exists prior to any object created to provide the corresponding service.

Now, this is all very well, but in reality it is impossible to get a business venture off the ground without having carried out a bankable feasibility study, which of necessity involves selecting a particular means of producing the service. This selection represents a transition from the space of services to the space of facilities that can provide services, and it is in this transition that we can often find the cause of dissatisfaction with the end result. In the above case of removing a cork the choices are relatively limited (although there would be thousands of variants if all combinations of shape, material, and color were considered); in the case of a major technology-based business venture the number of possible realizations is mind-numbing.

The approach most often taken is to select a few options based on previous experience and identify the preferred option by its greater cost-effectiveness. As effectiveness is defined in terms of meeting the business objectives, it would appear that nothing has been lost in this transition, but a closer scrutiny reveals that, almost invariably, the objectives have been recast using the features describing the performance of the chosen realizations. Again, a very simple example may be the best way to illustrate this: Laundering of clothes is a significant activity in our society; providing that service (i.e. getting our clothes laundered) therefore presents a potential investment opportunity. Our thoughts then automatically focus on the physical activity of laundering, and from there it is only a small step to focus on providing a better washing machine. There are many options, both with regard to technology and with regard to manufacturing, marketing, and sales, and an appropriate application of systems engineering will efficiently find a near-optimal solution in terms of cost-effectiveness. But the effectiveness is now couched in terms of the washing machine’s performance, not in terms of meeting the business objective, which was to maximize the return on investment. Once this has taken place, other options, such as providing a laundry service and dispensing with home washing machines all together, are removed from consideration.

The problems surrounding this transition form business to engineering are well recognized, and in my own sector of engineering, consulting, a great deal of attention is directed towards “understanding the needs of the Client”. However, this usually takes place at a point in the life of the project where the Client has already cast his requirements in the form of requirements on a facility, and the engineer is left to, at best, try to understand the underlying business objectives by some form of “reverse engineering” of the requirements. A much better approach would be to apply the analytical, top-down systems engineering approach from the very start of the project, developing the business objectives step-wise in increasing detail, starting with the single objective of maximizing the return on investment. This approach, which can be thought of as design in the functional domain, is the subject of my recent book, Designing Complex Systems, CRC Press (2008).

There is, of course, at some point still a transition from the business objectives into the space of realizations of these objectives, but because this takes place within the same framework, there is always complete traceability back to the business objectives. Even down to the level of detailed design, the justification for any choice from a set of options is formulated in terms of the business objectives, and the business proponent’s satisfaction with the outcome is assured.

Finally, with regard to this assurance, I note that systems engineering is very similar to quality assurance. People and enterprises did high-quality work long before there was any talk of quality systems; what a quality system provides is the assurance that a task will be performed to the same standard (almost) every time. Similarly, complex projects were previously, and some still are, undertaken successfully without systems engineering; what systems engineering provides, besides increasing the efficiency of the process, is the assurance that the business objectives will be fully met (almost) every time.

Systems Engineering News

Graph-Based Tools Contest 2009: Call for Cases

In order to facilitate the comparison of graph transformation tools, we are soliciting potential case studies. If you have a suitable case study, please describe it shortly but as detailed as needed and submit it to the GraBaTs EasyChair. This includes cases that have already been carried out using a given tool. A committee will select a small, but representative set of case studies to be used for the contest.

Case descriptions should include:

A short description of the context of the case, with references

A clear description of the case itself, including implicit or explicit answers to the following questions: What is the subject to be modelled?

What should the model be (able to) do, i.e., what manipulations/rules should be possible? What is the purpose of the model, i.e., what would it be used for from a larger perspective?

What are variation points in the case, i.e., divide up you case in core characteristics and extensions? How should the model be used, i.e., are visual aspects important, is manual simulation allowed/required?

What are the challenges involved in the case, and if possible, suggestions on how to measure submissions with respect to these challenges?

Submitters are encouraged to provide a set of reference input/output documents (models/graphs) that can be used to evaluate the correctness of solutions to the case study.

More information

Reforming Weapon Systems Acquisition

Source: AP/Gerald Herbert

Senators Carl Levin (D-MI) and John McCain (R-AZ) have demonstrated that United States Department of Defense spending reform is important enough to merit bipartisan action by co-sponsoring S. 454, the Weapon Systems Acquisition Reform Act of 2009. This legislation could be a step toward creating a more cost-efficient Department of Defense.

The Government Accountability Office identified the weapons acquisition process within the DoD as being at high risk for waste, fraud, abuse and mismanagement in 1990. Nearly 20 years later, the weapons acquisition process has deteriorated even further as contracts have become less competitive and exorbitant cost growth has become the norm. From 2000 to 2007, major military acquisitions ran over budget by $401 billion. The Weapons Systems Acquisition Reform Act would help ensure that interventions occur before the cost-overruns happen in the first place.

More information

PMI Opens Request for Sponsored Research Proposals

The Project Management Institute (PMI) requests research proposals from scholars in project management and other disciplines (e.g. management, organizational psychology, education, sociology, etc.). Proposed research should have direct application to any aspect of the project management body of knowledge or its practice.

More information

DHS (U.S.A.) to Establish New Research Centers

The U.S. Homeland Security Department released plans to establish two new research centers focused on program and concept analysis.

The department’s Science and Technology Directorate announced the formation of the Homeland Security Studies and Analysis Institute to provide analysis of mission-focused homeland-security programs.

Officials also announced the formation of the Homeland Security Systems Engineering and Development Institute, which will evaluate best practices on how the Department of Homeland Security can reach its objectives through life-cycle systems engineering and management among other analyses, the department reported.

More information

University of Maryland, Baltimore County’s Engineering Management & Systems Engineering Info Session, April 15, 2009

The University of Maryland, Baltimore County’s (UMBC) Engineering Management & Systems Engineering Information Session will be held on Wednesday, April 15, 2009, from 6 p.m. to 8:00 p.m. at the UMBC Tech Incubator. The public is welcome to come and network with current students, talk with staff and representatives from the Graduate School and Career Services, and learn more about UMBC’s graduate programs in Engineering. The event is co-sponsored by INCOSE Chesapeake Chapter and IEEE Baltimore.

More information

CALL FOR PAPERS: IEEE Transactions on Industrial Informatics

Special Section on “Model-based Approaches for Embedded Systems”.

Guest Editors: Joao M Fernandes (UMinho) and Luis Gomes (U Nova Lisboa).

This Special Section on “Model-based Approaches for Embedded Systems”aims at presenting some of the most significant research works representing the state-of-the-art in the area of modeling formalisms and techniques for embedded systems, with an emphasis on the use of graphical and visual notations for modeling the system’s behavior.

More information

Featured Society: NDIA Systems Engineering Division

Source: NDIA Website

The National Defense Industrial Association (NDIA) is a non-profit, educational association representing U.S. industry, government, and all military services. NDIA provides a legal and ethical forum for the exchange of information between Industry and Government on U.S. National Security issues.

The mission of the NDIA Systems Engineering Division is to promote the widespread use of systems engineering (SE) in the United States Department of Defense (DoD) acquisition process, in order to achieve affordable and supportable weapon systems that meet the needs of the military users; to provide a forum for the open exchange of ideas and concepts between government, industry and academia; and to develop a new understanding of a streamlined SE process.

NDIA formed the Systems Engineering (SE) Division over 10 years ago to address technical and management issues related to DoD acquisition reform, and to promote an integrated and balanced approach to weapon system design.

The SE Division seeks to effect good technical and business practices within the aerospace and defense industry. It focuses on improving delivered system performance, including supportability, sustainability, and affordability. The division emphasizes SE excellence in such areas as engineering processes, use of COTS, open systems architecture, SE disciplines, developmental test and evaluation (DT&E), supportability, education & training, modeling and simulation, software, integrated diagnostics, prognostics and enterprise health management, affordability, system assurance, system safety and human systems integration, and overall quality.

The SE Division is supported by Mr. Gordon M. Kranz, Director, Systems and Software Engineering (SSE), in the Office of the Deputy Under Secretary of Defense for Acquisition and Technology. Mr. Kranz’s responsibilities include establishing OSD SE

and DT&E policy and guidance in support of major DoD acquisition programs. He leads DoD efforts to revitalize SE and DT&E through enhanced SE and integrated T&E practices. Related SSE initiatives include early SE engagement, SE for Systems of Systems, technical risk management, manufacturing and production quality, software engineering, and system assurance.

SSE provides SE and DT&E support to acquisition programs through targeted program assessments that identify issues and risks early in the acquisition cycle in order to provide recommendations to improve program outcomes. The SSE team also manages the associated Defense Acquisition Workforce Improvement Act (DAWIA) competency models and certification standards that affect more than 50,000 members of the acquisition workforce assigned to the SE; production, quality, and manufacturing; and T&E career fields.

The NDIA SE Division is organized to support these U.S. DoD activities and initiatives. Active SE Division committees include Systems Engineering Effectiveness; Systems-of-Systems Engineering, Mission Assurance, Education & Training; Modeling and Simulation; Quality and Reliability Assurance; Life Cycle Support; Automatic Test; Software; System Assurance; Enterprise Health Management including Integrated Diagnostics & Prognostics; Developmental Test & Evaluation; Interoperability & Net- Centric Operations; System Safety; Human Systems Integration; and Quality Assurance.

The SE Division has taken on a number of lead roles and major projects in support of key DoD initiatives. It is the industry sponsor of the DoD/industry Capability Maturity Model Integration (CMMI®) project, which involved restructuring the previously stand-alone Software Engineering Institute (SEI) capability maturity models into an integrated model. The SE Division hosts the annual Systems Engineering Conference and CMMI® Technology Conference and User Group. The division has performed numerous tasks and studies for OSD and the Services and several tasks for the U.S. Defense Science Board.

The SE Division serves as a lead activity with invited participation by several affiliate organizations, including the Aerospace Industries Association (AIA), International Council on Systems Engineering (INCOSE), National Training and Simulation Association (NTSA), Institute of Electrical and Electronics Engineers (IEEE), the American Institute of Aeronautics and Astronautics (AIAA), and SAE International.

The SE Division does not seek to duplicate any significant effort ongoing in another NDIA division or committee, industry association, or professional society, but rather to complement efforts by bringing the activity into the division structure as an affiliate partner. This collaboration magnifies the resources and talent available to our DoD sponsor.

The NDIA SE Division lists the following as major Division activities:

NDIA Systemic Root Cause Analysis Workshop Capability Maturity Model Integration (CMMI) Supportability Documentation Task Supportability Factors Identification Task.

Membership of the NDIA is open to Companies and institutions via corporate membership, and to Defense professionals via individual membership. Local networking comes by means of 52 chapters, located in most parts of the U.S.A..

INCOSE Technical Operations

Resilient Systems Working Group

http://www.incose.org/practice/techactivities/wg/rswg/

by Alwyn Smit.

Introduction

Last time we looked at INCOSE technical operations in general. This article looks at the Resilient Systems Working Group.

Charter

The purpose of the Resilient Systems Working Group is to use systems engineering principles to enhance the resilience of systems to reduce the likelihood of and to recover from disasters. Resilience is the ability of organizational, hardware and software systems to mitigate the severity and likelihood of failures or losses, to adapt to changing conditions, and to respond appropriately after the fact. The study of system resilience includes the creation of a robust infrastructure that designs, builds, tests, maintains, and operates the system. The scope is larger than design, reliability, human factors or system safety. It is an infrastructure wide topic to include customers, developers, suppliers, and all other stakeholders. System resilience has a large interest in cultural, sociological and psychological causes of human-made disasters. Hence, it is truly multidisciplinary. The Resilient Systems Working Group is a part of the INCOSE Public Interest Sector.

Leadership

Chair: Scott Jackson, University of Southern California Co-Chair: Rick Dove, Stevens Institute of Technology

Contact Resilient Systems Working Group for additional information or to join this group.

Accomplishments and Products

The Resilient Systems Working Group (RSWG) had a successful meeting in Albuquerque with 16 participants. Most of the time was spent discussing what resilience is and reviewing a presentation on resilience. This presentation summarized conclusions from Challenger, Columbia, Chernobyl, 9/11, Katrina and other events. Resilience is the ability of organizational, hardware and software systems to mitigate the severity and likelihood of failures or losses, to adapt to changing conditions, and to respond appropriately after the fact. This definition has not been officially adopted by the group. Such concepts as emergence, complexity and adaptability figure heavily in resilience. The group discussed many products but decided that first priority would be given to a lexicon and to an expanded bibliography. The Resilient Systems Working Group is a node in the international Resilience Engineering Network. The group also has a relationship with the Robust Systems Working Group of the Association Française d’Ingénierie Système (AFIS), the French equivalent of INCOSE.

The URL for the Resilience Engineering Network is: www.resilience-engineering.org. The Proceedings for the Second Symposium on Resilience Engineering in November of 2006 in Juan-les-Pins, France can be found on this site.

The book Resilience Engineering: Concepts and Precepts can be ordered from Ashgate Publishing Limited from the following site: www.ashgate.com.

Current Projects

Technical Operations also include an Internal Operations element that focuses on technical events, technical communications, planning, procedures and publications. Specifically:

1. Resilience Lexicon. Project Leader – Rick Dove. This project will capture the unique words and definitions associated with resilience.
2. Expanded Resilience Bibliography Project Leader – Duarte Gonçalves. This project will document the many articles and books associated with resilience. It will also provide a short paragraph describing the content and value of each article or book.
3. Resilience Report Project Leader – Scott Jackson. The purpose of this project will be to develop a report on resilience that will be understandable by the public and political decision makers. This is a long-term project and will follow the completion of the Lexicon and the Expanded Bibliography.

Latest News

The RSWG, the Anti-Terrorism WG and the Infrastructure WG met in San Francisco with members of the San Francisco Fire Department (SFFD) and discussed the resilience of the fire protection infrastructure system.

Jennifer Maxwell, a student at USC, wrote a paper about the meeting. The idea is that this paper will be the starting point for an article in INCOSE Insight magazine. Additions to the article can be made by those who were there including members of the SFFD. Jennifer, David Boyd and Dick Emerson will be the co-authors of the paper.

Systems Engineering Software Tools News

Artisan Software Tools: Artisan announces Artisan Workbench

Artisan Software Tools, stated in its release to be the world’s largest independent supplier of industrial-grade, collaborative modeling tools for complex, mission and safety-critical embedded systems and software, has announced Artisan WorkbenchTM, which provides a fully integrated, collaborative engineering framework for the trouble-free deployment and maintenance of best- in-class tools for mission and safety-critical embedded systems and software development.

More information

Geensys announces Reqtify 2009-1a

Geensys, reported to be a specialist provider of embedded development tools, value-added embedded engineering/consulting services and embedded software IP, has announced Reqtify 2009-1a, a new and improved version of its flagship tool for the

automated management of embedded hardware and software requirements capture, traceability and impact analysis throughout the entire development lifecycle. Reqtify 2009-1a incorporates significant new, third-party interfaces for Enterprise Architect, CM Synergy and RTDS, brand new Eclipse JDT Interface and Tagger, an updated RIF 1.1 import/export gateway and an improved Word/PDF Tagger plug-in as well as various user-requested features and usability enhancements.

More information

Cassbeth Releases a New Version of the Specification Analysis Tool (SAT)

Cassbeth released a new version of the Specification Analysis Tool (SAT). This release introduces a new feature that allows a user to mine requirement objects bound by various categories in their specifications. This new feature is a direct result of using the related product General Document Analysis (GDA) tool for an analysis of President Obama’s’ American Recovery and Reinvestment Act of 2009.

More information

LDRA TBreq v3.0 Launches Next-Generation Requirements Traceability Automation

LDRA announced the launch of TBreq v3.0, which provides next-generation management and complete automation of requirements traceability with software testing and verification. For industries such as avionics, medical, defence, and nuclear where requirements traceability consumes a significant portion of project budget, TBreq v3.0 automates the management of software requirements, enabling developers to reduce software errors, project costs and resource constraints.

More information

Sparx Updates Enterprise Architect to 7.5

Sparx Systems announced on April 8 the release of Enterprise Architect 7.5 for download. Version 7.5 includes new and enhanced modeling capabilities for the business user, systems engineer and advanced modeler.

Enterprise Architect 7.5 allows users to build, trace and transform models from business concepts and rules down to executable BPEL code, collaborate and share large-scale enterprise repositories over multiple sites, with high performance version control integration between sites. Users can employ new scripting tools to make broad-scale and dynamic model updates on the fly. Enterprise Architect 7.5 allows users to visualize the enterprise with new built-in profiles for executive-level strategic modeling.

Three editions are offered:

Ultimate Edition

Systems Engineering Edition Business and Software Edition

For systems engineers, Enterprise Architect Systems Engineering Edition, brings the standard design and modeling tools into a hardware-focused environment. The Systems Engineering Edition includes support for SysML 1.1 for the first time. The Systems Engineering Edition can also generate code and logic from design constraints based on hardware. This edition retails for US$599, versus the US$299 for the standard edition.

More information

ParaMagic™ plugin 16.0 is Released by No Magic

NoMagic announced on 10 April that ParaMagic™ 16.0 offers a dramatic expansion of the power of SysML parametric simulation, allowing users to integrate Microsoft Excel®, MATLAB®/Simulink®(The MathWorks, Inc.) and Mathematica®(Wolfram Research, Inc.) into their MagicDraw SysML models.

NoMagic states that, with these new capabilities, users can:

Incorporate existing simulation models created in MATLAB and Simulink Automate data transfer between Excel spreadsheets and MagicDraw models Add powerful Mathematica graphing functions to their simulations

More information

News from Vitech

Vitech, home of CORE and COREsim systems engineering tools, has a new website. Current versions of CORE, per the Vitech website, are:

CORE Workstation 5.1.5 Commercial Edition

CORE Enterprise 5.1.5 Commercial Edition (Server, Client, and CORE2net) CORE 5.0 University Edition

COREsim, working with CORE Workstation or CORE Enterprise, gives the user the added capability of discrete event simulation. As well, COREsim enables execution of the integrated architecture, by dynamically interpreting the behavior model that resides in the system design repository. Discrete-event simulation logic identifies timing, resource utilization, and model inconsistency including:

COREsim TimelineTimeline Analysis – COREsim timeline analysis identifies the sequential and concurrent events that occur during the simulation, based upon data triggers, resource availability, random probabilities, and outcomes.

Resource Analysis – COREsim resource analysis monitors resource availability to identify bottlenecks, resource contention, and queuing effects on system performance.

Consistency Analysis – COREsim may be used interactively to identify logical inconsistencies as the behavioral model is developed. This provides the engineer with a dynamic modeling construction kit for establishing a complete and logically consistent model of system behavior.

More information

Systems Engineering Books, Reports, Articles and Papers

System of Systems Engineering

by Mohammad Jamshidi

Publisher: Wiley, ISBN: 0470195908 Edition: November 3, 2008

Publishers Description: This groundbreaking book brings together the viewpoints of key global players in the field to define challenges in System of Systems (SoS) and Systems of Systems Engineering (SoSE) and to provide possible solutions. Each chapter has been contributed by an international expert, and topics covered include modeling, simulation, architecture, the emergence of SoS and SoSE, net-centricity, standards, management, and optimization, with various applications to defense, transportation, energy, the environment, healthcare, service industry, aerospace, robotics, infrastructure, and information technology.

More information

Soft Computing Based Modeling in Intelligent Systems

Balas, Valentina Emilia; Fodor, János; Várkonyi-Kóczy, Annamária R. (Eds.) Publisher: Springer, 2009, ISBN: 978-3-642-00447-6

Publishers Description: The book includes soft computing implementations of intelligent systems models. The recent popularity of fuzzy systems, neural networks and evolutionary computation, considered as related in AI, are now widely used to build intelligent systems. Professor Lotfi A. Zadeh has suggested the term “Soft Computing” for all new techniques working in these new areas of AI. Soft Computing techniques are tolerant to imprecision, uncertainty and partial truth. Due to the large variety and complexity of the domain, the constituting methods of Soft Computing are not competing for a comprehensive ultimate solution. Instead they are complementing each other, for dedicated solutions adapted to each specific problem. Hundreds of concrete applications are already available in many domains. Model based approaches offer a very challenging way to integrate a priori knowledge into procedures. Due to their flexibility, robustness, and easy interpretability, the soft computing applications will continue to have an exceptional role in our technologies.

More information

Business Object Modeling – an Introduction

By Alex P on March 9th, 2009

Business object modeling describes a static representation of the business domain under consideration in a project. It is static as it shows the important entities, their relationships and attributes but does not show how these change over time (see Use Cases

– an Introduction for an example of a technique for a ‘dynamic’ or functional view of a system).

More information

Thinking in Systems: A Primer

by Donella Meadows

Publisher: Chelsea Green Publishing (December 3, 2008), ISBN-10: 1603580557, ISBN-13: 978-1603580557

Publishers Description

In the years following her role as the lead author of the international bestseller, Limits to Growth—the first book to show the consequences of unchecked growth on a finite planet— Donella Meadows remained a pioneer of environmental and social analysis until her untimely death in 2001.

Meadows’ newly released manuscript, Thinking in Systems, is a concise and crucial book offering insight for problem solving on scales ranging from the personal to the global. Edited by the Sustainability Institute’s Diana Wright, this essential primer brings systems thinking out of the realm of computers and equations and into the tangible world, showing readers how to develop the systems-thinking skills that thought leaders across the globe consider critical for 21st-century life.

Some of the biggest problems facing the world—war, hunger, poverty, and environmental degradation—are essentially system failures. They cannot be solved by fixing one piece in isolation from the others, because even seemingly minor details have enormous power to undermine the best efforts of too-narrow thinking.

While readers will learn the conceptual tools and methods of systems thinking, the heart of the book is grander than methodology. Donella Meadows was known as much for nurturing positive outcomes as she was for delving into the science behind global dilemmas. She reminds readers to pay attention to what is important, not just what is quantifiable, to stay humble, and to stay a learner.

In a world growing ever more complicated, crowded, and interdependent, Thinking in Systems helps readers avoid confusion and helplessness, the first step toward finding proactive and effective solutions.

Available at Amazon.com

Discovering Requirements: How to Specify Products and Services

by Ian Alexander, Ljerka Beus-Dukic

Publisher: Wiley (February 2009), ISBN: 978-0-470-71240-5

Publishers Description

Do you need to know how to create good requirements? Discovering Requirements offers a set of simple, robust, and effective cognitive tools for building requirements. Using worked examples throughout the text, it shows you how to develop an understanding of any problem, leading to questions such as:

What are you trying to achieve? Who is involved, and how?

What do those people want? Do they agree? How do you envisage this working?

What could go wrong?

Why are you making these decisions? What are you assuming?

The established author team of Ian Alexander and Ljerka Beus-Dukic answer these and related questions, using a set of complementary techniques, including stakeholder analysis, goal modelling, context modelling, storytelling and scenario modelling, identifying risks and threats, describing rationales, defining terms in a project dictionary, and prioritizing.

This easy to read guide is full of carefully-checked tips and tricks. Illustrated with worked examples, checklists, summaries, keywords and exercises, this book will encourage you to move closer to the real problems you’re trying to solve. Guest boxes from other experts give you additional hints for your projects.

Invaluable for anyone specifying requirements including IT practitioners, engineers, developers, business analysts, test engineers, configuration managers, quality engineers and project managers.

A practical sourcebook for lecturers as well as students studying software engineering who want to learn about

requirements work in industry.

Once you’ve read this book you will be ready to create good requirements!

More information

Requirements Engineering for Software and Systems

By Phillip A. Laplante

Publisher: Auerbach Publications; 1 edition (March 27, 2009), ISBN-10: 1420064673, ISBN-13: 978-1420064674

Publishers Description: With an intentional focus on software-intensive systems, this volume provides a probing and comprehensive review of the state of technology and developments in intelligent systems, soft computing techniques, and their diverse applications in manufacturing. To illustrate key ideas associated with requirements engineering, the text presents three common example systems: an airline baggage handling system, a point-of-sale system for one location of a large pet store chain, and a system for a “smart home” in which one or more PCs control various aspects of the home’s functions. The selected systems encompass a wide range of applications—from embedded to organic, covering industrial and consumer uses.

Available at Amazon.com.

The Foundations & Pragmatics of Cognitive Work Analysis

by Gavan Lintern, Cognitive Systems Design, Edition 1.0

Synopsis: Cognitive Work Analysis is notoriously difficult for those who encounter it for the first time. It is a complicated and expansive system of analysis, differing in scope and strategy from much of what currently goes on in cognitive engineering. There is little to do about this; the system is what it is for good reasons. Given that state of affairs, we need cohesive, pedagogical accounts of this analytic framework to guide beginners through their early efforts.

Cognitive Work Analysis remains difficult to understand and to execute because we have not made the foundational theory behind it sufficiently explicit and also because we have not been sufficiently tutorial in our approach to explaining it. In believing that these two things go together, I outline the theoretical basis for this framework of analysis and then offer a tutorial example that shows how the concepts can be applied.

Although I offer some refinements of Cognitive Work Analysis, there is nothing fundamentally new in this book. Rather, this is an effort to assemble the important ideas of Cognitive Work Analysis into a treatment that encourages solid understanding via a process of establishing specific concepts as knowledge anchors and then expanding that knowledge into a comprehensive system.

Available as a free download at www.cognitivesystemsdesign.net.

The Engineering Design of Systems: Models and Methods, 2nd Edition

By Dennis M. Buede, PhD

Publisher: John Wiley and Sons Ltd, Feb 2009, 516 pages. ISBN: 978-0-470-16402-0

Publisher’s Description: The Engineering Design of Systems compiles a wealth of information from diverse sources, providing a unique, one-stop reference of current methods and models for systems engineering. This updated edition features important new information on Systems Modeling Language (SysML), more descriptive material on usage scenarios based on literature from use case development, updated homework assignments, and use of the software product CORE to generate the SysML figures. This book serves as an excellent introductory reference suitable for students and professionals alike.

Availability of Standards for Purchase

One source of standards that are sometimes difficult to track down is www.techstreet.com. Techstreet has over 80 browseable catalogues from leading technical publishers, including ISO, ANSI, ASTM, ASME, API, IEEE, IEC, DIN, BSI, MIL, ICC and many more.

Available at www.techstreet.com.

Another source is the ANSI Standards Store: http://webstore.ansi.org/default.aspx.

Using Agile to Deliver Value – Kanban, Flow and Cadence

By Karl Scotland

This excellent paper considers the application of Kanban to agile software development. Kanban is a “just-in-time” process for team members acquiring work tasks, having its origins in “lean” this and that. The paper discusses issues and concepts which are general in their application, including:

Kanban – Controlled Work Flow – Effective Work Cadence – Reliable Work

More information

Report on Systemic Root Cause Analysis of Program Failures

National Defense Industrial Association – Systems Engineering Division

In conjunction with Office of Under Secretary of Defense Acquisition, Technology & Logistics, Systems & Software Engineering Deputy Director, Assessments & Support

Synopsis: Synopsis: Since 2004, the U.S.A. Office of the Under Secretary of Defense for Acquisition, Technology and Logistics (USD(AT&L)), Systems and Software Engineering/Assessments and Support (SSE/AS) Directorate has been conducting Program Support Reviews (PSRs) for major defense programs to help identify and resolve program issues and risks; and ultimately improve the probability of program success. Through analysis of the PSR data, SSE/AS has identified systemic issues seen across Major Defense Acquisition Programs (MDAPs) and Major Automated Information Systems (MAIS) that impede acquisition success

Report Downloadable Here.

Conferences and Meetings

Conference on Systems Engineering Research (CSER) 2009

Loughborough, UK, 20 – 22 April, 2009

More information

Systems & Software Technology Conference (SSTC) 2009

“Technology: Advancing Precision”, 20-23 April 2009, Salt Lake City, Utah

More information

System of Systems Engineering Forum

27 – 29 April 2009, Washington, DC, USA

More information

The 7th International Workshop on Modelling, Simulation, Verification and Validation of Enterprise Information Systems (MSVVEIS-2009)

co-located with the International Conference on Enterprise Information Systems (ICEIS), 6 – 10 May, 2009, Milan, Italy.

More information

31st International Conference on Software Engineering (ICSE) 2009

Vancouver, Canada, May 16-24, 2009

More information

Early Aspects at ICSE: aspect-Orientated Requirements Engineering and Architecture Design (EA 2009)

to be held in conjunction with ICSE 2009: 31st International Conference on Software Engineering 09, May 18, 2009, Vancouver, Canada

More information

isee’s partner WSP presents an iThink and STELLA workshop

20 – 21 May, 2009. North Yorkshire, UK

More information

Software & Systems Engineering Essentials 2009

Steigenberger Hotel Berlin, Los-Angeles-Platz 1, 10789 Berlin, Germany Workshops – 25th May 2009, Conference – 26th & 27th May 2009

More information

ICMISE 2009: International Conference on Medical Information Systems Engineering

Tokyo, Japan, May 27-29, 2009

More information

EJC 2009 – 19th European Japanese Conference on Information Modelling and Knowledge Bases

Maribor, Slovenia, June 1-5, 2009

More information

13th IFAC Symposium on Information Control Problems in Manufacturing

June 3 – 5 2009. Moscow, Russia

More information

The 21st International Conference on Advanced Information Systems (CAiSE09)

June 8 – 12, 2009. Amsterdam, The Netherlands

More information

RefsQ`09 The 15th International Working Conference on Requirements Engineering: Foundation for Software Quality

June 8 – 9, 2009. Amsterdam, The Netherlands

More information

Exploring Modeling Methods in Systems Analysis and Design (EMMSAD) 2009

Held in conjunction with CAiSE’ 09. June 8 – 9, 2009. Amsterdam, The Netherlands

More information

The 10th Workshop on Business Process Modeling, Development, and Support (BPMDS’09)

Held in conjunction with CAiSE’ 09. June 8 – 9, 2009. Amsterdam, The Netherlands

More information

5th International Workshop on Enterprise & Organizational Modeling and Simulation (EOMAS 2009)

Held in conjunction with CAiSE’ 09. June 8 – 9, 2009. Amsterdam, The Netherlands

More information

The First International Workshop on Domain Engineering

In conjunction with CAiSE 2009, June 9, 2009, Amsterdam, The Netherlands

More information

International Workshop on Value-driven Engineering of Systems of Things (VEST 2009)

Held in conjunction with CAiSE’ 09. June 8 – 9, 2009. Amsterdam, The Netherlands

More information

14th International Conference on Reliable Software Technologies – Ada – Europe

Telecom Bretagne. June 8 – 12, 2009. Brest, France

More information

SEPG Europe 2009 – Software and Systems Process Improvement Conference

June 9 – 12, 2009. Prague, Czech Republic

More information

6th International Conference on Remote Engineering and Virtual Instrumentation (REV 2009)

June 22 – 25, 2009. Bridgeport, CT, USA

More information

PETRI NETS 2009

June 22 – 26, 2009. Paris, France

More information

TiSto 2009 – International Workshop on Timing and Stochasticity in Petri nets and other models of concurrency

A satellite event of Petri Nets 2009 30th International Conference on Application and Theory of Petri Nets and Other Models of Concurrency. June 23, 2009. Paris, France

More information

5th European Conference on Model-Driven Architecture Foundations and Applications

23 – 26 June 2009. Enschede, The Netherlands

More information

SENSUS 2009 Summer School

29 June – 3 July 2009. Keszthely, Hungary

More information

The 21st International Conference on Software Engineering and Knowledge Engineering (SEKE 2009)

Hyatt Harborside at Logan Int’l Airport, July 1 – 3, 2009. Boston, USA

More information

Third International Conference on Software Engineering Approaches for Offshore and Outsourced Development (SEAFOOD)

July 2 – 3, 2009. ETH Zurich, Switzerland

More information

SSIRI 2009 – The 3rd IEEE International Conference on Secure Software Integration and Reliability Improvement

8 – 10 July 2009. Shanghai, China

More information

T4CIA’09 – Testing Technologies and Tools for Critical Industry Applications

The 1st Workshop in conjunction with SSIRI 2009 8 – 10 July 2009. Shanghai, China

More information

WER’09: 12th Workshop on Requirements Engineering

July 16 – 17, 2009. Valparaiso, Chile

More information

INCOSE 19th Annual International Symposium (IS) 2009

July 20 – 23, 2009. Singapore

More information

3rd Annual International Workshop on Requirements Engineering for Services (REFS’09)

In conjunction with COMPSAC 2009, July 20 – 24, 2009. Seattle, Washington

More information

2nd IEEE International Workshop on Industrial Experience in Embedded Systems Design (IEESD 2009)

In conjunction with COMPSAC 2009, July 20 – 24, 2009. Seattle, Washington

More information

2009 International Conference of the System Dynamics Society

July 26 – 30, 2009. Albuquerque, New Mexico

More information

PICMET ’09 Conference: “Technology Management in the Age of Fundamental Change”

August 2 – 6, 2009. Hilton Portland and Executive Tower, Portland, Oregon, USA

More information

Improving Systems and Software Engineering Conference (ISSEC 2009)

Co-located with the 6th Annual Project Management Australia Conference (PMOZ 2009). August 10 – 12, 2009. Canberra, Australia

More information

Workshop on Logical Aspects of Fault Tolerance (LAFT)

(affiliated with LICS 2009). August 15, 2009. University of California, Los Angeles, USA

More information

17th IEEE International Requirements Engineering Conference (RE’09)

31 August – 4 September 2009, Atlanta, Georgia, USA

More information

1st Workshop on Service-Oriented Business Networks and Ecosystems (SOBNE ’09)

1 September 2009, at the IEEE EDOC 2009 Conference in Auckland, New Zealand

More information

European Systems & Software Process Improvement and Innovation (EuroSPI2)

September 2 – 4, 2009. University of Alcala, Spain

More information

AIAA Space 2009 – Joint Space Systems Engineering and Economics Track

Within the conference is a joint Space Systems Engineering and Economics Track that has room for slots for four space systems engineering papers. September 14 – 17, 2009. Pasadena, CA, USA

Download Call for Papers

Additional Conference Information

Third IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO’09)

(IEEE approval pending)

September 14 – 18, 2009. San Francisco, USA

More information

14th System Design Languages Forum

September 22 – 24, 2009. Ruhr-University of Bochum, Germany

More information

ICISE 2009 – International Conference on Industrial and Systems Engineering

September 23, 2009, Toronto, Canada

More information

Ninth International Workshop on Automated Verification of Critical Systems (AVoCS 2009)

Swansea University Computer Science, September 23 – 25, 2009.

More information

Education & Academia

New Training Program to Prepare Systems Engineers for the INCOSE Certified Systems Engineering Professional (CSEP) Designation

UMBC Training Centers has added a valuable new course to its Engineering training curriculum. This course will prepare individuals for the rigorous Certified Systems Engineering Professional (CSEP) certification.

This certification, from the International Council on Systems Engineering (INCOSE), is a highly sought after certification for those engineers wanting to be recognized for their education, experience, and knowledge in the highly competitive field of Systems Engineering.

More information

Some Systems Engineering-Relevant Websites

http://www.easterbrook.ca/steve/?p=106

An interesting and formalised systems engineering challenge by Steve Easterbrook, a Professor of computer science at the University of Toronto, Canada.

http://www.bouwdienst.nl/leidraadse/

Guideline Systems Engineering for Public Works and Water Management

http://www.uxnet.org

UXnet (The User Experience Network) creates effective, functional, and strategic networks to enable cross-disciplinary collaboration between user experience professionals. UXnet connects people, organizations, resources, and ideas to enable the growth and maturation of User Experience as a practice, a community, and eventually a discipline.

http://gd.tuwien.ac.at/systeng/bahill/whatis/whatis.html

What is systems engineering? A Consensus of Senior Systems Engineers

http://en.wikipedia.org/wiki/Systems_engineering

http://www.springer.com/computer/programming/journal/766

The Requirements Engineering Journal. The journal is to provide a focus for disseminating new results about the elicitation, representation and validation of requirements of software-intensive information systems or applications.

http://ralphyoung.net

This is a web site dedicated to improving requirements practices. Their mission is to provide ideas, suggestions, recommendations, and resources for those who must understand and manage customer requirements in the systems and software-engineering world.

http://www.stsc.hill.af.mil/crosstalk/2009/03/index.html

CrossTalk, The Journal of Defense Software Engineering, is an approved Department of Defense journal. It’s mission is to encourage the engineering development of software in order to improve the reliability, maintainability, and responsiveness of the US war fighting capability and to inform and educate readers on up-to-date policy decisions and new software engineering technologies.

http://incoseitaly.blogspot.com/

Standards and Guides

ISO/IEC 15288:2008

Systems and software engineering – System life cycle processes

The publishers of this standard state:

ISO/IEC 15288:2008 establishes a common framework for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology. These processes can be applied at any level in the hierarchy of a system’s structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system’s life cycle. This is accomplished through the involvement of all interested parties, with the ultimate goal of achieving customer satisfaction.

ISO/IEC 15288:2008 also provides processes that support the definition, control and improvement of the life cycle processes used within an organization or a project. Organizations and projects can use these life cycle processes when acquiring and supplying systems.

ISO/IEC 15288:2008 concerns those systems that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities. When a system element is software, the software life cycle processes documented in ISO/IEC 12207:2008 may be used to implement that system element.

ISO/IEC 15288:2008 and ISO/IEC 12207:2008 are harmonized for concurrent use on a single project or in a single organization.

Editors note: A review of this standard will appear at www.ppi-int.com in the future, possibly over the next couple of months.

Related news:

Checklists and templates associated with ISO/IEC 15288:2008 were expected to be updated by March 2009 ISO/IEC TR 15271 Guide for ISO/IEC 12207 and ISO/IEC TR 19760 Guide for ISO/IEC 15288 will become ISO/IEC TR 24748. This document should be released in mid 2009

ISO/IEC 15026 System and Software Assurance is to be a four part document: Part 1 Concept and vocabulary

Part 2 Assurance cases

Part 3 System integrity levels Part 4 Assurance in the life cycle

Release is intended for early 2010

ISO/IEC 16326 Project Management is scheduled for release in mid 2009

Some Definitions to Close On

Integrated Product Team

“An organizational unit, staffed with necessary disciplines and stakeholder representatives that is responsible, accountable and empowered to take a product from requirements through to delivery.” (Halligan)

“A cross-functional, empowered team with a mission, budget and other resources for delivering a product or service that meets the needs of its customer or user. The IPT makes binding, team based decisions and ensures the interests of all stakeholders, customers, users, and vendors are represented.”, U.S.A. FAA

“Team composed of representatives from appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision making. There are three types of IPTs: overarching IPTs (OIPTs) that focus on strategic guidance, program assessment, and issue resolution; working level IPTs (WIPTs) that identify and resolve program issues, determine program status, and seek opportunities for acquisition reform; and program level IPTs that focus on program execution and may include representatives from both government and after contract award industry.” USAF

“Cross functional team formed for the specific purpose of delivering a product for an external or internal customer. A group of individuals who have complementary skills and are committed to a common purpose, approach, and performance objectives and hold themselves mutually accountable.”, State of Texas

Integrated Project Team

“The body responsible for managing a project from Concept to Disposal. Its main tasks include developing the SRD, devising equipment solutions to meet that requirement, and managing the procurement and in-service support of the equipment. The Smart Procurement IPT is characterized by its ‘cradle to grave’ responsibility, its inclusion of all the skills necessary to manage its project, and its effective and empowered leader.”

www.ams.mod.uk/ams/content/docs/ils/ils_web/glossary.htm

“A multi-disciplinary team led by a project manager responsible and accountable for planning, budgeting, procurement and life-cycle management of the investment to achieve its cost, schedule and performance goals. Team skills include: budgetary, financial, capital planning, procurement, user, program, architecture, earned value management, security, and other staff as appropriate.”

OMB Circular No. A–11 Section 300—Planning, Budgeting, Acquisition, And Management Of Capital Assets (2005)

“Integrated Project Teams are cross functional teams ranging from requirements management through project management, engineering, technical skills and equipment support.”, Bright*Star New Zealand (formerly IIR)

“The Integrated Project Team is the body responsible for managing a project from concept to disposal.”, U.K. National Audit Office

Integrated Program Team

No definitions found.

Project Performance International News

Managing Technical Projects 2-Day Course in Brazil

Design, develop, produce and deliver a 2-day course on systems engineering management in 5 days start to finish – yes we can! Whilst not the way PPI would choose to work, when a client needs the impossible, we will try to move heaven and earth to make it happen. In this case, this month (April 2009), we did.

New PPI LinkedIn and Twitter

PPI has also created a LinkedIn group for past delegates. The aim of this group is to encourage discussion between past course delegates and to create a community in which you may ask questions or gain assistance from like-minded people.

Managing Director and Course Presenter, Mr. Robert Halligan, will be posting links to useful articles and tweeting Systems-Engineering related quotes regularly on the social networking platform, Twitter.

Past delegates join PPI’s LinkedIn Group Follow Mr. Robert Halligan on Twitter

Project Performance International Events

Systems Engineering 5-Day Courses

Upcoming locations include:

São José dos Campos, Brazil London, UK (COURSE FULL)

Ankara, Turkey

Pretoria, South Africa (COURSE FULL) Amsterdam, The Netherlands

Melbourne, Australia

View 2009 Systems Engineering Course Schedule

Requirements Analysis and Specification Writing 5-Day Courses

Upcoming locations include:

Adelaide, Australia Las Vegas, USA

Amsterdam, The Netherlands Cape Town, South Africa

View 2009 RA&SW Course Schedule

OCD/CONOPS 5-Day Courses

Upcoming locations include:

Melbourne, Australia Adelaide, Australia

View 2009 OCD/CONOPS Course Schedule

Software Engineering 5-Day Courses

Upcoming locations include:

Munich, Germany Adelaide, Australia

View 2009 Software Engineering Course Schedule

PPI Upcoming Participation in Professional Conferences

20 – 23 April, 2009 – Systems & Software Technology Conference 2009 – Salt Lake City, UT, USA (Exhibiting) 30 June – 2 July, 2009 – Defence + Industry 2009 – Adelaide, Australia (Exhibiting)

20 – 23 July, 2009 – INCOSE International Symposium 2009 – Singapore (Exhibiting)

Kind regards from the SyEN team:

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

Alwyn Smit, Editor, email: asmit@ppi-int.com

Julie May, Production, email: jmay@ppi-int.com

Michael Halligan, Production, email: halliganm@ppi-int.com

Project Performance International

PO Box 2385, Ringwood, Vic 3134 Australia Tel: +61 3 9876 7345

Fax: +61 3 9876 2664

Web: www.ppi-int.com

Email: contact@ppi-int.com

Copyright 2009 Project Performance (Australia) Pty Ltd, trading as Project Performance International Tell us what you think of SyEN: email to contact@ppi-int.com

If you do not wish to receive a copy monthly of SyEN in future, please reply to this e-mail with “Remove” in the subject line. All removals are acknowledged; you may wish to contact us if acknowledgement is not received within 7 days.

Disclaimer

No person should rely on the contents of this publication without first obtaining advice from a qualified professional person. This publication is provided free as a public service on the understanding that (1) the authors, consultants and editors are not responsible for the results of any actions taken on the basis of information in this publication, nor for

any error in or omission from this publication; and (2) the publisher is not engaged in rendering professional or other advice or services. The publisher, and the authors, consultants and editors, expressly disclaim all and any liability and responsibility to any person, whether a reader of this publication or not, in respect of anything, and of the consequences of anything, done or omitted to be done by any such person in reliance, whether wholly or partially, upon the whole or any part of the contents of this publication. Without limiting the generality of the above no author, consultant or editor shall have any responsibility for any act or omission of any other author, consultant or editor.

COPYRIGHT PROJECT PERFORMANCE (AUSTRALIA) PTY LTD, ABN 33 055 311 941. May only be copied and

distributed in full, and with this Copyright Notice intact.