WHAT’S INSIDE:

A Quotation to Open On

Feature Article: Niels Malotaux – Lean Systems Engineering

Systems Engineering News

• INCOSE INSIGHT July 2011 – Systems of Systems and Self-Organizing Security

• The Institute for Systems Research at the University of Maryland sponsors a free event –Maryland Robotics Day

• Cognition Corporation Teams Up with Netherlands Based Synergio, a European distributor specializing in Requirements Engineering

• Interactive Modeling of Local Governmental Core Systems

• Researchers Reconstruct Human Faces Using 3D Modeling

• IPv6 — Are you ahead, behind, or completely off the map?

• Innovate2011 was held in Bangalore and Delhi August 8-11, 2011

• Systems Thinking and the Three Musketeers – Deming’s SoPK Part I

Featured Society – TechAmerica

Systems Engineering Software Tools News

• inteGREAT by eDev Technologies
• Proposal for Eclipse-based Requirement Modeling Framework Released

Systems Engineering Books, Reports, Articles and Papers

• Performance-Based Earned Value by Paul Solomon and Ralph Young (IEEE Computer Society and John Wiley)
• Systems Thinking in Enterprise Architecture by Jamshid Gharajedaghi
• General Systems Thinking by Gerald M. Weinberg

Conferences and Meetings

Education and Academia

• Georgia Tech Professional Master’s in Applied Systems Engineering – A Hands-On Approach to Learning with the Master’s of Systems Engineering Program
• University of Pennsylvania Singh Program in Market and Social Systems Engineering
• Postdoctoral position at the National University of Singapore

Some Systems Engineering-Relevant Websites

Standards and Guides

• ISO/IEC 42010, System and Software Engineering: Architecture Description
• Status of EIA-STD-632 “Processes for Engineering a System”
• Standard for Technical Reviews and Audits

Some Definitions to Close on

PPI News

A Quotation to Open On

“Would you tell me please, which way I ought to go from here?
That depends a good deal on where you want to get to, said the cat.
I don’t much care where -, said Alice.
Then it doesn’t matter which way you go, said the cat. “
Lewis Carroll,
Alice in Wonderland, Chapter 6.

Feature Article

Lean For Systems Engineering

By

Niels Malotaux, Project Coach

Last year I presented at the “Lean & Agile for Systems Engineers” seminar in Stockholm organized by INCOSE-Sweden. I was asked to talk about “How is it possible that most organizations still survive while their competitors are applying Lean?” (Short answer: “They don’t”) and “My Practical Approaches for Becoming Lean and Really Agile”. I was also asked to present a “Lean & Agile Primer”, in order to set the stage: what are we actually talking about? I wanted to avoid the usual hallelujah stories about Lean and Agile, so I researched to find and present about the “essence” of these ideas, and how these ideas can actually improve systems engineering results. You can download the presentations: www.malotaux.nl/doc.php?id=31 .

Here are some of my findings about Lean. Perhaps I can write another time about my findings about Agile. Short advice: avoid the hype and the tools; find the essence and use it!

The origin of the word “Lean” in the present context comes from people from MIT, who tried to find the secret behind the Japanese Car Production ‘miracle’ (read Toyota). The word started the hype with the book The Machine that Changed the World, the Story of Lean Production by Womack, Jones, and Rook (1990). A reviewer of the book noted: “A lot of the cost of vehicles is based on: bad design, poor management, and an attitude that problems, no matter how small, can be overlooked”.

Womack writes: The goal is reduction of waste. To achieve this, a company must look at what creates value and eliminate all other activities:

1. Specify value from the standpoint of the end customer by product family.
2. Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value.
3. Make the value-creating steps occur in tight sequence, so the product will flow smoothly toward the customer.
4. As flow is introduced, let customers pull value from the next upstream activity.
5. As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced; begin the process again, and continue it until a state of perfection is reached in which perfect value is created with no waste.

Nice sounding words, but what do they really mean?

I decided, instead of reading second-hand material, to go to the Japanese original, Taiichi Ohno’s book: The Toyota Production System – Beyond Large Scale Production (1978), as well as background information from other Japanese sources. I learned that in the 1950 timeframe, the company (Toyota) nearly went bankrupt and had to lay off one third of its employees. This stimulated Ohno to focus on four specific aims – note my comments concerning each aim:

• • Deliver the highest possible quality and service to the customer

Without quality, the customers won’t buy, and if the customers don’t buy our products, all other issues are irrelevant. Is it coincidental that Deming presented his speech to Japanese top-management in 1950, saying just that?

• • Develop employees’ potential based upon mutual respect and cooperation

The employees create the value. All management can do is to facilitate and help them to create the value more efficiently. Still, “Death by Overwork” is an official Japanese Government statistic and Toyota only recently decided that overtime should be limited to 360 hours per year, which implies that people are still expected to work overtime on average up to 1.5 hour every day.

• • Reduce cost through eliminating waste in any given process

There are so many things we tend to do that do not contribute to creating value for the customer. It is the task of everybody in the organization to recognize and actively eliminate waste in whatever we do, and not do.

• • Build a flexible production site that can respond to changes in the market

Because Toyota initially didn’t build so many cars, they had to adapt what they learned from Ford’s mass-production (you can buy any model and any colour, as long it’s a model T and it’s black) towards making small-scale and varying production as efficient, or even better.

To quote some lines from Ohno’s book:

• • When asked what Toyota was currently doing, Ohno replied: “All we do is analyze and review the TimeLine from Order to Cash, removing the non-value-adding wastes”

This provides a clear focus to continuous improvement, not wasting time and resources.

• • “The Toyota Production System began when I challenged the old system”

Continuously challenging the old system is the basis of improvement. As both Einstein and Benjamin Franklin said: Insanity is doing the same thing over and over again and expecting a different outcome. The old system apparently needed improvement, so it always should be challenged. We should be so humble as to admit that we can always improve. For those who think that continuously improving quality of what we do and what we produce costs more: Crosby already had found that Quality is Free. Even in 1950, Deming had told the Japanese this. It is my own observation that quality is cheaper.

• • “Necessity is the mother of invention: improvements are made on clear purposes and need”

We see the US Lean movement pushing the tools and techniques they found at Toyota. At Toyota, they make improvements on clear purposes and need. Their tools and techniques emerged out of necessity and will be different tomorrow, because the improvement cycle never stops. This makes me remember the story of what a US mission to Japan found: they visited many successful Japanese companies and saw that every morning the people were doing exercises. Back at home they advised US companies that doing morning exercises would make them more successful. The mission failed to observe unsuccessful Japanese companies, where people also did morning exercises every day.

• • “The TPS has been built on the practice of asking “Why?” five times”

Before jumping to implementing the first solution that comes to mind, better first develop the problem, then look for possible solutions and then select the most promising one. Five times “Why?” is usually sufficient to find the root problem from which we can then design the appropriate solution. In practice we see so many projects developing a perfect solution for the wrong problem. Better to first develop the problem!

• • “The time that provides me with the most vital information about management is the time I spend in the plant, not in the office”

The ‘working floor’, where the people are creating the value, is the place where you can observe what can be improved, and how you can help the people who create the value to become more effective and efficient. Sitting behind your office desk you will create theoretical solutions for theoretical problems that do not work as expected in practice. This is what Masaaki Imai describes in his book Gemba Kaizen – A Common Sense, Low-Cost Approach to Management (1986), Gemba being “the working place” and Kaizen being “continuous improvement”.

• • “Toyota’s top management watched the situation quietly and I admire the attitude they took”

What Ohno did was not very Japanese: he squarely told people the truth, instead of trying for them not to ‘lose face’. He got quite some opposition and he admits that without clear executive support he wouldn’t have been able to implement his ideas.

Where Lean seems to focus on tools and techniques (which of course sell nicely), the Japanese simply used and keep using the Deming Cycle (Plan-Do-Check-Act) and asking five times “Why?” to find solutions for their own particular issues and circumstances in order to continuously improve. After all, they are not in the business of selling a “method”.

Ohno is a modest man, admitting that he obtained his ideas when reading Henry Ford’s books and looking at US supermarket supply principles. Like Henry Ford, he took old ideas and adapted them for his clear purposes and need.

Those who don’t learn from history are doomed to repeat it (after Santayana), so let’s dig up some more roots of so-called ‘Lean’ ideas:

• Benjamin Franklin (1706-1790)
  • • Waste nothing, cut off all unnecessary activities, plan before doing, be proactive, assess results and learn continuously to improve continuously
• Henry Ford (1863-1947)
  • • My Life and Work (1922)
      • We have eliminated a great number of wastes (at the farm in Dearborn)
    • Today and Tomorrow (1926)
      • Learning from waste; keeping things clean and safe; better treated people produce more
• Toyoda’s (Sakichi, Kiichiro, Eiji) (1867-1930, 1894-1952, 1913- )
  • • Jidoka: Zero-Defects, stop the production line (1926)
    • Just-in-time – flow – pull
• W. Edwards Deming (1900-1993)
  • • Shewhart cycle: Design-Produce-Sell-Study-Redesign (Speech to Japanese management, Japan – 1950)
    • Becoming totally focused on quality improvement (idem)
      Management to take personal responsibility for quality of the product
    • Out of the Crisis (1986) – Quality reduces waste
• Joseph M. Juran (1904-2008)
  • • Quality Control Handbook (1951, taught in Japan – 1954)
    • Total Quality Management – TQM
    • Pareto Principle
• Philip Crosby (1926-2001)
  • • Quality is Free (1980)
    • Zero-defects (1961)
• Taiichi Ohno (1912-1990)
  • • (Implemented the) Toyota Production System (Beyond Lange-Scale Production) (1978, 1988 in English)
    • Absolute elimination of waste – Optimizing the TimeLine from order to cash
• Masaaki Imai (1930- )
  • • Kaizen: The Key to Japan’s Competitive Success (1986)
    • Gemba Kaizen: A Commonsense, Low-Cost Approach to Management (1997)

Ohno says there are two pillars of the Toyota Production System:

1. Just in Time (JIT)

No inventory.

Inventory is stuff waiting to be used later. Inventory deteriorates and has to be kept, managed, transported, which is all considered waste, because it doesn’t create value, it only costs. Ohno admits that the idea is simple, but the implementation is a lot of hard and continuous work. An example of inventory with Systems Engineering is detailing requirements way before they are used. Once they are needed they are deteriorated by improved insight in what the project really is about.

Perfection is a condition for JIT to work. If the things that are delivered Just In Time are not in perfect order, they cannot be used, the flow is disrupted and it’s not any more JIT. Therefore, if a defect is found: stop the line, find the cause, and fix it immediately.

Use root-cause-analysis to find the root of the problem, as there is a process that is producing this defect. Find this process and change it so that it doesn’t produce the defect. Continuous improvement of product, project and process.

2. Autonomation

This is a new word hinting at our autonomous nerve system, having local autonomous feedback loops. It was introduced by Sakiichi Toyoda when automating the looms he produced. If one wire at the loom breaks, it’s of no use keeping the loom running, because it’ll be producing defective and therefore unusable cloth. If the looms run autonomously and signal a defect when it occurs, one operator can attend many looms. The sales of Toyoda’s patents on autonomous looms to a company in the UK provided the money to start developing automobiles.

If we translate Autonomation to development:

• • • The development team runs unattended until signaling it needs help (caused by an issue beyond the team’s control)
    • Management observes the team and proactively facilitates them to become ever more efficient. Management prevents issues delaying the team beyond the team’s control – education, empowerment, and responsibility of people. This is one of the most important tasks of management. If management doesn’t remove waste proactively (mainly before it happens!), or even causes waste, management is to be regarded as waste, and therefore should be removed or replaced.
    • If an issue still does occur, management helps to remove obstacles quickly, making sure it doesn’t happen again.

We see here an enlightened way of management, not policing with command and control, but rather management being subservient to the workers to help them to become more efficient. This is quite a different attitude from what we often see in contemporary management attitudes in the West. It was, however, borrowed from the original type of management that, before World War II, made the US companies so powerful and prosperous. This knowledge was exported to Japan after the war (see CCS Management Course, provided in the references, below) and in the US was replaced by what the Hopper brothers in their book The Puritan Gift called the “Cult of the (so called) Expert”, showing how this attitude led to the current economic crisis.

Capacity = Work + Waste

The capacity in an organization is used for:

• Work, which creates value.
• Non-value adding, but necessary, work

Example: managers are waste, unless they organize, facilitate, and optimize the work of the workers, increasing the value produced by the workers more than the management’s added cost.

• Waste: anything that does not contribute to value creation.

“Because it costs nothing, eliminating waste is one of the easiest ways for an organization to improve its operations.”

Identifying Waste

People are not stupid. If it were easy to recognize and eliminate waste, it would have been done already. Apparently, it’s counter-intuitive. To help us identifying waste, Ohno mentions seven types of waste, to which an eighth was added later. In the following table we see these wastes, with a translation into what these would mean to development (or systems engineering) tasks and possible remedies to do something about them (not necessarily the best remedies, but examples to help you apply the concept):

Manufacturing	Development / SE (after Poppendieck)	Possible Remedies (my suggestions)
Overproduction	Extra features Unused documents	Prioritizing real requirements, Deciding what not to do
Inventory	Partially done work	Synchronization, Just In Time
Transport	Handoffs	Keeping in mind: Responsibility (what to do) Knowledge (how to do it) Action (doing it) Feedback (learning from result)
Processing	Design inefficiency Wishful thinking	Knowledge, experience, reviews Preflection[1]
Waiting	Delays	Process/organization redesign
Movement	Task Switching	Maximum of two tasks in parallel
Defects	Defects	Prevention
Ignoring ingenuity of people	Ignoring ingenuity of people	Effective management, empowerment Bottom-up responsibility

5S and 3Mu

When people talk about Lean, you will soon hear about 5S and about the 3 Mu’s. These are an aid for people to internalize the essence:

• Seiri – Remove unnecessary things waste
• Seiton – Arrange remaining things orderly flow
• Seiso – Keep things clean uncovers hidden problems
• Seiketsu – Keep doing it, standardize know what to improve
• Shitsuke – Keep training it resisting inevitable entropy
• Muda – Waste minimize waste
• Mura – Irregularities optimize flow
• Muri – Stress sustainable pace

What is Real Value?

When Terminal 5 was built at Heathrow Airport (London), it was a huge technical success. It was quite an achievement, to complete a multi-billion pound project on time and on budget. However, the people for whom the terminal was actually built (without passengers there is no need for a terminal!) aren’t interested in the technical details of a terminal.

They only want to:

• Check-in their luggage as easily as possible, and
• Get their luggage back as quickly as possible in acceptable condition at their destination.

They didn’t.

One of the problems is to determine what the value of the project (or our work in general) really is about.^[2]

This is about what we call Real Requirements^[3]. Requirements engineering is quite underdeveloped in most projects. Why? I think it’s a lack of proper education. Providing this education is one of the responsibilities of management.

Example of Identifying Waste (Value Stream Mapping)

Assume that the users of our system encounter a problem that costs them extra time (Problem occurring: negative value or waste to the users), see Figure 1:

Figure 1: Value Stream Mapping Example

Then it may take some time:

• before some of the users start complaining (Problem recognized)
• before the problem is reported to those who can do something about it (Problem to development)
• before development (receiving it e.g. by email), puts it in their issue database (Problem into database)
• before the Change Control Board (CCB) decides whether and how to handle the issue (CCB decision)
• before handling the issue is scheduled (Time allocated)
• before the problem gets solved
• before the solution is verified and validated (V&V)
• before the solution is deployed
• before the problem doesn’t hinder the users anymore.

In this process, there are a lot of value-adding activities, all (seemingly) necessary to create the value of the solution. It’s obvious that between these activities, there is a lot of waiting time.

From this example we can see the following:

• The total time the users keep having the problem is 114 days.
• The value-adding time is 1.6 days and the non-value adding time is 112 days.
• If, using our system, twice a day 100 users experience this problem, spending an extra 10 minutes every time, the wasted business cost of the users waiting for the solution is (with some assumptions):

2 times per day x 100 people x 10 minutes extra x 112 days x $400 per day = $187k.

• The net cost of producing the value of the solution is (with some more assumptions):

3 people x 1.6 days x $1000 per day = $5k.

While solving the problem, we are actually wasting almost $187k, instead of spending ‘only’ $5k. Having mapped the “value stream”, we can now look for minimizing the delays between the value adding stages. We may challenge the necessity and efficiency of the value adding stages themselves. And of course we also do a root-cause analysis to determine why we produced the problem in the first place. Still, we must be careful not to optimize everything at once, because if we try to improve too much in too short a time, we will probably fail.

Many so-called “Process Improvers” usually start “improving” the value adding activities within the boxes (see Figure1). Now we can see that, in this case, they would better start with removing the waste between the boxes.

Value Stream Mapping in Development or Testing

The previous example is used for production: repeated actions, which we can observe and then improve on. Some people maintain that this cannot be applied to development. A lot of what we do in development as well as in testing, however, is more of the same, with a lot of waiting and inefficient synchronizing. Here we can use the same regular value stream mapping principles as described. Some development activities (mainly within the boxes of fFgure 1) are, however, specific to this particular development, and analysis after the fact is not useful, because once we find out that we could have prevented the waste, the time has already been spent and the waste is already produced. Instead of relying only on reflection on what we should have done better, we’d better use preflection: imagining which elements of what we are going to do will produce waste, before doing it, and then not doing it. This is the only way to avoid this type of waste and this is what we routinely do with the Evolutionary Planning approach (see www.malotaux.nl/?id=evoplanning). An example of how waste is prevented before the time is spent can be found at www.malotaux.nl/?id=designdelivery

We use ‘magic sentences’ like:

• “Why are we doing this?”
• “Is it really necessary?”
• “Is it really necessary now?”
• “Who’s waiting for it?”
• “How much time would you need?” – “How much time do you have?” – “How much time should you use?” – “How much time will you give yourself?”

Planning in this way, we routinely save 30% of the time while producing better results in all other respects. Because it’s so easy, people learn to save time within just several weeks. Why don’t they already do this, or why does it take several weeks? Because what people have to do is partly counter-intuitive. That’s why it hasn’t happened spontaneously already. A coach helps them by saying “Can you do this in three weeks for me? Trust me; it has always worked, at least until now!” If then, within two weeks people find it starts working for them, new intuition is born. From then, it will go automatically and the coach can start focusing on other issues.

But I’m only a systems engineer! What has this to do with me?

What has this to do with me? After all, I’m a systems engineer and not a project manager. Well, the project manager is responsible for the project to deliver an effective and efficient result. However, the workers in the project and especially the systems engineers determine the time they spend, and the efficiency of the solutions they provide for the users. This makes systems engineers even more responsible for being aware of all time elements:

• in the product (system) they are conceiving
• in the project, how they come to good solutions, how they organize their work
• in the processes used to develop the product
• in the processes their product (system) uses to support the users letting the value crystallize.

Some snippets

• Womack
  Most managers think their greatest contribution to the business is doing work-arounds on broken processes, rather than doing the hard work to get the process right so that it never breaks down.
• Imai, in Gemba Kaizen – A Commonsense Low-Cost Approach to Management

90 per cent of all corporate problems can be solved using common sense and improving quality while reducing cost through the elimination of waste.

• Tom Harada (worked under Ohno)

Plan-Do-Check-Act cycle was by far the most important thing we did in hindsight.

Not to make this article too long, please read the page on Plan-Do-Check-Act on my website: www.malotaux.nl/?id=pdca

Plan-Do-Check-Act is the basis for continuous Root-Cause-Analysis and for continuous improvement.

• A project manager
  Root-Cause-Analysis on every defect found? We don’t have time for that!

Apparently people do not have the time to do things correctly the first time; however, they have a lot of time when things go wrong. The development budget is squeezed and the panic budget is unlimited. This is one of the reasons why projects take way more time than necessary. Why don’t people learn? Because it’s counter-intuitive, even for management!

Conclusion

Some essential ideas behind being lean:

• Delivering the right stuff, the right way, at the right time, as efficiently as possible
• Understanding what real value means
• Quickly and easily adapting to all stakeholders (however beware: only the Customer pays, the other Stakeholders don’t mind the cost!)
• (especially for software) Total system focus – software is only an aid – it only provides value when it is used successfully
• Continuous elimination of Waste
  • Doing what contributes the most value
  • Not doing what does not contribute value
  • Prevention rather than repair – relentless problem solving – root cause analysis
  • Perfection – Quality is cheaper
• Predictability: Continuously being able to tell what will be done when (to take appropriate action)
• Delivering in small steps where possible, to real stakeholders doing real things
  Minimizing the waste of incorrect perceptions, assumptions and implementations, optimizing productivity of Stakeholders – not just demos
• Continuously optimizing what we do, how we do it, and how we organize things using PDCA
• Empowerment – everybody feeling responsible for the result (remember the Goal of a Project – see www.malotaux.nl/?id=goalofaproject)
• Assertiveness – actively removing impediments, no need for excuses
• Understanding that it’s not about tools: a lot is attitude and craft (you cannot ‘implement’ Lean)
• Management facilitating and coaching the workers to do the right things the right way at the right time
• Management to be personally responsible for continuous improvement (not just change)
• JIT, Autonomation, Kanban (not explained in this text), Value Stream Mapping, Flow, 5S, 3Mu, etc. All good to know techniques, however, beware of technique-fetishism!
• Involving the whole organization

Looking at what I’ve learned during the past decades in my work to help projects, greatly improving their performance, it’s all lean: not doing what is not necessary, not spending more than necessary, and continuous pursuit of perfection. I call it Quality on Time. My father, as a business consultant, did similar things in the 60’s, optimizing the flow and performance of e.g. bicycle production, without ever having heard of Toyota. That’s not surprising, because after all it’s just common sense, as he used to say. However, “common sense apparently is not so common”, is a comment I often heard in the corridors of the INCOSE International Symposium in Chicago. A lot of the things that we have to do to make projects successful and on time are counter-intuitive, which makes it almost impossible for this to happen spontaneously. Without active and continuous coaching by management, it will not happen. If management doesn’t know yet how to do this, they hopefully will ask qualified external coaches for assistance.

Reading

• Philip B. Crosby, Quality is Free, 1979, Quality is Still Free, 1996. ISBN 0070145326
• W. Edwards Deming
  • Out of the Crisis, 1986. ISBN 0911379010
  • Speech for Japanese Management, 1950, www.jsdstat.com/Statblog/wp-includes/Hakone.pdf
• K. and W. Hopper, The Puritan Gift, 2007. ISBN 9781845119867
• Masaaki Imai, Gemba Kaizen: A Commonsense, Low-Cost Approach to Management, 1997. ISBN 0070314462
• Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, English version 1988. ISBN 0915299143
• Henry Ford, My Life and My Work, 1922. ISBN 161743020X
• Henry Ford, Today and Tomorrow, 1926. Reprint 1988, 2003. ISBN 0915299364
• Benjamin Franklin, Autobiography, various publishers. ISBN 0486290735
• Homer M. Sarasohn and Charles A. Protzman, The Fundamentals of Industrial Management – CCS Management Course, 1949. http://www.cmis.csiro.au/opm/publications/PDF/ccs_manual_complete.pdf
• Charles Womack et al., The Machine That Changed the World, 1990. ISBN 0743299795
• Website INCOSE Lean-SE Working group (192 Lean Enablers): http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm

Niels Malotaux is an independent Project Coach and expert in optimizing project performance, helping organizations around the world to optimize the predictability of their projects. He has some 35 years experience in designing hardware and software systems, at Delft University, in the Dutch Army, at Philips Electronics and 20 years leading his own systems design company. Since 1998, he has devoted his efforts to helping projects to deliver Quality On Time: delivering what the customer needs, when it is needed, to enable customer success. Niels teaches Evolutionary Project Management (Evo) Methods, Requirements Engineering, and Review and Inspection techniques. Since 2001, he has taught and coached well over 100 projects in 25+ organizations in the Netherlands, Belgium, China, Germany, Ireland, India, Israel, Japan, Romania, South Africa and the United States, which has led to a wealth of experience in which approaches work better in practice, and which work less well. He is a frequent speaker at conferences, see www.malotaux.nl/?id=conferences.

Systems Engineering News

Systems of Systems and Self-Organizing Security

INCOSE INSIGHT July 2011

The articles in this issue examine several aspects of systems of systems (SoS) and self-organizing security in an attempt to foster recognition of the security issues presented by the SoS in the systems engineering profession. Ten essays address this theme from various perspectives. Some serve as a wakeup call, some focus on the vulnerabilities of early systems of systems, and some begin to explore the lessons we can learn from self-organized security in systems of systems.

More Information http://www.parshift.com/s/110701SystemsOfSystemsAndSelfOrganizingSecurity-Essay.pdf

The Institute for Systems Research at the University of Maryland

Sponsors Maryland Robotics Day (a free event)

Maryland Robotics Day is Friday, Sept. 9, 2011, and will showcase the wide range of robotics research taking place in the Maryland Robotics Center, housed within the Institute for Systems Research (ISR) at the University of Maryland. The website for this year’s event is now online and being updated and expanded on a regular basis.

More Information http://www.eng.umd.edu/html/survey/robotics-day/gov.html

Cognition Corporation Teams up with Netherlands Based Synergio, a European distributor specializing in Requirements Engineering

Cognition Corporation has been offering solutions for product and process development for more than ten years. This partnership will expand Cognition’s ever growing customer base, sending them to the next level in the field of Requirement and Risk Management Software. Cognition’s Cockpit tool is the next generation in Product Lifecycle Management (PLM) Tools; combining requirements and risk management in an easy to use web-based software tool.

More Information http://www.cognition.us/

Interactive Modeling of Local Governmental Core Systems

The City of Portland and IBM have collaborated to develop an interactive model of the relationships that exist among the city’s core systems, including the economy, housing, education, public safety, transportation, healthcare/wellness, government services and utilities. The resulting computer simulation allowed Portland’s leaders to see how city systems work together, and in turn identify opportunities to become a “smarter city”. The model was built to support the development of metrics for the Portland Plan, the City’s roadmap for the next 25 years. As an example of how the model could be used in practice, recently the City of Portland laid out plans to achieve a 40 percent reduction in carbon emissions by 2030, and an 80 percent reduction by 2050.

More Information www.ibm.com/smartercities

Researchers Reconstruct Human Faces Using 3D Modelling

Researchers from Microsoft’s Beijing lab have taken 3D modeling a step further. The new system focuses on the human face, and enhances the most advanced computer graphics. The researchers presented their new system at the SIGGRAPH 2011 computer graphics conference that was held earlier this month in Vancouver, B.C.

More Information http://www.geek.com/articles/games/microsoft-research-develops-fast-3d-face-modeling-system-could-it-work-with-kinect-2011088/

IPv6 — Are you ahead, behind, or completely off the map?

Internet Protocol version 6 (IPv6) is a new version of the Internet Protocol (IP) that is designed to succeed the older Internet Protocol version 4 (IPv4). The Internet operates by transferring data in small packets that are independently routed across networks as specified by an international communications protocol known as the Internet Protocol. Each data packet contains two numeric addresses that are the packet’s origin and destination devices. Since 1981, IPv4 has been the publicly used version of the Internet Protocol, and it is currently the foundation for most Internet communications. (Wikipedia). In a recent Network World survey, most enterprises said that they’ll be on IPv6 by 2013. A frequently asked question is “How do I know if we’re ahead, behind, or completely off the map with our IPv6 planning and implementation?” Network engineers, system administrators, application owners and developers, DBAs — pretty much everyone in IT needs to start thinking about IPv6 according to Josh Stephens (“EtherGeek”).

More Information http://blogs.computerworld.com/18723/ipv6_are_you_ahead_behind_or_completely_off_the_map

Innovate2011 was held in Bangalore and Delhi August 8-11, 2011

Systems engineering is the key to driving innovation in the product development process, helping organizations deliver smarter products by enabling collaboration and integration across the product lifecycle. This event was focused on leveraging the discipline of systems engineering to successfully manage innovation of software intensive products, product lines, and systems. Attendees gain in-depth knowledge from experienced IBM experts and customers on the tools, methods, and best practices that can be leveraged to deliver smarter products in less time and with higher quality. The track focused on integration of engineering disciplines, alignment of business and engineering objectives, innovation management, and “systems of systems.”

More Information http://www-01.ibm.com/software/in/rational/innovate/tracks/syseng/

Systems Thinking and the Three Musketeers – Deming’s SoPK Part I

Conceptually, it is often easy to grasp the concept of Systems Thinking, writes contributor Eric Christiansen, in the first of a four-part series looking at Dr. W. Edward Deming’s system of management – the System of Profound Knowledge (SoPK). What is more difficult is figuring out what you should do once you understand it. And that’s where the Three Musketeers come in. For over 150 years these words have invoked images of four young men working together with single minded purpose to overcome great obstacles, privations, injuries and loss. (In the Alexandre Dumas novel, The Three Musketeers, Athos, Porthos and Aramis are the three musketeers who eventually befriend D’Artagnan –thus making four companions (“All for one and one for all.”) At the heart of “Systems Thinking” is the same philosophy and call for action for the benefit of all.

More Information http://www.processexcellencenetwork.com/methodologies-statistical-analysis-and-tools/columns/systems-thinking-and-the-three-musketeers/

Featured Society – TechAmerica

TechAmerica Overview

TechAmerica aims to be the leading voice for the U.S. technology industry, which it sees as the driving force behind productivity growth and jobs creation in the United States, and the foundation of the global innovation economy. Representing approximately 1,000 member companies, of all sizes from the public and commercial sectors of the U.S. economy, TechAmerica claims to be the industry’s largest advocacy organization.

TechAmerica was formed by the merger of AeA (formerly the American Electronics Association), the Cyber Security Industry Alliance (CSIA), the Information Technology Association of America (ITAA) and the Government Electronics & Information Technology Association (GEIA). TechAmerica’s headquarters is located in Washington DC. It has a network of 20 offices across the United States and two overseas.

TechAmerica Standards – Status

As an ANSI-accredited standards development organization, TechAmerica produces best-practice industry standards. Status with respect to TechAmerica standards is:

{Insert the tables with headings at http://www.techamerica.org/standards}

The Systems Standards and Technology Council (SSTC)

The Systems Standards and Technology Council (SSTC) is TechAmerica’s focal point for all matters dealing with engineering and operations management, engineering technology and related policy areas affecting the government electronics and IT marketplace. It is a forum for discussion of technical management issues and prepares industry positions on proposed legislation, studies, regulations, standards, and related documents.

The Council oversees activities of specialized engineering committees which conduct an active, ANSI accredited, standards development program. Configuration Management, Systems Engineering, System Safety, Reliability, Earned Value Management, Life Cycle Logistics Supportability, Data Management, and other key standards were developed by TechAmerica members.

Engineering Committees

Engineering Committees of TechAmerica presently are:

Avionics Process Management Committee, APMC – This committee works to develop process management standards for systems and equipment used in the field of avionics (Avionics includes electronics used in commercial, civil and military aerospace applications) and to act as the US Technical Advisory Group for International Electrotechnical Committee TC107, Process Management for Avionics.

Compact Model Council, CMC – This Council was formed for the purpose of promoting standardization in the use and implementation of Compact models. It seeks to promote the international, nonexclusive, standardization of compact model formulations and the model interfaces. Its vision is to have standardized compact models for all major technologies so that customer communication and efficiency can be enhanced, as well as standard interfaces so that compact models for the latest technologies can be tested and implemented easier and faster, allowing leading edge design development cycles to shorten.

Enterprise Information Management and Interoperability Committee, EIMI – This Committee seeks to address the opportunities created by advances in information technology to enhance the capability of the TechAmerica companies and our Government associates to productively use data and information as the effective basis for decisions and actions. The focus of the committee is to: develop, contribute to, promote, and institutionalize data, information management, and associated interoperability standards ; Influence the information interoperability landscape, providing recommendations and guidelines to address approaches to interoperability; Facilitate communication and collaboration on standardization policy, technologies, governance, and path of evolution; and represent member interests in the development, and application of cutting edge technology, process, and practices to support and improve the constituent elements of Information Management.

Component Parts Committee, G-11 – This Committee recommends solutions to technical problems in the application, standardization and reliability of parts, except for active solid state devices. This is implemented by evaluation and preparation of proposed advancements in specifications, standards and other documents; both government and industry, to assure that parts are suitable for their intended applications and for procurement.

Solid State Devices Committee, G-12 – This Committee develops solutions to technical problems in the application, standardization, and reliability of solid state devices. This is implemented by evaluation and preparation of recommendations for specifications, standards, and other documents, both government and industry, to assure that solid state devices are suitable for their intended purposes.

Configuration Management Committee, G-33 – This Committee prepares positions on government policies, practices, specifications, and standards dealing with technical data, drawing practices and configuration management practices. It promotes understanding of configuration management principles, and develops standards. The committee provides innovative solutions and educational services through workshops and related publications.

Human Systems Integration Committee, G-45 – The Human Systems Integration (HSI) Committee focuses on processes and requirements to assure satisfactory human-system integration, including human factors Engineering (HFE); manpower, personnel and training (MPT); environment, safety and occupational health (ESOH); personnel survivability and habitability. The primary focus areas of the G-45 HSI committee are: defining, assessing and optimizing human-system interfaces; maximizing human and human-system performance and; minimizing personnel-driven customer ownership costs. Important functions of the G-45 committee include: evaluating new and revised Government documents; HSI gap analysis (current versus required capabilities); and advising senior TechAmerica and Department of Defense representatives about current and emerging HSI issues, problems and opportunities.

Electromagnetic Compatibility Committee (EMI/EMC), G-46 – The G46 committee deals with the system-oriented discipline that ensures electromagnetic compatibility in electronics design. The Committee develops technical criteria and procedures to guide the design engineer. Its work also includes spectrum management and conservation, secure communications, and electromagnetic emission, susceptibility, control and characterization.

Systems Engineering Committee, G-47 – This Committee serves as an industry focal point for systems engineering by developing and maintaining standards, coalescing industry positions, preparing and coordinating positions on government policies & practices, and promoting sharing of best practices on the engineering of systems.

G-47 is working on a revision to systems engineering standard ANSI/EIA-632 and is seeking input from users to help them during this revision process.

G-47 is working on a new Reliability Standard and is seeking input from users to help them during this process.

System Safety Committee, G-48 – This Committee develops technical and program criteria, standards, procedures, and methodology for the application of system safety engineering at all phases of the life cycle of a system or equipment. It documents and disseminates standard analytical techniques for enhancing system safety and conducting industry surveys for the purpose of improving techniques for testing, collecting, and distributing historical operational system safety data.

Quality & Reliability Engineering Committee, QRE – This Committee supports quality and reliability documents applicable to electronic components, both active and passive devices. The Committee also supports quality system standards such as EIA-557B, Statistical Control and EIA-832, Process Improvement. The Committee is currently investigating the need for standards in the areas of supplier maturity rating, basic quality education and design quality assurance. We provide effective liaison between industry and the government in the development and application of quality assurance concepts, policies and practices.

Life Cycle Logistics Supportability Committee, LCLS – This Committee serves as an industry focal point for life cycle logistics and supportability through the application of logistic support analysis principles. The committee develops and maintains standards, coalesces industry positions, and prepares and coordinates positions on government policies and practices. The committee also promotes sharing of best practices on logistics and supportability of products and systems.

I/O Buffer Information Specification, IBIS – IBIS is a standard for electronic behavioral specifications of integrated circuit input/output analog characteristics. In order to enable an industry standard method to electronically transport IBIS modeling data between silicon vendors, simulation software vendors, and end customers, this template is proposed. The intention of this template is to specify a consistent format that can be parsed by software, allowing simulation vendors to derive models compatible with their own products. This Committee meets every three weeks on IBIS technical development, IBIS utilities development, IBIS parser/checker development, and for exchanging general information on good modeling practices and for dealing with all issues related to IBIS. IBIS Committee Task Groups exist to address Quality issues, Cookbook creation, independent Model Review, and Advanced Technology Modeling techniques. The IBIS Open Forum also holds several IBIS Summit meetings worldwide throughout the year for face-to-face discussions and technical presentations.

More Information www.techamerica.org/

Systems Engineering Software Tools News

inteGREAT

by

eDev Technologies

Toronto, Canada

inteGREAT by eDev Technologies in Toronto, Canada is a low cost (approximately $5k per seat), requirements development tool that integrates requirements development and management and test document automation. Capabilities of inteGREAT include business modeling, requirements elicitation, traceability, flowcharts, impact assessment, simulation, and resource management. Goals, actors, functional requirements, constraints, risks etc. are captured into a hierarchy. Collaboration platforms include SharePoint, MS Project, Team Foundation, and Web Access. Eighteen standard documents can be provided automatically based on the current knowledge base, including the business requirements document, system requirements spec, RTM, business rules catalogue, use case document, user interface test case, integration test case, functional test case, swimlane diagrams, and others. Integration tools include ERWIN, XMI, HP Quality Center, MS Word, and MS EXCEL. A free trial is available.

More Information www.edevtech.com/

Proposal for Eclipse-based Requirement Modeling Framework Released

The idea of the Eclipse Requirements Modeling Framework (RMF) is to provide a core for requirement tools so that they can integrate into the open source Eclipse environment. According to eclipse.org this would offer a possibility for many projects that are involved in requirements management to find a common implementation of the standard. It would push Eclipse in to phases of the development process where it is currently under-represented.

More Information www.eclipse.org

Systems Engineering Books, Reports, Articles and Papers

Performance-Based Earned Value

by Paul Solomon and Ralph Young

IEEE Computer Society and John Wiley

2007

ISBN-10: 0471721883

ISBN-13: 978-0471721888

Paul Solomon and Ralph Young are internationally recognized industry experts, Paul in Earned Value Management (EVM) and Ralph in systems engineering, requirements, and project management. Performance-Based Earned Value is constructed from guidance in standards and capability models for EVM, systems engineering, software engineering, and project management. It is the complete guide to EVM, invaluable in helping students prepare for the Project Management Institute’s (PMI) Project Management Professional (PMP) exam with practical examples and templates to facilitate understanding, and in guiding project professionals in the private and public sectors to use EVM on complex projects. The book provides a recommended change to industry practice in performing EVM that enhances its value through more objective assessment of actual work performance and product quality, according to Eleanor Haupt, Past President, Project Management Institute, College of Performance Management.

More Information http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471721883,miniSiteCd-IEEE_CS2,descCd-description.html

Advances in Systems Safety: Proceedings of the Nineteenth

Safety-Critical Systems Symposium

Southampton, UK

8-10th February 2011

[Paperback]

ISBN-13: 978-0857291325

The Symposium was designed for engineers, managers and academics in the field of system safety, across all industry sectors. The 17 papers in this volume provide wide-ranging coverage of current safety topics, with a blend of academic research and industrial experience. They include both recent developments in the field and discussion of open issues that will shape future progress. The papers are presented under the headings of the Symposium’s sessions: Safety Cases; Projects, Services and Systems of Systems; Systems Safety in Healthcare; Testing Safety-Critical Systems; Technological Matters and Safety Standards.

Announcing an Upcoming Book

Systems Thinking in Enterprise Architecture

The book targets the intersection of practitioners and academics and explores the important, notional relationship between Enterprise Architecture (EA), systems thinking, and cybernetics. Several authors have been invited to contribute to the book, resulting in a total of 20 chapters on the topic.

Systems Thinking in Enterprise Architecture is still the working title of the book and it expected to change once all chapters have been reconciled. The book will be published in the Systems Thinking and Systems Engineering Series by College Publications, thus marking the successor to the remarkable volume 1: A Journey Through the Systems Landscape by Harold “Bud” Lawson, who is also one of the joint contributors to our book.

In order to read more about the book, please refer to the ITU Enterprise web site for deadlines, list of contributors, and publication guidelines. If you are interested in contributing, please do not hesitate to send us a draft manuscript!

More Information http://thinkingenterprise.blogspot.com/

From Systems Thinking to Systems Being

A system is a set of interconnected elements which form a whole and show properties which are properties of the whole rather than of the individual elements. This definition is valid for a cell, an organism, a society, or a galaxy. Joanna Macy says that a system is less a thing than a pattern—a pattern of organization. It consists of a dynamic flow of interactions which is non-summative, irreducible, and integrated at a new level of organization permitted by the interdependence of its parts. The word “system” derives from the Greek “synhistanai” which means “to place together.”

In his seminal book Systems Thinking, Systems Practice, Peter Checkland defined systems thinking as thinking about the world through the concept of “system.” This involves thinking in terms of processes rather than structures, relationships rather than components, interconnections rather than separation. The focus of the inquiry is on the organization and the dynamics generated by the complex interaction of systems embedded in other systems and composed by other systems.

From a cognitive perspective, systems thinking integrates analysis and synthesis. Natural science has been primarily reductionistic, studying the components of systems and using quantitative empirical verification. Human science, as a response to the use of positivistic methods for studying human phenomena, has embraced more holistic approaches, studying social phenomena through qualitative means to create meaning. Systems thinking bridges these two approaches by using both analysis and synthesis to create knowledge and understanding and integrating an ethical perspective. Analysis answers the ‘what’ and ‘how’ questions while synthesis answers the ‘why’ and ‘what for’ questions. By combining analysis and synthesis, systems thinking creates a rich inquiring platform for approaches such as social systems design, developed by Bela H. Banathy, and evolutionary systems design, as Alexander Laszlo and myself have developed to include a deeper understanding of a system in its larger context as well as a vision of the future for co-creating ethical innovations for sustainability.

Just like the first image of Earth from outer space had a huge impact on our ability to see the unity of our planet, systems thinking is a way of seeing ourselves as part of larger interconnected systems. Most importantly, this new perception creates a new consciousness from which the possibility of a new relationship emerge:

“From the moon, the Earth is so small and so fragile, and such a precious little spot in that Universe, that you can block it out with your thumb. Then you realize that on that spot, that little blue and white thing, is everything that means anything to you – all of history and music and poetry and art and death and birth and love, tears, joy, games, all of it right there on that little spot that you can cover with your thumb. And you realize from that perspective that you’ve changed forever, that there is something new there, that the relationship is no longer what it was.” (Rusty Schweickart, Apollo 17 astronaut)

Systems thinking is a gateway to seeing interconnections. Once we see a new reality, we cannot go back and ignore it. More importantly, that “seen” has an emotional connection, beautifully captured in the statement by Rusty Schweickart after his experience of seeing his home planet from space.

What are the emotions evoked by perceiving for the first time the unity, interconnectedness, and relatedness of a system? What are the feelings evoked by perceiving and experiencing disconnection and isolation? Humberto Maturana says that “emotions are fundamental to what happens in all our doings” and yet, bringing up emotions in a scientific or business conversation is in many cases considered irrelevant, inappropriate or simply uncomfortable. Following Maturana’s views, I would say that the simplified answer to my two questions on the emotions evoked by unity and disconnection are love and fear, correspondingly. Love is the only emotion that expands intelligence, creativity and vision; it is the emotion that enables autonomy and responsibility. Maturana defines love as “relational behaviours through which another (a person, being, or thing) arises as a legitimate other in coexistence with oneself.” Only in a context of safety, respect and freedom to be and create (that is, a context of love) can people be relaxed and find the conditions conducive to engage in higher intelligent behaviours that uses their brain neocortex. Learning, collaboration and creativity happen when we are able to function from a consciousness capable of including a world centric awareness of “all of us”, as Ken Wilber puts it. On the contrary, in a situation of stress, insecurity, or any other manifestation of fear, we are conditioned to react more instinctually and to operate from our reptilian brain to fulfil more rudimentary needs linked to survival.

The first image of our whole Earth from space created a sense of awe and beauty. From space, we can see (and feel) its wholeness: there are no political lines dividing our national territories, there is only one whole system. However, from our terrestrial and regionally bounded experiences, we can feel that the neighbour tribe is sufficiently different and threatening to be considered an enemy.

“Before we can change the way we live, before we have saved the rainforest and the whales, we need to change ourselves. Humanity with all its different races is one. We and all other living things are nourished and sustained by the same earth” (Rema, a 14 year old girl from New Zealand).

This is the leading edge of the sustainability movement: the realization that no matter how many solar panels we install, how many green products we consume, how much CO2 we remove from the atmosphere, we will not be living better lives if we do not transform ourselves, our lifestyles, choices and priorities. Sustainability is an inside job, a learning journey to live lightly, joyfully, peacefully, meaningfully.

Systems being involves embodying a new consciousness, an expanded sense of self, a recognition that we cannot survive alone, that a future that works for humanity needs also to work for other species and the planet. It involves empathy and love for the greater human family and for all our relationships – plants and animals, earth and sky, ancestors and descendents, and the many peoples and beings that inhabit our Earth. This is the wisdom of many indigenous cultures around the world, this is part of the heritage that we have forgotten and we are in the process of recovering.

Systems being and systems living brings it all together: linking head, heart and hands. The expression of systems being is an integration of our full human capacities. It involves rationality with reverence to the mystery of life, listening beyond words, sensing with our whole being, and expressing our authentic self in every moment of our life. The journey from systems thinking to systems being is a transformative learning process of expansion of consciousness—from awareness to embodiment.

— Kathia Laszlo, Ph.D., directs Saybrook University’s program in Leadership of Sustainable Systems

NOTE: This post is an excerpt from the plenary presentation “Beyond Systems Thinking: The role of beauty and love in the transformation of our world” by Dr. Kathia Laszlo at the 55^th Meeting of the International Society for the Systems Sciences at the University of Hull, U.K., on July 21, 2011.

More Information http://saybrook.typepad.com/complexity/

General Systems Thinking

by

Gerald M. Weinberg

Originally published in 1975 and reprinted more than twenty times, the book uses fine writing to explore new approaches to projects, products, organizations, and systems.

Scientists, engineers, organization leaders, managers, doctors, students, and thinkers of all disciplines can use this book to dispel the mental aerosol that clouds problem-solving. As author Gerald M. Weinberg writes, “I haven’t changed my conviction that most people do not think nearly as well as they could had they been taught some principles of reasoning.”

The book provides more than 50 helpful illustrations and 80 examples from two dozen fields, and an addendum by a mathematical notation used in problem-solving. It may provide a useful aid in addressing problems, systems, and solutions.

John D. Richards said, “. . . this is one of the classics of systems or field of computing. I suggest it to all; it will mete out both scientists and non-scientists to examine their world and their thinking.”

Conferences and Meetings

Event

TechAmerica 2011 Engineering & Technical Management Workshop & Training

August 29 – September 1, 2011, Denver, Colorado, USA

More Information http://www.techamerica.org/2011-etm

Massachusetts Institute of Technology Annual Conference on Systems Thinking for Contemporary Challenges

October 24-25, 2011, Massachusetts Institute of Technology, Boston, USA

The aim of the conference is to provide practical information from multiple disciplines that will spark ideas for how to implement systems thinking and innovation to address complex challenges, whether in industry, academia, government, or the world at large.

More Information http://sdm.mit.edu/systemsthinkingconference

11th International Workshop on Automated Verification of Critical Systems – AVOCS 2011 September 12-14, 2011, Newcastle upon Tyne, UK

The aim of AVoCS 2011 is to contribute to the interaction and exchange of ideas among members of the international research community working on developing tools and techniques for the verification of critical systems.

More Information http://conferences.ncl.ac.uk/AVoCS2011/

No Magic World Conference

September 25-28, Ft. Worth, TX, USA

The Conference is targeted for CIOs, Systems Engineers, Project Managers, Business Analysts, Enterprise Architects, Software Architects, and Developers.

More Information www.umlconference.com/

Program Excellence: Leading Virtual Teams (Free Webinar)

September 27, 2011 – 2 p.m. – 3:00 p.m. U.S.A. ET

More Information

http://now.eloqua.com/es.asp?s=1076&e=18634&elq=1c55278c9ceb4c13a1bad4ed406bcd89

Fifth IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2011)

October 3-7, 2011, Ann Arbor, MI, USA

The aim of the SASO conference series is to provide a forum for the foundations of a principled approach to engineering systems, networks and services based on self-* properties such as self-organization, self-adaptation, self-management, self-monitoring, self-tuning, self-configuration, self-repair, etc.

More Information:

Homepage: http://www.cscs.umich.edu/SASO2011/index.php

The *First* Business Architecture Summit at BBC 2011 – The Benefits of Linking Enterprise Business Models with IT Infrastructure – Beyond the Basics, October 30-November 3, 2011, Fort Lauderdale, FL USA

The Business Architecture Summit takes place as part of Building Business Capability (BBC 2011), along with the Business Rules Forum, Business Analysis Forum, and Business Process Forum – bringing together an unsurpassed group of professionals tasked with building a more capable organization. Download the BBC 2011 conference guide for more information on these conferences.

More Information: http://www.buildingbusinesscapability.com/email/BAF/080811/

5th Annual INCOSE Great Lakes Regional Conference in Systems Engineering: Leveraging Adaptability to Tame Uncertainty, Dearborn, MI

November 4-6, 2011

More Information http://2011incoseregional.eventbrite.com

Haifa Verification Conference 2011 (HVC 2011), Haifa, Israel

December 6-8, 2011

More Information http://www.research.ibm.com/haifa/conferences/hvc2011

Complex Systems Design & Management Conference, Cité Universitaire in Paris

December 7-9, 2011

More Information http://www.csdm2011.csdm.fr/-Programme-.html

iFM2012 ABZ 2012 – Abstract State Machines

Joint conference in honor of Egon Borger’s 65th birthday for his contribution to state-based formal methods

June 18-22, 2012, CNR Research Area of Pisa, Italy

More Information http://abzconference.org/

PETRI NETS 2012 – 33rd International Conference on the Application and Theory of

Petri Nets and Concurrency

Co-located with ACSD 2012: International Conference on Application of Concurrency to System Design

June 25–29, 2012, Hamburg, Germany

More Information http://www.informatik.uni-hamburg.de/TGI/events/pn2012/

2011 International Conference on Future Management – Science and Engineering (ICFMSE2011)

The International Conference on Future Management Science and Engineering (ICFMSE 2011) was held on August 4~5, 2011, in Bali Island, Indonesia. ICFMSE 2011 is sponsored by Information Engineering Research Institute, USA. The conference proceedings will be published by Lectute Notes in Information Technology, ISSN ：2070-1918. All papers accepted will be indexed by ISTP.

Systems Engineering and the Integrated Master Schedule Full Day Tutorial

August 18^, 2011, SAIC, Research Park, Orlando, FL USA

This third tutorial in the educational series concludes with an Industry cognitive perspective which covers a general focus on the management process of Applied Systems Engineering. It will uncover how activities and goals of the process are identified with analysis justification provided in a similar manner to the technical process in the Applied Requirements Analysis and Traceability tutorial. This management process will be presented for the development phase only (referencing the DOD Systems Engineering for Mission Success Guide) for an Integrated Master Schedule.

More Information http://www.incose.org/orlando/paypal_tutorial_SE-IMS_2011.php

Education and Academia

Georgia Tech

Professional Master’s in Applied Systems Engineering

A Hands-On Approach to Learning with the
Master’s of Systems Engineering Program

Georgia Tech’s College of Engineering, the office of Distance Learning and Professional Education and the Georgia Tech Research Institute collaboratively designed the Professional Master’s in Applied Systems Engineering (PMASE) program for experienced professionals interested in building and expanding their systems engineering expertise. The program offers a practical, hands-on approach to learning how to successfully integrate systems engineering processes to gain a competitive advantage in any industry.

More Information www.pmase.gatech.edu/program

University of Pennsylvania

Singh Program in Market and Social Systems Engineering

Penn’s Rajendra and Neera Singh Program in Market and Social Systems Engineering is the world’s first undergraduate engineering curriculum that studies networked technologies such as Facebook and Google. The program is designed to integrate the disciplines needed to study the interconnected world of markets and social systems. It builds on Penn’s strengths as an urban campus, where schools and faculty for computer science, electrical and systems engineering, and business are in close proximity. The program will also immerse students in relevant technical skills and academic concepts — a comprehensive theory-into-practice approach that will prepare them to become business and technology leaders.

More Information http://makinghistory.upenn.edu/node/769

Postdoctoral Position at the National University of Singapore

Applications are invited for the position of Research Fellow in Probabilistic Modeling and Analysis.

JOB DESCRIPTION

The Department of Computer Science in the School of Computing at the National University of Singapore (NUS) has an immediate opening for a Research Fellow with expertise in probabilistic modeling and analysis of software systems.

Contact: Prof. David S. Rosenblum, email david@comp.nus.edu.sg

Some Systems Engineering-Relevant Websites

http://pb-ev.com/default.aspx

This website by Paul Solomon contains under the caption “Performance-Based Earned Value ® PBEV = EVM + Quality” a wealth of information on Earned Value Management (EVM). EVM is a project management technique for measuring project performance and progress in an objective manner. Paul Solomon, PMP is co-author of the book, Performance-Based Earned Value® and President of the consulting firm with that name. For those with a U.S. DoD interest, the site contains recommended changes to OMB policy, FAR, and DFARS (see the site for meaning of the acronyms).

http://www.niwotridge.com/PMasSE/index.html

This site by Glen B. Alleman presents a perspective on large project management as a systems engineering discipline. It outlines a systems engineering approach to project management

http://www.spmn.com/lessons.html

The Software Program Managers Network (SPMN) was established in 1992 by the Assistant Secretary of the U.S. Navy to identify proven industry and government software best practices and convey these practices to managers of large-scale DoD system acquisition programs.

The SPMN Focus Team Initiative provided experts in technical and management practices for the development of large-scale software. This page summarizes lessons learned from SPMN Focus Team visits with many different software-intensive development programs in all three U.S. DoD Services.

One group of lessons is listed under the title Systems Engineering on Embedded Weapon System Programs. Additional lessons are listed under other useful categories.

http://www.afit.edu/cse/

This is the site of the United States Air Force Institute of Technology (AFIT) Center for Systems Engineering (CSE). The mission of the CSE is to develop new SE concepts that will provide processes, practices, tools and resources to the SE workforce through research, education, and consultation for air, space and cyberspace competence. The site contains a number of interesting case studies and downloadable resources for those with an interest in defence programs.

INCOSE Technical Operations

SE Effectiveness Working Group

Charter

The purpose of the SE Effectiveness Working Group (SEEWG) is to promote effective systems engineering by collecting and analyzing quantitative data on the impact of specific SE processes and practices on project performance. This data will contribute to the development of a stronger business case for systems engineering.

Leadership

Chair: Joe Elm; Software Engineering Institute

Co-Chair: Eric Honour; Honourcode, Inc.

Contact the SE Effectiveness Working Group for additional information or to join this group.

Accomplishments/Products

• The SEEWG was authorized on 18-Nov-2010
• The inaugural meeting of the SEEWG was held on 23-Nov-2010
• A paper was submitted for INCOSE IS2011: Elm, Joseph P.; “A Study of Systems Engineering Effectiveness: Building a Business Case for SE”
• The SEEWG gave presentations at INCOSE IS2011 on the data obtained from prior research (Eric Honour’s SE-ROI research, NDIA SE Effectiveness study) and the plans for Project 1

Current Projects

• Project 1 – Support of the NDIA / IEEE AESS SE Effectiveness Study

The SEEWG is working with the NDIA Systems Engineering Division and the IEEE Aerospace and Electronic Systems Society to build a business case for Systems Engineering. This study attempts to develop quantitative measures of the impact of specific SE practices on project performance. Initial activities of this study will involve surveying the INCOSE membership to collect project data for analysis. Through 2011, the work has developed and tested a web-based survey instrument while gathering an initial set of data. Within the next few months, wide distribution will be made to encourage submissions into the data.

More information: http://www.incose.org/practice/techactivities/wg/seewg/

Standards and Guides

ISO/IEC 42010, System and Software

Engineering: Architecture Description

The revision to ISO/IEC 42010 (now titled System and Software Engineering: Architecture Description) passed its FDIS ballot. The revision adds concepts and requirements for Architecture Frameworks and Architecture Description Languages, as well as some updates to the overall conceptual framework. See http://www.iso-architecture.org/iso-42010. Publication by ISO should occur this year, producing the new designation of ISO/IEC 42010:2011.

EIA-STD-632 “Processes for Engineering a System” Status

One of the significant systems engineering standards intended for general application is ANSI/EIA STD 632 “Processes for Engineering a System”, the current edition of which was approved for publication in 1999. The standard aims to provide an integrated set of fundamental processes to aid a developer in the engineering or re-engineering of a system.

This standard is in the process of being updated to Revision A. At this time, the Revision exists in an advanced draft form. The update effort is being performed by TechAmerica G-47 group on Systems Engineering. G-47 is lead by Dr. John Evers of Raytheon. Substantial time is being devoted to the Revision A effort at the TechAmerica 2011 Engineering & Technical Management Workshop & Training Conference to be held in Denver, CO, USA, over August 28 to September 1, 2011. Follow-on Guidebook(s) to ANSI/EIA STD 632 are understood to be in the planning stage.

Standard for Technical Reviews and Audits

Following the cancellation of MIL-STD-1521B on Technical Reviews and Audits by the United States Department of defense in the mid-1990s, demand has existed for a soundly based standard on the subject. Some of the predecessor organizations from which TechAmerica was formed were involved in discussion with industry and U.S. Government on the possibility of developing a suitable standard or technical bulletin. This item remains on the program of TechAmerica G-47 group on Systems Engineering. However, effort is understood to be essentially on hold at this time.

Some Definitions to Close On

Waterfall, Incremental, Evolutionary, Spiral, Agile

Waterfall Model: The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible.

Source: http://en.wikipedia.org/wiki/Waterfall_model

Waterfall Model: A model of the software development process in which the constituent activities, typically a concept phase, requirements phase, design phase, implementation phase, test phase, and installation and checkout phase, are performed in that order, possibly with overlap but with little or no iteration.

Source: ISO/IEC 24765:2008 Systems and software engineering vocabulary

Waterfall Model: The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development.

Source: http://searchsoftwarequality.techtarget.com/definition/waterfall-model

Waterfall Model: The waterfall model is a model of a system (including software) development process in which work is planned to be performed in a sequence of, broadly, requirements definition, design, construction or coding, system integration, and finally, system verification, followed by use. Waterfall does not preclude iteration within any of these activities, nor does waterfall preclude ad hoc, as distinct from planned, iteration back to previously performed activities.

Source: Robert Halligan

Comment: Much civil engineering performed within local government is waterfall development. Bridges are almost always developed using a waterfall strategy. Waterfall is not evil!

Incremental Development: Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed.

Source: Alistair Cockburn, http://alistair.cockburn.us

Incremental Development:

A series of mini-Waterfalls are performed, where all phases of the Waterfall are completed for a small part of a system, before proceeding to the next increment, or

Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of a system, or

The initial software concept, requirements analysis, and design of architecture and system core are defined via Waterfall, followed by iterative Prototyping, which culminates in installing the final prototype, a working system.

Source: http://en.wikipedia.org/wiki/Software_development_methodology

Incremental Development: A software development technique in which requirements definition, design, implementation, and testing occur in an overlapping, iterative (rather than sequential) manner, resulting in incremental completion of the overall software product.

Source: ISO/IEC 24765:2008 Systems and software engineering vocabulary

Incremental Development: A system (including software) development process in which work is planned on the basis that requirements are defined, and then the system is developed to meet those requirements through one or more partial implementations, together with the final implementation. Incremental development does not preclude ad hoc iteration back to previously performed activities, including requirements.

Source: Robert Halligan

Comment: Many products with risk due to technology or complexity are developed using an incremental development strategy, e.g. aircraft engines. Incremental development is also used as a result of a variety of other influences, e.g. quick response, time to market, maximization of revenue from multiple releases, money phasing, timed needs, cash flow, have the customer find the bugs, planned technology insertion.

Evolutionary Development: There are two fundamental types of evolutionary development:

• • Exploratory development, where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of the system that are understood. The system evolves by adding new features proposed by the customer.
  • Throwaway prototyping, where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system.

Source: http://css.freetonik.com/wiki/software_engineering:software_process_models?do=backlink

Evolutionary Development: The Evolutionary Development model divides the development cycle into smaller, incremental waterfall models in which users are able to get access to the product at the end of each cycle.

Source: Vaibhav Admane and Anant Iyer

Evolutionary Development: The `evolutionary’ approach is characterized by the planned development of multiple releases. All phases of the life cycle are executed to produce a release. Each release incorporates the experience of earlier releases.

Source: ESA PSS-05-0 Issue 2 February 1991

Evolutionary Development: A system (including software) development process in which the development of multiple sequential releases is planned and executed, each release incorporating all relevant activities of the development cycle from requirements through to implementation, and usually also system verification. Each release incorporates the experience of earlier releases, and usually (but not necessarily) provides useful capability.

Source: Robert Halligan

Note: With attribution to ESA PSS-05-0 Issue 2 February 1991, which, notwithstanding its age, provides a very good definition of evolutionary development.

Comment: Evolutionary development is most appropriate where requirements are expected to change at a significant rate, and the changes reflect genuine change in need. Evolutionary development should not be used as a rationalization for getting on to the fun stuff – almost never is proceeding into development in ignorance of what is already known or knowable about the problem a part of the formula for producing the best result.

Spiral Development: Spiral development is a family of software development processes characterized by repeatedly iterating a set of elemental development processes and managing risk so it is actively being reduced.

Source: CMU/SEI-2000-SR-008, Barry Boehm (University of Southern California, Los Angeles), July 2000

Spiral Development: The spiral development model is a risk-driven process model generator. It is used to guide multi-stakeholder concurrent engineering of software-intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s degree of definition and implementation. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

Source: Barry Boehm, University of Southern California, SPIN presentation 28 June 2000

Spiral Development: An iterative process for developing a defined set of capabilities within one increment. The process provides the opportunity for interaction between the user, tester, and developer. In this process, the requirements are refines through experimentation and risk management, there is continuous feedback, and the user is provided with the best possible capability within the increment. Each increment may include a number of spirals.

Source: Office of the Under Secretary of Defense, U.S. DoD, 2 April, 2002

Spiral Model: The Spiral Model, first described by Boehm in a 1988 article in the IEEE Computer journal, is a type of software paradigm, or methodology used to manage the steps in the creation of a software product. A key article by Barry Boehm, the so-called “inventor” of the Spiral Model, and Wilfred J. Hansen (“The Spiral Model as a Tool for Evolutionary Acquisition,” CrossTalk, May 2001) describes how it can be used in the DoD context. The key success factor in Spiral development is a strong risk management and identification process since the model prototypes and/or builds hard (i.e., high-risk items) first in an intentional attempt to wring the risks out of system development as early as possible. The DoD has expanded the software-centric original model to include systems development, using it as the implementation mechanism for an Evolutionary Acquisition strategy.

Source: https://acc.dau.mil/CommunityBrowser.aspx?id=37330

Spiral Model: A model of the software development process in which the constituent activities, typically requirements analysis, preliminary and detailed design, coding, integration, and testing, are performed iteratively until the software is complete.

Source: ISO/IEC 24765:2008 Systems and software engineering vocabulary

Spiral Development: A stage-based, stage-gate, risk and opportunity-driven approach to system (including software) development whereby the areas of greatest risk and/or opportunity are addressed first and the resolutions to the more uncertain areas are allowed to act subsequently as constraints on downstream solution development. The spiral development approach is characterized by detailed planning for the current stage, and if development is to continue, detailed planning for the next stage, developed towards the end of the current stage, i.e. rolling wave planning.

Source: Robert Halligan

Comment: Although the term “spiral development” was made popular by Barry Boehm, then with TRW, from 1983 onwards, in the context of software engineering, the approach has been practiced without any particular label for millennia. Spiral development can be thought of as a general approach to problem solving in the presence of significant uncertainty – as such, it has widespread application.

Agile Development: Agile Software Development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The Agile Manifesto introduced the term in 2001.

Source: http://en.wikipedia.org/wiki/Agile_software_development

Agile Development: Agile Software Development is a lightweight software engineering framework that promotes iterative development throughout the life-cycle of the project, close collaboration between the development team and business side, constant communication, and tightly-knit teams.

Source: http://www.techopedia.com

Agile Development: What is Agile Software Development? In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.

Source: Agile Alliance, http://www.agilealliance.org

Agile: Project execution methods can be described on a continuum from “adaptive” to “predictive.” Agile methods exist on the “adaptive” side of this continuum, which is not the same as saying that agile methods are “unplanned” or “undisciplined.”

Source: INCOSE Systems Engineering Handbook v. 3.2, January, 2010

On closing: I have attempted to select definitions that represent, in a balanced way, the diversity of meanings given within the engineering community to the defined development models. Should I have missed any significant definition that places a different slant on any of the development models, I would welcome details for later publication.

Robert Halligan, FIE Aust

PPI News

{Julie to plug in}

PPI Events (see www.ppi-int.com)

Systems Engineering Public 5-Day Courses (2011)

{Julie to plug in}

Requirements Analysis and Specification Writing Public Courses (2011)

{Julie to plug in}

Software Engineering Public 5-Day Courses (2011)

{Julie to plug in}

OCD/CONOPS Public Courses (2011)

{Julie to plug in}

Cognitive Systems Engineering Courses (2011)

{Julie to plug in}

PPI Upcoming Participation in Professional Conferences

{Julie to plug in}

Kind regards from the SyEN team:

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

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

Elise Matthews, Production, email: ematthews@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood, Vic 3134 Australia

Tel: +61 3 9876 7345

Fax: +61 3 9876 2664

Tel Brasil: +55 12 3212 2017

Tel UK: +44 20 3286 1995

Tel USA: +1 888 772 5174

Web: www.ppi-int.com

Email: contact@ppi-int.com

Copyright 2011 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 PPI if acknowledgement is not received within 7 days.

1. Preflection (why doesn’t this important word exist?) as opposed to reflection, see www.malotaux.nl/?id=preflection ↑
2. Note that a project doesn’t even deliver value itself. It only can deliver the conditions for the users of the system to create the value. ↑
3. See Ralph R. Young, Effective Requirements Practices (Addison-Wesley, 2001) for a thorough discussion of ‘real requirements. ↑