Brought to you by Project Performance International (PPI)
SyEN #004 - January 15, 2009
SyEN: Informative reading for the project professional, containing scores of news and other items summarizing developments in the profession and 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 that meet requirements and maximize value delivered in accordance with the values of the stakeholders.
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.
The newsletter presents in-depth coverage of the month's news in systems engineering and directly related fields, plus limited information on PPI's activities and events. Please forward this e-mail to friends and colleagues who you think would be interested.
We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email to: firstname.lastname@example.org.
Featured Society: IEEE Systems Council
Systems Engineering Software Tools News
Systems Engineering Books, Reports, Articles and Papers
Conferences and Meetings
Some Systems Engineering-Relevant Websites
Standards and Guides
Some Definitions to Close On - OCD and CONOPS
A Quotation to Open On
“Make everything as simple as possible, but not simplier." - Albert Einstein
What is Cognitive Systems Engineering and Why Should You CareGavan Lintern
General Dynamics, Advanced Information Systems
Dayton, Ohio 45431-1289
Large-scale socio-technical systems are cognitive systems and function as such through the individual and collaborative cognitive work of the humans in the system. As major systems have become more information intensive and more distributed, the difficulty of addressing cognitive challenges has become a troubling area for Systems Engineering. The discipline of cognitive systems engineering has methods and tools that can be brought to bear on the challenge of designing system functionality that will support human participants as the undertake the essential cognitive work.
While the specialty area of Human Systems Integration is intended to resolve issues of cognitive design as well as other Human Factors issues, I generally find the cognitive design work undertaken within the framework of this specialty area to be unprincipled and insubstantial. In particular, insights generated over the past 20 years within the discipline of Cognitive Systems Engineering do not have any worthwhile level of visibility within Systems Engineering.
In this series of news letter articles, I will describe some of those insights and outline some of the analytic and design methods that that help us take advantage of those insights. I will commence in the first article by defining important terms. In the second article, I will outline important features of the practice of Cognitive Systems Engineering, discuss the distributed nature of cognitive systems and introduce my personal perspective on design. In the final two articles, I will outline two popular frameworks for Cognitive Systems Engineering. While these two frameworks are viewed as competitive frameworks within the discipline of Cognitive Systems Engineering, I will argue that Systems Engineers will be better served by viewing them as complementary. Finally, I will illustrate how each of these frameworks can be fitted into existing Systems Engineering processes to contribute to the design of large-scale socio-technical systems.
Cognitive Work. Cognitive work involves the cognitive activities of knowing, understanding, planning, deciding, problem solving, integrating, analyzing, synthesizing, assessing and judging. It is common within behavioral science to distinguish cognition from perception and action. Operationally at least, that distinction cannot be supported. As pointed out by Gibson (1979) in the exposition of his ecological approach to visual perception, one cannot separate these functions in any principled way. Thus, cognition is a system in which we perceive, think and act and in which meaning, the centerpiece of cognition, emerges from the relationship between them (Lintern, 2000).
The term work has a special role to play in this discussion. Work has functional requirements based in the purpose of the work mission. It also has constraints, some of them physical (we cannot violate physical laws) and some of them intentional (we should not violate human laws of conduct and human values). Many of the physical constraints are imposed by the technological resources that have made available while our adherence to intentional constraints is often shaped by the effectiveness of technological resources in communicating and reminding workers of specific attributes of purpose, laws, principles of conduct and values. The analysis of cognitive work seeks to identify purpose, constraints (both physical and intentional) and processes (both those specified in design and of those developed by workers on the job).
Cognitive Systems Engineering. Cognitive Systems Engineering is a professional discipline that uses formal methods of cognitive analysis and cognitive design to ensure that cognitive work is both efficient and robust. The aim is amplify and extend the human capability to know, perceive, decide, plan, act and collaborate by integrating system functions with the cognitive processes they need to support. Note that this is not about integrating humans into systems or humans with systems. The focus is on the cognitive work with a particular emphasis on how we might employ technological functionality to support that work.
Cognitive Systems Engineering deals with socio-technical systems in which the work is information intensive. The socio in socio-technical refers to the social processes of communication, cooperation and competition.
Human Systems Integration. Within Systems Engineering, Cognitive Systems Engineering can be comfortably located in the specialty area of Human Systems Integration. The latest edition of the INCOSE Systems Engineering Handbook (V 3.1, August 2007, Appendix M ) defines Human Systems Integration as the interdisciplinary technical and management processes for integrating human considerations within and across all system elements. This definition and the term itself implies that we wish to integrate humans with systems or possibly, that we wish to integrate humans into systems.
Both the term, Human Systems Integration, and the INCOSE definition can be taken to imply that the human should be subservient to technology and I find that many in the engineering professions assume this perspective at least implicitly. Less egregiously, some accord equal status to humans and technology. Although many Human Factors professionals and Cognitive Systems Engineers also express this latter view, I wish to insist that technology must be subservient to the human. Cognitive Systems Engineering should be directed at ensuring robust and effective coordination between the humans in the system and also ensuring that human functionality is supported and enhanced by technical functionality. The implication of my definition is that we do not want to integrate humans with technology but rather to integrate humans with humans and humans with work and use technological capabilities to facilitate that.
Cognitive Systems Engineering can be deployed to good effect in any information-intensive work domain. Health care, military command-and-control and industrial power generation are just three work domains that can benefit from the systematic analysis and design of cognitive work. The focus is on helping workers think more effectively by design of support technologies, work processes or training. In that regard, Cognitive Systems Engineering seems most relevant to the Human Systems Integration domains of Manpower, Training, Human Factors Engineering and Safety as defined in the INCOSE Systems Engineering Handbook (V 3.1, August 2007, Appendix M ).
That is not to belittle the remaining domains of Personnel, Environment, Occupational Health, Habitability and Survivability or even to claim that Cognitive Systems Engineering could not contribute in those areas but rather to point out that the current work in the Cognitive Systems Engineering does not currently offer much that is useful for those remaining domains.
Human factors engineering. Human factors engineering is a professional discipline that uses formal methods of analysis and design to ensure that work is both efficient and robust. Note the similarity of this definition to the one for Cognitive Systems Engineering; the only difference being that I have removed all references to cognition. Human factors engineering is a broader discipline that takes account of physical as well as cognitive work. Alternatively, it could be said that Cognitive Systems Engineering is a sub-discipline of Human Factors Engineering. The terms Ergonomics and Engineering Psychology are sometimes used instead of Human Factors Engineering. Some think of Ergonomics as a discipline that focuses primarily on physical work but that view is not universal. There is no useful distinction between Engineering Psychology and Human Factors Engineering.
I have initiated this series of articles with definitions because I often perceive confusion or uncertainty about what these terms mean. If Cognitive Systems Engineering is to make any sense at all, a solid base in foundational definitions crucial ideas about Cognitive Systems and Cognitive Systems Engineering. In the next article in this series I will introduce some central ideas about Cognitive Systems and Cognitive Systems Engineering.
Gibson, J.J., 1979. The Ecological Approach to Visual Perception. Houghton Mifflin, Boston.
Lintern, G. (2000). An affordance-based perspective on human-machine interface design. Ecological Psychology, 12, 65-69.
More information on Gavan is available in the “People” section
The IEEE Systems Council facilitates interactions among communities of interest on system-level problems and applications. The Council believes that system-level thinking is essential in the world today, not only for technical systems but also for society at large. The Council addresses the discipline of systems engineering, including the issues and complexities of system-level and system-of-systems applications, focusing on the total systems effectiveness of complex integrated systems of United States and global significance.
The IEEE Systems Council integrates IEEE activities regarding aspects of multiple disciplines and specialty areas associated with the engineering of systems. This Council covers, but is not limited to the following:
The Council acts as an umbrella organization for fifteen IEEE member societies. The IEEE itself is non-profit organization, claiming to be the world's leading professional association for the advancement of technology, and having more than 375,000 members in over 160 countries.
For general information on the IEEE Systems Council, including the IEEE Systems Journal, IEEE Systems Conference and other IEEE Systems Council activities, the published contact is Council President Clyde Chittister at email@example.com. For specific information on the Council, or to participate in Council technical activities, the IEEE Systems Council contact is Vice President for Technical Operations Paul Croll at firstname.lastname@example.org.
iRise, Ravenflow add visuals to Requirements Composer
Two companies are riding shotgun with IBM’s release of its Requirements Composer requirements definition product. iRise and Ravenflow have brought out products of their own that complement Requirements Composer with visual capabilities.
MagicDraw SysML Plugin 16.0
The SysML Plugin has been updated to reflect changes based on the SysML 1.1 specification, feedback from users, and the latest discussions with OMG. The SysML plugin is an optional product for MagicDraw, adding System Engineering diagrams and modeling constructs for describing hardware, software, or heterogeneous systems.
Take an IRQA Tour - Requirements Engineering using IRQA
IRQA is a Requirements Definition and Management tool supporting the complete Requirements Engineering process, in an easy way, enhancing and empowering collaboration and communication by: - Aligning Business objectives with IT - Delivering exactly what was requested - Increasing customer satisfaction by delivering what was agreed - Delivering projects on-time and on-budget.
A Review of: "Systems Engineering with SysML/UML: Modeling, Analysis, Design by Tim Weilkiens (Author)"
A review by “Jon” of Tim Weilkiens’ book "Systems Engineering with SysML/UML: Modeling, Analysis, Design" appears at http://www.conceptech.co.uk/content/systems-engineering-sysmluml-review.
The TAGRI (They Aren't Gonna Read It) Principle of Software Development
Extreme Programming (XP) introduced the YAGNI (You Aren't Gonna Need It) principle which advises you to not invest time overbuilding software because you likely won't need the extra functionality anyway, and that the time you spent building stuff that you don't need could instead have been invested building stuff that you do need. There's a complementary concept with respect to documentation: TAGRI, They Aren't Gonna Read It. The basic idea is that very little of the documentation which gets created during software development actually gets read by the actual target audience. Recognizing this, you should model/document with a purpose and create agile documentation which reflects the true needs of the audience for that documentation; the best way to do this is to work closely with the people you are writing the documentation for, when you do that you discover that they may need something completely different than what you originally thought.
Web Article: Reviewing Test Cases
The main reason of the reviewing: increase test cases quality and therefore product quality.
As we know testers are involved on the Requirements Specification review process to provide the SQA knowledge to the requirements written. As testers are involved on the process they become experts on the area and on the application functionality and many times their knowledge helps avoid introducing future defects into the functionality that later the developer will code (it’s the phase that we called: defect prevention).
Web Book Review: Requirements Modelling and Specification for Service Oriented Architectureby Ian Graham
ISBN: 978-0-470-77563-9, October 2008
Synopsis: Many software developers often confuse requirements engineering with software specification and, as a result, build unusable systems, despite meeting specifications. Bringing together all the techniques needed by the modern software developer, here is a practical handbook to requirements engineering and systems specification for developers building systems within a service oriented architecture. It introduces the concepts of SOA and relevant standards and technology, such as Web services and ESBs, and then presents a range of modern requirements engineering techniques.
Web Article: Use cases - what comes before?
This article puts use cases into context by exploring where they sit within a project. Various methods for validating them within the wider context are also discussed. It also discusses what other techniques can or should be used in conjunction with them.
Web Article: The Agile PMO: Consistent Project Gatekeepers
In the last installment we took a look at the gap between what the Program Management Office (PMO) reports out, and what's actually happening in a project team. To begin to understand the nature of this gap, we’ll first take a look at what we use for project gatekeepers.
Web Article: Make or Break: Why Accurate Cost Estimation Is Key
The accuracy of your cost estimation process can make or break project success. Learn the strategies that will help you gain control of this key area and ensure future project profitability!
One of the greatest challenges for a project leader is to successfully deliver on all aspects of a project both according to the client's specifications and within the allotted budget. It is often the case that either one aspect or the other can be accomplished, but not necessarily both. When it comes to controlling costs, it is a critical first step to make appropriate estimations at the outset of a project. Being able to control costs is largely a matter of adhering to established guidelines, oftentimes by learning from previous projects and reacting to current circumstances efficiently and effectively.
Book Synopsis: Design Requirements Engineering: A Ten-Year Perspective
Lyytinen, K.J.; Loucopoulos, P.; Mylopoulos, J.; Robinson, W. (Eds.), 2009, XIII, ISBN: 978-3-540-92965-9
Synopsis: Since its inception in 1968, software engineering has undergone numerous changes. In the early years, software development was organized using the waterfall model, where the focus of requirements engineering was on a frozen requirements document, which formed the basis of the subsequent design and implementation process. Since then, a lot has changed: software has to be developed faster, in larger and distributed teams, for pervasive as well as large-scale applications, with more flexibility, and with ongoing maintenance and quick release cycles.
What do these ongoing developments and changes imply for the future of requirements engineering and software design? Now is the time to rethink the role of requirements and design for software intensive systems in transportation, life sciences, banking, e-government and other areas. Past assumptions need to be questioned, research and education need to be rethought.
This book is based on the Design Requirements Workshop, held June 3-6, 2007, in Cleveland, OH, USA, where leading researchers met to assess the current state of affairs and define new directions. The papers included were carefully reviewed and selected to give an overview of the current state of the art as well as an outlook on probable future challenges and priorities. After a general introduction to the workshop and the related NSF-funded project, the contributions are organized in topical sections on fundamental concepts of design; evolution and the fluidity of design; quality and value-based requirements; requirements intertwining; and adapting requirements practices in different domains.
Book Synopsis: A Practical Guide to SysML: The Systems Modeling Language
Sanford Friedenthal, Alan Moore, Rick Steiner, Year of Publication: 2008, ISBN:0123743796
Synopsis: Systems engineers and architects must understand how all the parts of a system work together to satisfy its requirements. SysML is a general purpose graphical modeling language used to specify, analyze, and design systems that may include hardware, software, and personnel. It allows engineers to describe how a system interacts with its environment, and how its parts must interact to achieve the desired system behavior and performance. The SysML model provides a shared view of the system, enabling a design team to surface issues early and prevent problems that would otherwise delay development and degrade design quality. Since SysML is based on UML, it also facilitates integration between systems and software development. SysML is now being adopted by companies across a broad range of industry, including Aerospace and Defense, Automotive, and IT System Developers. This book provides a comprehensive and practical guide for modeling systems with SysML. It includes a full description of the language along with a quick reference guide, and shows how the language can be applied to specify, analyze, and design systems. It contains examples to help readers understand how SysML can be used in practice. The book also includes guidance on how an organization or project can transition to model based systems engineering using SysML, with considerations for processes, methods, tools, and training.*The authoritative guide for understanding and applying SysML*Authored by the foremost experts on the language*Language description, examples, and quick reference guide included.
Web Article: Writing Effective Requirements Specifications
The Goddard Space Flight Center's (GSFC) Software Assurance Technology Center (SATC) has developed an early life cycle tool for assessing requirements that are specified in natural language. The Automated Requirements Measurement (ARM) tool was used to analyze more than 50 NASA System/Software Requirements Specification (SRS) documents. ARM reports were used to focus human analysis on specific aspects of the documentation practices exhibited by these documents. Several significant weaknesses were identified. This paper identifies the underlying problems that produce these deficiencies and recommends methods that can be used to prevent such problems.
Web Article: New Titles in Systems Engineering & Management
Book Synopsis: Systems of Systems Engineering: Principles and Applications
By Mo Jamshidi, Publisher: CRC, Publication Date: 2008-11-06, ISBN-10 / ASIN: 1420065882, ISBN-13 / EAN: 9781420065886
Synopsis: As technology presses forward, scientific projects are becoming increasingly complex. The international space station, for example, includes over 100 major components, carried aloft during 88 spaces flights which were organized by over 16 nations. The need for improved system integration between the elements of an overall larger technological system has sparked further development of systems of systems (SoS) as a solution for achieving interoperability and superior coordination between heterogeneous systems.
A Pioneering Look at the Future of Systems Integration
Systems of Systems Engineering: Principles and Applications provides engineers with a definitive reference on this newly emerging technology, which is being embraced by such engineering giants as Boeing, Lockheed Martin, and Raytheon. The book covers the complete range of fundamental SoS topics, including modeling, simulation, architecture, control, communication, optimization, and applications. Containing the contributions of pioneers at the forefront of SoS development, the book also offers insight into applications in national security, transportation, energy, and defense as well as healthcare, the service industry, and information technology.
System of systems (SoS) is still a relatively new concept, and in time numerous problems and open-ended issues must be addressed to realize its great potential. Systems of Systems Engineering offers a first look at this rapidly developing technology so that engineers are better equipped to face such challenges.
INCOSE International Workshop (IW) 2009
January 31 – February 3, 2009, San Francisco, CA USA
INCOSE Los Angeles Chapter (INCOSE-LA) 2009 Mini-Conference
February 7, 2009, Loyola Marymount University (LMU), Los Angeles CA
Program Management Academy Workshop: Getting Great RequirementsFeb 20, 2009. 8:30 am - 4:30 pm (Pacific Time), Courtyard by Marriott, 15868 SW Sequoia Parkway, Tigard, Oregon 97224, USA http://www.regonline.com/Checkin.asp?EventId=680178
Open Design Spaces supporting User Innovation (ODS`09) in conjunction with 2nd International Symposium on End User Development (EUD 2009)
March 2, 2009 Siegen, Germany
MBSE’09, Second International Conference on Model-Based Systems Engineering
Herzeliya and Haifa, Israel, March 2-5, 2009
Third Workshop on Engineering Complex Distributed Systems (ECDS 2009)
March 16-19, 2009, Fukuoka, Japan
International Conference on Complex, Intelligent and Software Intensive Systems (CISIS) 2009
March, 16th - 19th 2009, Fukuoka Institute of Technology (FIT), Fukuoka, Japan
Fifth Workshop on Model-Based Testing (MBT) 2009
March 22, 2009, York, UK
The 2nd International Conference on Industrial Informatics and Systems Engineering (IISE 2009)
Leipzig, Germany, 23-25 March 2009
IEEE International Systems Conference
Vancouver, Canada, March 23-26, 2009
INCOSE U.K. Annual Spring Conference
March 30 – April 1, 2009
The International Council on Systems Engineering Spring 09 Conference
April 2 – 4, 2009
American Society for Engineering Education (ASEE) Spring 2009 Northeast ConferenceUniversity of Bridgeport, April 3-4, 2009
The First NASA Formal Methods SymposiumApril 6 - 8, 2009 Moffett Field, California
IDEAS 2009- XII Iberoamerican Conference on Requirements Engineering and Software Environments
Medellín, Colombia, 13-17 April 2009
Conference on Systems Engineering Research (CSER) 2009
Loughborough, UK, 20 - 22 April, 2009
Systems & Software Technology Conference (SSTC) 2009"Technology: Advancing Precision", 20-23 April 2009, Salt Lake City, Utah
31st International Conference on Software Engineering (ICSE) 2009
Vancouver, Canada, May 16-24, 2009
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
Software & Systems Engineering Essentials 2009
Steigenberger Hotel Berlin, Los-Angeles-Platz 1, 10789 Berlin, Germany Workshops - 25th May 2009, Conference - 26th & 27th May 2009
ICMISE 2009: International Conference on Medical Information Systems Engineering
Tokyo, Japan, May 27-29, 2009
EJC 2009 - 19th European Japanese Conference on Information Modelling and Knowledge Bases
Maribor, Slovenia, June 1-5, 2009
13th IFAC Symposium on Information Control Problems in ManufacturingMoscow, Russia, 3-5 June 2009
RefsQ`09 The 15th International Working Conference on Requirements Engineering: Foundation for Software QualityAmsterdam, Holland, June 8-9, 2009
Exploring Modeling Methods in Systems Analysis and Design (EMMSAD) `098-9 June 2009, Amsterdam, The Netherlands
held in conjunction with CAiSE' 09
The 21st International Conference on Software Engineering and Knowledge Engineering (SEKE 2009)
Hyatt Harborside at Logan Int'l Airport, Boston, USA, July 1 - July 3, 2009
The First International Workshop on the Critical Computer Based Systems (CCBS`09) 2009
Monte Carlo Resort, Las Vegas, Nevada, USA (July 13-17, 2009)
INCOSE 19th Annual International Symposium (IS) 2009
July 20-23, 2009, Singapore
2009 International Conference of the System Dynamics Society
Albuquerque, New Mexico, July 26 - 30, 2009
PICMET '09 Conference: "Technology Management in the Age of Fundamental Change"
August 2 - 6, 2009, Hilton Portland and Executive Tower, Portland, Oregon, USA
17th IEEE International Requirements Engineering Conference (RE`09)31 August - 4 September 2009, Atlanta, Georgia, USA
AIAA Space 2009 - Joint Space Systems Engineering and Economics Track
Pasadena, CA, USA, 14-17 September 2009. Within the conference is a joint Space Systems Engineering and Economics Track that has room for slots for four space systems engineering papers.
The URL to download the Call For Papers is: http://www.aiaa.org/events/space/09-0038_Call%20for%20papers_final.pdf
The URL for additional conference information is: http://www.aiaa.org/content.cfm?pageid=230&lumeetingid=2074
ICISE 2009 - International Conference on Industrial and Systems Engineering23 September 2009, Toronto, Canada
Ninth International Workshop on Automated Verification of Critical Systems (AVoCS 2009)
Swansea University Computer Science, 23-25 September 2009
ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems (formerly the UML series of conferences)
Denver, Colorado, USA, October 4-9, 2009
Track Systems Engineering 2009Munich, Germany, 7 to 8 October 2009
Formal Methods for Industrial Critical Systems (FMICS) 2009
November 2-3, 2009, Eindhoven, The Netherlands
28th International Conference on Conceptual Modeling9-12 November, 2009, Gramado, RS, Brazil
Research Experience for Undergraduates in Systems Engineering for Healthcare, University of Maryland
The Institute for Systems Research at the University of Maryland is inviting applications to the Summer 2009 Research Experiences for Undergraduates program, Systems Engineering for Improving Health Care. This program is pending funding by the National Science Foundation. The program is to run from June 1 to August 7, 2009. Applications are due on February 1, 2009.
Systems Engineering Fundamentals - CALTECH
The Systems Engineering (SE) Fundamentals Certificate Program is designed to provide comprehensive coverage of the field of systems engineering. The program is intended for those beginning their systems engineering careers or those desiring to reacquaint themselves with the breadth of systems engineering activities.
Acquisition Systems Engineering – CALTECH
Acquisition Systems Engineering (SE) is a four part program generally held over a six week period and designed to provide comprehensive coverage of the field of systems engineering in the acquisition environment. The program is intended for those beginning their systems engineering careers or those desiring to reacquaint themselves with the breadth of systems engineering activities. The program is taught with a combination of formal presentation materials and in-class exercises. The instructors provide practical examples and lessons learned from their own experience in terms of what works and what doesn't work in informal discussion that is tailored to the needs, interests, and abilities of the program participants.
Advanced Systems Engineering for DoD Systems - CALTECH
The Systems Engineering Center of the California Institute of Technology Industrial Relations Center provides training in advanced systems engineering specifically focused on the defense environment. The Advanced Systems Engineering for DoD Systems certificate program focuses on the application of sophisticated tools and methods to address today’s issues in DoD system development and maintenance.
Post-doc Model Driven Engineering (RT/E systems) near Paris
The laboratory LISE (Model Driven Engineering Laboratory for embedded and real-time systems), part of the Laboratoire d' Intégration des Systèmes et des Technologies (450 researchers in the field of software-intensive systems, see http://www-list.cea.fr/) has an open position for a research assistant. The candidate must hold a PhD or equivalent with top performance in a field that is closely related to computer science. He/she should have a good background in middleware technology and/or the embedded and realtime domain.
Shanghai Jiao Tong University (SJTU) Embraces Systems Engineering
The Shanghai Jiao Tong University (SJTU), Shanghai, China feels that it has taken the lead in the management system reform in the institutions of higher learning in China, regaining its vigor and vitality as well as momentum for rapid growth as never seen before. The SJTU feels that a number of its disciplines have been advancing towards the world's first-class level, such as communication and electronic system engineering, naval architecture and ocean engineering, automatic control, composite materials, and metal plasticity processing. A batch of burgeoning branches of learning have occupied an important position in the country, including systems engineering.
In the new century, SJTU has formulated a grand blueprint for future development and is determined to make continued efforts to build itself into a first class university in the world.Gavan Lintern, PhD
Dayton Ohio, 937 602 5215, email@example.com
Gavan Lintern earned his Ph.D. (1978) in Engineering Psychology from the University of Illinois.
He has worked in aviation-related human factors research at the Aeronautical Research Laboratories, Melbourne from 1971 to 1974, and in flight simulation research on a US Navy program in Orlando, Florida from 1978 to 1985. He returned to the University of Illinois in 1985 to take up a position as a faculty member at the Institute of Aviation. He was awarded tenure in 1991 and remained in that position until 1997. He has subsequently worked on projects related to cognitive systems design and training systems design for the Australian Defense Science & Technology Organization in Melbourne (Australia), Aptima Inc in Boston and General Dynamics in Dayton.
His primary areas of expertise are in cognitive analysis and design of complex knowledge and information systems, instructional system development for aviation and information-intensive systems, and e-Learning development of professional and technical courseware. He has high-level skills in Cognitive Work Analysis, Ecological Interface Design, Brahms human workflow modeling and web design. He is currently working on design of Command & Control systems, development of an optimum manning framework, and integration of Cognitive Engineering with Systems Engineering.
He has over 30 publications in reviewed journals and numerous symposium papers and book chapters.
Awards and Affiliations
UK Major Defence Projects Report Released
The National Audit Office of the United Kingdom has published a report on the cost, time and capability achievement performance of 20 of the UK’s largest Defence projects, for the year ending 31 March, 2008:Ministry of Defence: Major Projects Report 2008
Publication date: 18 December 2008
In summary, the NAO concluded that, for the period of the Report, the forecast aggregate costs of the 20 projects increased by £205 million, and there was an additional 96 months aggregate slippage. Of the 20 projects, 15 are currently forecasting to meet all of their Key User Requirements. The Report also covered ten projects which are still in an Assessment Phase. This report, together with reports for other years commencing 1999, can be downloaded at:
Patent Application Lodged for System and Method for Verifying and Testing System Requirements
The following patent application was lodged in the United States on 27 November 2008, by Israeli inventors Peleg Yiftachel, Dan Goldwasser, and Yuval Rapaport-Rom:
USPTO Application #: 20080295079
Title: System and method for verifying and testing system requirements
Abstract: There is provided in accordance with embodiments of the present invention a method and a system for testing and verifying a requirements specification of a system comprising describing the requirements specification in a REQUIREMENTS ENGINEERING LANGUAGE (REL), simulating an execution of a scenario of the REL, and identifying logical faults in said requirements specification based on said simulating. Accordingly, the system for testing and verifying of requirements specification of a system comprising a modeling and testing component to build a model of the requirements specification, and a dynamic testing component to test the requirements specification by execution of at least one simulation cycle.
The present invention relates in general to a system and method for verifying and testing system requirements. More particularly, the present invention relates to a system and method for writing system specifications and verifying the specifications by simulation.
Background of the Invention: Software development is a process typically made of several phases. First, system requirements are gathered and analyzed. This is known as the Requirements phase. Next, in the Design phase, system requirements are transformed into design. Then, during the Implementation phase, the design is built or programmed into the actual system. The system is tested against the original requirements during the Testing phase. The last phase is typically known as Operation and Maintenance. In this phase the system is installed and maintained at a customer site.
Specifying system requirements is an essential phase of every system development process, as all following stages of development depend on the correct capturing and understanding of the system during the Requirements phase. Accordingly, errors or faults that are left unnoticed at this phase may cause wrong decisions at later phases, resulting in systems that either miss customers' needs or are littered with malfunctions, known as “bugs”. Such bugs may occur because the specified system requirements were incoherent, inconsistent, incomplete or ambiguous.
Research shows that the cost of fixing a bug at the Requirements phase grows exponentially if the bug is caught later in the development process. The importance of accurate and complete specification of system requirements has prompted much research focusing on improving current methods.
One approach of modeling systems is by the use of Abstract Machines. An Abstract Machine is described as using the Abstract Machine Notation (AMN). AMN is a state-based formal specification language, using a collection of mathematically based techniques for system requirements specification. An Abstract Machine typically comprises a state together with operations on that state. In a specification and a design of an Abstract Machine the state is modeled using notions like sets, relations, functions, sequences etc. The operations are modeled using pre and post-conditions using AMN. The method prescribes how to check the specification for consistency (preservation of invariant) and how to check designs and implementations for correctness (correctness of data refinement and correctness of algorithmic refinement). An example of the use of AMN may be found in the B-Method, developed by B-Core. The B-Method, however, does not perform ambiguity checks, completeness checks, or temporal invariant preservation.
Using languages for expressing structured, declarative system models, and automatically analyzing properties of those models, using first order logic, is another approach. The formal specification notation Z, useful for describing computer-based systems, is based on Zermelo-Fraenkel set theory and first order predicate logic. It has been developed by the Programming Research Group (PRG) at the Oxford University Computing Laboratory (OUCL) and elsewhere since the late 1970s.
Based on models written in formal languages such as Z, tools that support such languages can generate instances of invariants, simulate the execution of operations (even those defined implicitly), and check user-specified properties of a model. The Alloy language, emanating from Z, was developed by the Software Design Group at the MIT Laboratory for Computer Science, is an example of such a language. The Alloy Analyzer is a tool for analyzing models written in Alloy. Alloy and its analyzer have been used primarily to explore abstract software designs. Alloy therefore focuses on the Design and Implementation stages of the development process, rather than on requirements engineering. Moreover, it lacks the ability to verify temporal invariants.
ZANS is an animation tool for Z specifications. ZANS was developed by a software engineering group at the School of Computer Science, Telecommunications and Information System at the DePaul University. The main goals of ZANS are: to facilitate validation of Z specifications; to experiment design refinement and code synthesis based on Z specifications. Currently, it supports the following features: type checking of Z specifications; expansion of schema expressions; evaluation of expressions and predicates; execution of operation schemas. ZANS does not perform ambiguity checks, completeness checks, or temporal invariant preservation.
Z/EVES uses state-of-the-art formal methods techniques, integrating a specification notation with an automated deduction capability. The resulting system supports the analysis of Z specifications in several ways: syntax and type checking, schema expansion, precondition calculation, domain checking, and general theorem proving. The Z/EVES methods were developed by ORA Canada. Z/EVES does not perform ambiguity checks, completeness checks, or temporal invariant preservation.
The Unified Modeling Language (UML), developed by the Object Management Group (OMG), represents yet another approach. The UML comprises of 13 diagrams that capture different views of a system, during its early requirements and design phases of development. The Use Case diagram is used for specifying system requirements. Robustness diagrams, a part of the Agile Modeling methodology developed by Scott W. Ambler, extend Use Cases. The basic idea of Robustness diagrams is to analyze the steps of a Use Case in order to validate the business logic within it and to ensure that the terminology is consistent with other Use Cases that users have previously analyzed. In other words, users can ensure that their Use Cases are sufficiently robust to represent the usage requirements for the system they are building. Another use of Robustness diagrams is to identify potential objects or object responsibilities to support the logic called out in the use case, effectively acting as a bridge to UML diagrams such as Sequence Diagrams and Class Diagrams. Robustness diagrams do not incorporate the ability to define invariants and properties, and thus any tool supporting Robustness Diagrams will inherently lack the ability to verify the preservation of such invariants.
The ASM thesis is that any algorithm can be modeled at its natural abstraction level by an appropriate ASM. Based upon this thesis, members of the ASM community have sought to develop a methodology based upon mathematics which would allow algorithms to be modeled naturally; that is, described at their natural abstraction levels. The ASM methodology aims at being able to describe the entire software life-cycle: requirements specification, design and implementation. It goes further to state that it will enable users throughout the process to validate their work against the ASM model. The ASM does not incorporate the ability to define temporal invariants, and therefore tools supporting ASM are not able to perform temporal invariant preservation tests.
Summary of the Invention: There is provided in accordance with embodiments of the present invention a method for testing and verifying a requirements specification of a system comprising describing the requirements specification in a REQUIREMENTS ENGINEERING LANGUAGE (REL), simulating an execution of a scenario of the REL, and identifying logical faults in the requirements specification based on the simulating.
There is further provided in accordance with embodiments of the present invention a system for testing and verifying of requirements specification of a system comprising a modeling and testing component to build a model of the requirements specification, and a dynamic testing component to test the requirements specification by execution of at least one simulation cycle. There is further provided in accordance with embodiments of the present invention a modeling and testing apparatus comprising a moderator component to translate a high-level specification requirements to a requirements engineering language, an object builder component to build a unique representation of the specification requirements, and a checker component to check characteristics of the unique representation.
There is further provided in accordance with embodiments of the present invention a dynamic testing apparatus comprising a requirements tests manager to define, simulate, and analyze a scenario, a simulator manager to coordinate the simulation sequence of the scenario, a dynamic verification manager to activate the checkers during the simulation sequence, and a simulation and verification manager to control the dynamic testing component.
University of Virginia (USA) Conducts Systems Engineering Projects in Mendoza, Argentina
The University of Virginia (UVA) during late December 2008/early January 2009 visited Mendoza, Argentina with an aim of its students conducting projects to expand their knowledge of systems engineering concepts through working on projects with two Mendoza companies: Pasrai, a small, Mendozan family-owned olive oil manufacturer, and AltaVista, a large wine producer.
The projects included:
The work included the identification of system goals and performance measures, the creation of alternative solutions, and and the evaluation of alternative solutions through analysis and modeling. The students were to deliver final oral presentations and written reports that matched the expectations of their Argentine clients.
Contact: Reid Bailey, Assistant Professor and Assistant to the Chair in Systems and Information Engineering, email firstname.lastname@example.org; Doug Sutton and Michael Ledwith (who co-lead the class)
The INCOSE Foundation
The INCOSE Foundation is a charitable organization with the stated goal of advancing the development of systems engineering through funded scholarships, research, and international forums. The Foundation solicits contributions from individuals, corporations, and other foundations worldwide.
The Foundation is a separate legal entity from the International Council on Systems Engineering (INCOSE), but both organizations are closely aligned in philosophy, strategic directions, and values. The Foundation has its own separate Board of Directors. The Foundation relies on contributions from INCOSE members, INCOSE chapters, INCOSE CAB companies and organizations, the rest of the worldwide engineering community, and the general public. Despite the economic downturn, the INCOSE Foundation expects to provide three scholarships (undergraduate and graduate), and one stipend to a working group in 2009.
The Foundation received its USA 501(c) (3) exempt status from the IRS on 30 September 2005. This enables all U.S. donors to claim a charitable deduction on their annual income tax submissions. The Foundation is exploring ways in which non-U.S. contributions can benefit individual donors.
Object Management Group (OMG) helps to create a component-based software marketplace by hastening the introduction of standardised object software.
ICH is a not-for-profit collaboratory of standards/industry groups, solution providers, testing/research organizations, and IT practitioners. ICH serves members and the general public by helping to advance the capability and integrity of information and communication infrastructures.
The Defense Technical Information Center (DTIC®) serves the DoD community as the largest central resource for DoD and government-funded scientific, technical, engineering, and business related information available today.
The UK Defence Standardisation (Dstan) is a free, helpdesk service aimed to service MOD and the Defence Industries standardization needs which is run by experts from Dstan. It also gives links to other MOD sites to act like this site, as service helpdesk's. Their mission is to 'Achieve Interpretability through Standardisation Excellence.'
The AIAA (American Institute of Aeronautics and Astronautics) for more than 65 years, has been the principal society of the aerospace engineer and scientist. It's purpose is, "to advance the arts, sciences, and technology of aeronautics and astronautics, and to promote the professionalism of those engaged in these pursuits.”
The American Society of Naval Engineers (ASNE) purpose is to; advance the knowledge and practice of naval engineering in public and private applications and operations, to enhance the professionalism and well-being of members, and to promote naval engineering as a career field. This site also contains links to other related sites, information on job openings, meetings and events, publications and scholarships.
IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system. IDEFØ was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT).
The European Cooperation for Space Standardisation (ECSS) is an initiative established to develop a coherent, single set of user-friendly standards for use in all European space activities.
Expert Choice's solutions ensure that organizations make accurate decisions that are aligned with their strategic business objectives. This is done by use of software, consulting and training to turn abstract goals into concrete actions.
OMG Advances Standards at Technical Meeting
Members of the Object Management Group' (OMG') met in Santa Clara, Calif., during the week of December 8-12, 2008.
The OMG Board of Directors voted to approve three specifications:
For this edition of SyEN, we focus on two terms that have become a source of great confusion because of the similarity of their names: Operational Concept Description (or Document - OCD) and Concept of Operations (CONOPS).
A Survey of Definitions of Operational Concept Description (OCD)
“The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used.” U.S. DoD, DI-IPSC-81430, 5 December, 1994
“Operational Concept: A verbal and graphic statement of an enterprise’s assumptions or intent in regard to an operation or a series of operations of a system or a related set of systems”, Guide for the Preparation of Operational Concept Documents, ANSI/AIAA G-043-200x Draft 2.0 29 August 2006
“Operational Concept Document: A document for recording an Operational Concept”, Guide for the Preparation of Operational Concept Documents, ANSI/AIAA G-043-200x Draft 2.0 29 August 2006
A Survey of Definitions of Concept of Operations (CONOPS)
“A Concept of Operations (CONOPS) evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or a particular end state for a specific scenario.”, Naval Warfare Development Command, U.S.A.
“CONOPS (Concept of Operations) is a verbal or graphic statement, in broad outline, of a commander’s assumptions or intent in regard to an operation or series of operations.”, U.S. DoD Joint Publication 1-02, also U.S. Secretary of the Air Force Air Force Policy Directive 10-28, 15 September 2003
“This is a statement of the commander's intent which expands why the force has been tasked to do the mission stated in paragraph 2. It tells what results are expected; how these results facilitate future operations; and how, in broad terms, the commander visualizes achieving those results (force as a whole).”, U.S. Army Field Manual FM 6-20-30, Chapter 2
“Concept of Operation. Concept de l'opération. Au niveau tactique, expression claire et concise qui énonce l'objectif que le chef s'est fixé et qui précisedans ses grandes lignes le déroulement de l'action ainsi que la répartition des missions des unités subordonnées.” www.gaia-airsoft.org/glossary.htm
“Concept of Operations – description of how an organization will implement a certain program or effort”, U.S. Department of Defense, “Continuous Process Improvement Transformation Guidebook”, May 2006
“Concept of Operations (CONOPS) — A verbal or graphic statement that clearly and concisely expresses what the joint force commander intends to accomplish and how it will be done using available resources. The concept is designed to give an overall picture of the operation”, U.S.A. Joint Publication 1-02, “Department of Defense Dictionary of Military and Associated Terms”, current 22 March 2007
Further Definitions of Concept of Operations (CONOPS) - Dissenting
A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users’ viewpoint.”, IEEE Std 1362-1998, IEEE Guide for Information Technology — System Definition — Concept of Operations (ConOps) Document -Description
“A ConOps describes how a community intends to use a contemplated system as a means to mitigate or suppress an actual or anticipated problem situation.”, Concept of Operations (ConOps) of a Systems Engineering Educational Community (SEEC), INCOSE-TP-2003-015-01 Version: 0, 15 March 2004
“Concept of Operations: describes the way the system works from the operator’s perspective”, INCOSE Systems Engineering Handbook, Version 3, INCOSE-TP-2003-002-03, June 2006
What to Make of All of This?
Putting aside for the moment the three dissenting (and relatively recent) definitions of CONOPS, the definitions establish two fundamentally different types of information, corresponding to OCD and CONOPS respectively.
OCD – a system-centric description of the intended users of a system, the intended uses of that system, how the system is to be used, and the external conditions during use. The OCD has traditionally served the purpose of a reference for fitness for intended use (i.e. for requirements validation, design validation and system validation).
CONOPS – a conceptual description of how an outcome is to be achieved. That is, a CONOPS is a form of solution description, limited to those aspects of the overall solution that relate to end-use. Hence the CONOPS has a lot in common with other standardized forms of conceptual (architectural) solution descriptions, such as system/subsystem design descriptions (SSDD), IEEE 1471 architectural design descriptions, some of the views of the architectural frameworks, and design databases accessed by CASE tools which employ proprietary and/or public domain languages such as SysML or UML. The CONOPS has traditionally served the purpose of conveying to stakeholders the operational part of the intended solution. In fact, the term has its origins in the military, where the CONOPS expressed the Commander’s intentions as to deployment and interactions of forces and technology to produce a desired military outcome.
More recently, and sadly, the similarity of names between OCD and CONOPS has led to institutionalised confusion, with the Institution of Electrical and Electronic Engineers (IEEE) releasing a standard for OCDs under the name CONOPS (IEEE 1362), and two different parts of the International Council on Systems Engineering (INCOSE) using the terms in conflicting ways in publications supposed to help people! In the latter case, INCOSE is working jointly with the AIAA to update the best (IMO) of the OCD guides (ANSI/AIAA OCD Guide), and is using the terms OCD and CONOPS in their traditional, and grammatically correct ways in this effort. However, in two other INCOSE publications, the term CONOPS is used to mean OCD. It is to be hoped that both IEEE and INCOSE will fix this mess! In the meantime, the need for the two different sets of information, each serving an important need, remains. My advice for any organization – make sure that the terms are clearly, rationally and consistently defined for use in the organization.
Look for lists of standards and guides for OCDs and CONOPS in the February 2009 edition of SyEN.
Robert Halligan, FIE Aust
First International Delivery of PPI’s New Software Engineering 5-Day Course
The first delivery outside Australia of PPI’s new 5-day course on software engineering will take place in Amsterdam over 19-23 January, 2009.
First Delivery of PPI Systems Engineering Training in Italy
PPI will deliver its first course in Italy, the very popular 5-day Systems Engineering for Technology-Based Projects and Product Developments, in the beautiful city of La Spezia, over 16-20 February, 2009. La Spezia is a coastal city on the north west coast in the region sometimes referred to as the Italian Riviera. The city, located between Genoa and Pisa, on the Ligurian Sea, hosts one of the major Italian military and commercial harbours.
First Delivery of PPI Systems Engineering Training in Spain
PPI will deliver its first course in Spain, an in-house delivery of its 5-day Systems Engineering for Technology-Based Projects and Product Developments, to an astronomical organization at Tenerife in the Canary Islands, Spain. Tenerife is the largest of the seven Canary Islands in the Atlantic Ocean, off the coast of Africa. The island has a mighty volcanic crater Cañadas del Teide, with a diameter of 20 kilometers, and the 3.718 meters high Teide in its center.
PPI to Deliver Systems Engineering Training Program to Large Multinational
PPI has been selected to provide a systems engineering training program to the engineering workforce in Australia of a large, technology-based multinational company operating in the civil and defence sectors. The program will commence in February, 2009.
PPI Free Systems Engineering Goldmine
Not strictly news, just a reminder of the availability to qualified applicants of free online access to about 1GB, and growing, of systems engineering resources.
Apply via: http://www.ppi-int.com.
Systems Engineering 5-Day Courses
Upcoming locations include:
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
Requirements Engineering 5-Day Courses
Upcoming locations include:
OCD/CONOPS 5-Day Courses
Upcoming locations include:
Software Engineering 5-Day Courses
Upcoming locations include:
PPI Upcoming Participation in Professional Conferences
Kind regards from the SyEN team:
Copyright 2009 Project Performance (Australia) Pty Ltd, trading as Project Performance International
Tell us what you think of SyEN: email to email@example.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.
This email is an advertisement complying with the CAN-SPAM Act 2003.