 |
 OPERATION DESERT STORM trucker cap 1 16 91 tank hat M1A1 Abrams military $15.00 Time Remaining: 23d 13h 28m Buy It Now for only: $15.00 |
 M1 ABRAMSTANKARMY STARDIGITALACUBLACK HATCAP $9.99 Time Remaining: 26d 21h 4m Buy It Now for only: $9.99 |
 US ARMYM1 ABRAMSARMOURARMORTANK HATCAP $8.99 Time Remaining: 24d 5h 39m Buy It Now for only: $8.99 |
 US ARMYM1 ABRAMSTANK HATCAPCOTTONKHAKIUPSCALE $14.99 Time Remaining: 24d 5h 7m Buy It Now for only: $14.99 |
 USMCMARINES M1 ABRAMSTANK HATCAPCOTTONUPSCALE $14.99 Time Remaining: 12d 18h 12m Buy It Now for only: $14.99 |
Engineering projects
1. What Systems Engineering is and what it can provide to development organizations
1.1 Definition of Systems Engineering
There are a multitude of definitions for systems engineering that have been published, most of which have common themes in them. For example, MIL-STD-499A defines SE as:... the process(es) required to transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test and evaluation. ...
NASA's System Engineering Handbook , while not truly defining SE, gives a description of it as:... a continuous, iterative process with a built-in feedback mechanism that is used throughout a project or program's life cycle to arrive at the best system architecture and design possible.
For the purposes of this article, let us combine the most useful parts of the various definitions and define SE as follows:
The set of activities which oversees the development process, ensuring that the product requirements are complete and fully satisfy the customer's needs, the technical analyses are done, and everything necessary to integrate the parts of the product so they work together as a unit have been identified and completed.
1.2 Why do we need Systems Engineering?
The field of endeavor that we call systems engineering is a combination of different fields and disciplines. It typically encompasses systems analysis, requirements definition and management, systems design and architecting, often the subdisciplines of "ilities" such as reliability, availability, maintainability, etc., and other specialties as make sense in the specific circumstances.
However, simply listing the specific areas of SE does not give a sufficiently accurate picture of the overall capabilities that SE is capable of if the reader does not have a background in it. Perhaps a better term for what SE is capable of doing in the commercial world is systems management rather than systems engineering, since this gives more emphasis to the breadth and to the long-term role of the systems group than just the engineering portion. In defense/aerospace development, SE typically gets heavily involved through the development life-cycle up to delivery to the customer, then minimally involved afterwards. In the commercial world, the systems group can sometimes maintain its role in the on-going management of the system, e.g. in software applications developed for in-house use.
Whether SE is operating in a defense or a commercial environment, the system life cycle and the SE process begins with the identification of a user need. This need is then translated into a set of user requirements and from there to a set of system-level requirements through a needs analysis and requirements definition effort. This is followed by other activities during conceptual system design (typically involving the synthesis, analysis, and selection of system-level conceptual solutions and/or technology applications) and preliminary system design (involving the modeling of expected system behavior, the allocation of system-level requirements to subsystems, and their subsequent translation into more detailed design specifications). The extent to which these steps are performed or not performed depends on
- the complexity of the system
- whether the steps are dictated by regulatory (e.g. DoD) requirements
- the development approach chosen (waterfall vs. iterative vs. RAD techniques)
At a high level the basic steps always need to be done. The more detailed and specific steps are done as the need dictates. The following figure is used in both MIL-STD-499B and in EIA IS-632. It is equally applicable to both defense SE and to commercial SE.
Figure 1 - Process View of Systems Engineering
The size and constitution of the SE department, or even the necessity for one, depends both on the system being developed or operated and on the desires of the system's customer. For a small, stand-alone software application, or a single-board power supply, a dedicated systems engineer is not necessary. The function of integration is still necessary, but it can be performed by the designer. For a mainframe program many thousand lines of code in size with multiple interfaces to other programs or to users, experience has shown that systems engineering can provide benefit far in excess of its cost. If SE does nothing more than requirements analysis, the effort and the department is worthwhile. For new product development, the Software Engineering Institute (SEI) estimates that 40% of software bugs are due to poor or missed requirements. In the DoD, 80% of the life-cycle cost of a software-intensive system is for maintenance and the cost of fixing software increases by an order of magnitude as it passes from development to maintenance. At one of the author's past employers, the experience was much better than this because the developers were also the maintainers (a situation which is not always true, especially since contractors are used so much in SW development). Even in this case, SE can easily pay for itself multiple times by just properly managing requirements.
2. SE in the Defense Industry
SE in the defense industry has a reputation for being stilted, formal, complex, and having high overhead. Probably the only true part of that is that it requires high overhead and has strict reporting requirements. Not only is there extensive analysis work required, but it has to be strictly documented and reported. So SE writes a lot of documentation (MNS, SEMP, A-, B-, C- specs, ICDs, etc.) and gets involved in the numerous reviews that are a part of large, risky system development: SRRs, SDRs, PDRs, CDRs. The following figure is adapted from DoD Directive 5000.1
Figure 2 - Typical SE Documentation in Defense Work
The purposes of the documentation requirements in the defense industry are to make it as easy as possible for the government to understand and follow what's going on in the project, to audit it, and to prove that they have full control over it. These needs actually drive much of the DoD's development methods. Since the military does not do its own development work as a rule, they rely on thousands of people of unknown abilities in many companies to develop their complex systems. The military resolved this problem by setting up detailed processes and procedures in order to provide greater assurance that the systems will be well and thoroughly produced. The government is faced with particular problems in this regard that private industry does not face, or at least not to the same extent.
While there is a lot of formality and rigidity within the Defense industry , there are legitimate reasons for the processes. The drivers to these SE methodologies and processes are: complexity, high technological risk, extreme operational constraints, thoroughness, and auditability. Note that economics are generally not a consideration here. Once a project receives Congressional funding, the economics of it are not debated any longer until the contract is awarded and a project financial monitoring systems is put into place. (I include NASA here because the important characteristics are the same. It is not unreasonable to include the commercial aircraft developers also, Boeing, Airbus, McDonnell Douglas, because their need to do thorough SE is much the same as the military's.)
Complexity:
The defense industry has always pushed the margins on SE methods because their systems were often new, technologically risky, and very complex. There could be no compromise to knowing that they had thought of the best achievable design solutions to very difficult requirements. The space program, aircraft carriers, the stealth bomber, the Abrams tank, and many others all require rigorous analysis and integration to ensure that everything works as a system and not as individual and incompatible systems. (The failure to hire an integrator for the avionics on the B2 ended up costing the USAF several times more than the integration contract bid when the electronics were put together and the automatic defense systems were found to interfere with the flight avionics.)
High technological risk:
In the early days of the Industrial Revolution, the most advanced technologies were developed by private industry, occasionally (but usually not) with government help. The telephone and radio, the early airplanes and automobiles, the early railroad locomotives were all cutting edge technology done without government assistance, the developers assumed all the risk involved. While there was Army-funded development for tanks and other military vehicles early this century, after World War I the lead in technology moved back to the private sector (an exception being aircraft development done in both sectors). During World War II, the government again took over the lead in developing the most advanced technology and this time held onto it for over forty years. After W.W.II and Korea, the space program began a huge technology push in parallel with that created by the Vietnam conflict. Unprecedented amounts of government money were spent on large, complex, risky projects. Private industry could never have done the level of development that was demanded by the Apollo program or by the space shuttle. The computer industry would not be nearly as advanced were it not for massive amounts of government R&D funds.
Extreme design constraints:
Space and military equipment must operate under widely varying constraints of temperature, vibration, humidity, and shock to reliabilities typically in excess of 99%+. Designing for such extremes and to such high reliabilities requires a great deal of design analysis and statistical modeling to assess each design. Field-level maintain-ability is also an important design consideration as is the man-machine interface (MMI) under field conditions of high stress. There are many subfields within SE devoted to analyzing, mathematically and in other ways, these areas to ensure that the product will satisfy the requirements under all conditions at all times.
Complete answers:
Since the government puts a higher emphasis on a perfectly workable system (if it doesn¹t work, someone may get hurt or killed) than it does on making a profit, there is much greater emphasis on examining development issues as thoroughly and as completely as possible regardless of cost. While schedule impacts are sometimes a concern, the times the government gets the most worried is when they need the materials for a war in progress or when a space launch window is threatened (due to the high dollar cost and significant schedule impact).
When the technological risk is high, the dollar cost is high, and/or human life depends on the proper operation of the system, little expense or schedule is spared to do a thorough SE job. Every aspect of the system is examined, studied, analyzed, and written up in order to hand a package of documentation to the government personnel that covers all of the risky aspects of the system. Systems engineers who have worked on major aerospace or defense contracts know that 100% coverage is as expensive and unlike as 100% reliability, and at detailed levels there is sometimes professional disagreement on how risky a certain aspect or a design is. But the majority of the time on these systems a lot of time and effort is put into providing as complete an analysis to the buyers as possible.
Auditability:
One aspect of SE work that is true in the defense industry that is not true in much of the commercial world is that every technical decision must have detailed analysis and documentation behind it if there is any risk perceived at all. The Congressional Budget Office, the OMB, or the GSA may come behind each development effort to ensure that the government receives fully developed systems for its financial outlay. This puts pressure on project managers to make certain that they can point to specific studies or analyses for each technical decision they make.
This requires not only a lot of SE personnel to do the work and to give the briefings, but it requires a lot of overhead to write and control the documentation. Since the government does not need to operate at a profit, the high labor costs associated with providing detailed technical audit trails are not of concern. Spending twenty-five thousand dollars to audit, investigate, and trace a twenty-five thousand dollar contract item is acceptable in this environment.
However, today the entire military development approach is geared toward a pace of development that now seems almost moderate in comparison to the rapid-fire changes in the computer industry. The DoD is limited by policies and procedures that were developed when the pace of change was much slower. It drove the pace for 30-40 years, now it's being held back by those policies and procedures. There are increasingly numerous examples of high technology development that is being paced by commercial needs rather than by government needs. Industrial Light and Magic is pushing Silicon Graphics much harder than SGI's aerospace customers are. Indeed, the hardest driver to government procurement and development efforts now is the Year 2000 problem a problem they will be unable to solve in time if their processes do not change quickly.
3. SE in The Commercial World
The primary differences between SE in the commercial world vs. in the defense industry used to be very consistent and predictable. As stated earlier, defense work was very expensive, very risky, and generally developed very large programs. This resulted in SE practices which were time and resource consuming, required a lot of documentation and "proof" and which the commercial world saw as expensive (it is) and unnecessary (it isn't in that environment).
This relationship has been changing over the past few years. Previously, there was little doubt that the military and space systems were more complex and technologically risky than commercial ventures (with the notable exception of passenger aircraft and cargo or passenger ships) and thereby needed strict systems engineering approaches. While these government systemsii still have strict auditability requirements and extreme design constraints, it can no longer be said that they are more complex than many of the systems developed commercially. The inherent complexity of semiconductor chip manufacturing and of large-scale software development has made many commercial systems as complex as defense systems, if not as large physically.
Today's laptop computers have more processing power and more memory than the Tracking and Data Relay Satellite (TDRS) that the government depends so heavily on. Microsoft Word for Windows, V.1, had over 384,000 source lines of code. Not many companies can afford to develop a new computer or a program of thousands of lines of code without strong requirements analysis of what the customer will buy and without sufficient test and integration. This computer and the programs that it runs are complex systems that require strong systems management efforts to be successfully developed. (For many years much of the commercial world considered Systems Engineering to be necessary only for large military systems because they couldn't see the benefits for themselves. Many of the aerospace engineers that left aerospace during the downsizing a few years ago quickly learned that putting "Systems Engineer" on their resumes resulted in their resumes being quickly rejected when they applied for jobs in the commercial world.)
SE in the commercial world has a significant advantage over SE in government projects, we have the freedom to pick and choose which approaches, methods, and techniques will give us the information we need to develop products and grow the business, but not be driven by rules and regulations that do not apply. We can do as much analysis as needed to get the answer without having to prepare formal documentation and presentations. The restrictions we face are that SE must justify what it does with respect to a) time-to-market impacts, and b) cost/benefit analyses.
That said, many of the approaches used in the defense industry can be adapted and tailored to commercial development when it makes sense to do so. The differences lie not so much in what is done as in how it is done. The best practices on the defense side flow into the commercial side, a situation which accelerated during the defense downsizing of the early 90's. Some of these practices are listed in the article by Verma and Fabrycky. Upon reading their list it becomes obvious that there are several SE activities that show up quite often. These are:
- Requirements management
- Feasibility analysis
- Functional analysis and decomposition
- Allocation of requirements to configuration items
- System architecture design
- Performance analysis
- Interface identification and design
- Design trade-off studies
- Specification generation and support
- Identification of system resource requirements
- System Reviews
When considered in toto this set of activities more properly forms the field of systems management than of systems engineering. I.e. when these things are done correctly, the systems development process is managed rather than just being a set of time-scheduled activities done by different groups.
In a presentation given to the Los Angeles chapter of INCOSE in 1996, the presenter, a vice-president at Douglas Aircraft, mentioned that while she was at Boeing several years ago they joint-ventured with a Japanese firm. There was technology sharing on both sides, with Boeing sharing many processes to develop new aircraft, except for sharing their systems engineering methods. That was considered a significant commercial advantage and thereby company-proprietary and not to be shared.
While SE practices and methods in the government procurement industry are well established and documented, the commercial industry is still trying to determine what SE methods make most sense for it. While a government contract will start the requirements decomposition with the A-spec, what makes more sense in the commercial world is to work directly with the user to determine what the user requirements are. This approach has put more emphasis on the user¹s requirements and has led to various methods of defining what those are. The techniques being tried vary from user interview techniques, to variations on requesting the user provide an A-level spec, to the storytelling/scenario building technique promoted by Yacobson in the field of Object-Oriented software.
The author once worked at a data processing company that utilized a bank of mainframe computers that churned through terabytes of data in order to produce customer-desired lists. The process we created for developing new products and the associated documentation were:
Figure 3 - New Product Development Documentation in A Commercial Arena
In the early stages of this new process, the SE group struggled heavily in writing the requirements specifications for the existing system. As often happens in the commercial world, there was almost no useable system-level documentation. What documentation that existed was programmer-level documentation that had been written much earlier and rarely updated. There was no interface documentation and the company felt that none was needed because the programmers knew what the interfaces were. The result of this undisciplined approach was that the SE personnel had to hold many meetings with large numbers of programmers (each of whom knew only a small piece of the system) in order to document the programs and the data flow. The job became so hopeless that the SE group eventually stopped documenting the existing system and concentrated its efforts on writing requirements for new products.
The opportunity SE has to meet with the customer is a leverage point that can be used to discuss the user¹s needs with them and the impact those needs have on development time and on overall cost. Often in government development work there is a high expectation by the government that the system they want can be delivered by the date they want. Nearly as often, this turns out to be unrealistic. SE can provide a great benefit to both the customer and to the developers if they can give the customer a more realistic understanding of the technical complexities and can manage their expectations.
Another area where commercial practices differ lies in the emphasis on getting products to market quickly. The government does not have to worry about competitors delivering tanks or aircraft faster than they do, but private industry must compete for market share and get products to the customers as quickly as possible. This has caused an emphasis on methodologies which reduce the overall development and production timeline. Various forms of rapid application development (RAD) methods are constantly being investigated and tried in order to reduce the timeline. There is a body of management literature which shows that the emphasis in product development needs to be on schedule, not on cost, because the faster you can deliver a product into the customer¹s hands the more market share and profit you can make.
This is not to say that government has ignored the time-to-market issue. Pressure by Congress to reduce costs have often resulted in the conclusion that since development costs are high, the cost reductions desired can be achieved by reducing development timelines. Integrated Product Teams (IPTs) were developed in the aerospace industry and RAD techniques have been developed at government labs. It is just more difficult to emphasize schedule when you¹re developing products with so many unknowns and when the profit pressure to bring products to market quickly is absent.
As a general rule, commercial companies are looking at systems engineering methods and struggling to define what makes sense for them. The author was one of a group of systems engineers with aerospace backgrounds hired by TRW Information Systems during the development of a major infrastructure project. After creating an SE group and staffing it, the organization then decided that the formal SE methodology the engineers brought in was too foreign to its culture and backed away from instituting strong SE methods and procedures. Other companies, such as Toyota and Nissan, were much more successful at understanding what they needed and incorporating it into their culture. Their Lexus and Infiniti lines were developed around IPTs and utilized SE processes to design and produce each car as a single integrated unit rather than as a collection of separate components.
In summary, it is possible to bring the advantages of systems engineering into the commercial arena. Careful attention must be paid to the costs and benefits of doing so, and it is incumbent on the SE personnel to justify their methods and procedures so that upper management can readily see the financial advantages of performing systems engineering. Indeed, this type of justification may be an integral part of SE in the commercial world.
Footnotes:
1. include NASA here because the important characteristics are the same. It is not unreasonable to include the commercial aircraft developers also, Boeing, Airbus, McDonnell Douglas, because their need to do thorough SE is much the same as the military's.
2. For many years much of the commercial world considered Systems Engineering to be necessary only for large military systems because they couldn't see the benefits for themselves. Many of the aerospace engineers that left aerospace during the downsizing a few years ago quickly learned that putting "Systems Engineer" on their resumes resulted in their resumes being quickly rejected when they applied for jobs in the commercial world.
About the Author
M1A2 Abrams tank