Engineering projects

Document Sample
Engineering projects Powered By Docstoc
					<div class="KonaBody">
                <h3>1. What Systems Engineering is and what it can
provide to development organizations</h3>
<h3>1.1 Definition of Systems Engineering</h3>
<p>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:<em>... 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.
...</em><br>NASA's System Engineering Handbook , while not truly defining
SE, gives a description of it as:<em>... 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
<p>For the purposes of this article, let us combine the most useful parts
of the various definitions and define SE as follows:</p>
<p><em>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.</em></p>
<h3>1.2 Why do we need Systems Engineering?</h3>
<p>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.</p>
<p>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.</p>
<p>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</p>
<li>the complexity of the system</li>
<li>whether the steps are dictated by regulatory (e.g. DoD)
<li>the development approach chosen (waterfall vs. iterative vs. RAD
<p>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.</p>
<img src=""
border="0" alt="SEDFigure1.gif"> <br>
<h3>Figure 1 - Process View of Systems Engineering</h3>
<p>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.</p>
<h3>2. SE in the Defense Industry</h3>
<p>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</p>
<img src=""
border="0" alt="SEDFigure2.gif"> <br>
<h3>Figure 2 - Typical SE Documentation in Defense Work</h3>
<p>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.</p>
<p>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
<p>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.)</p>
<h4>High technological risk:</h4>

                        <div style="width:300px;float:right;margin:12px
0px 12px 12px">
                   <script type="text/javascript">
            AB_pos          = "intext";
            AB_lang         = "en";
            AB_cat_channel = "8695717077, ";
            AB_path         = "";
          <script type="text/javascript">
            google_ad_channel = "7940249670, " + AB_cat_channel +
            google_language = "en";
            google_ad_region = 'test';
          <script type='text/javascript'
<p>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&amp;D funds.</p>
<h4>Extreme design constraints:</h4>
<p>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.</p>
<h4>Complete answers:</h4>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>3. SE in The Commercial World</h3>
<p>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).</p>
<p>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.</p>
<p>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.)</p>
<p>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
<br>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:</li>
<li>Requirements management</li>
<li>Feasibility analysis</li>
<li>Functional analysis and decomposition</li>
<li>Allocation of requirements to configuration items</li>
<li>System architecture design</li>
<li>Performance analysis</li>
<li>Interface identification and design</li>
<li>Design trade-off studies</li>
<li>Specification generation and support</li>
<li>Identification of system resource requirements</li>
<li>System Reviews
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<img src=""
border="0" alt="SEDFigure3.gif">
<h3>Figure 3 - New Product Development Documentation in A Commercial
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</ul>                 <!--INFOLINKS_OFF-->

Shared By:
mr doen mr doen mr
About just a nice girl