SYSTEMS ENGINEERING PROFILES
[ What is a Systems Engineering Profile ]
[ Profile Topic Areas ]
[ Flowchart of Profile Development ]
[ Web-based Profile Requirements ]
[ Project Deliverables ]
While the discipline of Systems Engineering has been practiced primarily
by the Defense, Aerospace, and some Civil sectors during the past 2-3 decades,
we expect that in the 21st Century,
nontraditional engineering (and even some non-engineering domains)
will benefit from systems engineering techniques.
All of these sectors will need to develop highly complex systems,
with strict requirements on performance, reliability, economy,
and short time-to-market.
A Systems Engineering Application Profile (SEAP) is a high-level
description of how systems engineering knowledge, procedures,
processes, and technology can be used for
problem solving within an application domain.
After reading a profile, readers should be left with a basic
understanding of what makes an application domain tick!
Benefits
By assembling and presenting a suite of applications profiles in one place,
we hope to identify patterns in problem solving strategies and techniques
that are common to multiple application domains (INCOSE 95).
Development of these profiles will advance systems engineering education,
promote the discipline of systems engineering,
and enable systems engineering practice across application domains.
I encourage you to develop a profile for a domain in
which you have a keen interest, and for which you
have access to information from experts.
Because team development is an essential component of
systems engineering, profiles should focus on the end-to-end
solution of a problem that requires the resources of at least 20-30 people.
"How I installed a web server in my apartment" is a good example
of an an unacceptable topic. Suitable topic areas include:
Agriculture
Automated Highway Systems
Chemical Systems (e.g., oil/chemical refineries)
Commercial Aircraft
Electronic Design Automation
Electronic Packaging
Energy Systems
Environmental Restoration/Cleanup
Entertainment Systems (e.g., Networked Video Games)
Geographic Information Systems
Healthcare Information Systems
Highway Transportation Systems
Intelligent Building Systems
Intranets/Extranets/Web Browsers....
Infrastructure Systems (e.g., bridges, dams, roads etc..)
Medical devices
Microelectronics manufacturing
Motor Vehicles
Natural Resources Management
Office Automation
Petroleum Exploration
Power Systems Engineering
Robotic devices
Satellite Design and Deployment
Structural Systems (e.g., buildings and highway bridges)
Systems Engineering Automation/Tools.
Telecommunications
Telemedicine
Urban Planning
Waste Management and Disposal
Of course, you are welcome to propose your own topic.
Good introductions to some of these application domains can be
found in special issues of Scientific American,
Communications of the ACM and IEEE Design and Test.
Another good place to look is the Proceedings of the International
Council of Systems Engineering (INCOSE), especially papers that
have been presented in the "Systems Applications" tracks.
The design and operation of complex systems involves the
development and coordinated management of complex relationships
among a variety of subsystems and components.
Some of these entities and relationships are related to the project itself;
others belong to the organizational infrastructure
that supports the project development.
With these comments in mind,
Figure 1 shows the ingredients, processes, and viewpoints that
should be included in your systems profile.
Figure 1 : Flowchart for Systems Profile Development
SEAPs should help readers with technical and management
backgrounds and interests understand why an application exists,
what the application domain does, how it accomplishes its purpose,
and who makes things happen. These factors are shown along the
left-most column of Figure 1.
SEAPs should also look at system lifecycle development as the
composition of interacting processes:
-
In part, system development is an organizational process to be managed .
Important factors in an organizational design are estimation of human resources,
and management and scheduling of activities and information/data among these resources.
The organization should serve the dual role of supporting individual projects,
while also work towards the business mission, and meeting stakeholder and customer needs.
These concerns are shown on the left-hand side of Figure 1.
-
System development is also a technical process to be accomplished .
Important components of the development are mapping of customer/business goals
into technical and performance requirements, transforming the requirements
into desireed systems behavior, synthesis of a project structure,
and procedures for building and testing the engineering product/service.
See the right-hand side of Figure 1,
Each process should consider activities/tasks from the conceptual
stages of development through retirement of a product/service.
Organization and Management Viewpoint
Four broad classes of questions for the organization are as follows:
-
Why does the organization exist?
-
Profiles should describe the organization's owners and stakeholders,
the key business opportunities for the organization and, if possible,
the its long-term strategic goals?
-
Who are the intended customers? Where are they located?
-
Who are the main players (i.e., competition) in the application domain?
-
How is the application domain/industry affected by
economic and commercial forces?
-
Who in the organization actually does this work?
-
Profiles should describe the roles and responsibilities of the main groups
of people within an organization. Some groups will support the organization
as a whole -- others will be assigned to a specific
project (e.g., management, architects, engineers).
-
Clearly identify the roles and responsibilities of the main project
participants (e.g., planners, architects, engineers, contractors).
What is the working relationship among these groups?
-
How do people within an organization interact with other organizations,
and with their customers and stakeholders?
-
Are the project operations centralized, distributed,
farmed out to contractors, etc?
-
What does the organization do?
-
Profiles should describe the events and scenarios
that affect the organization behavior.
-
How is the organizational behavior guided by
organizational requirements,
legal requirements,
project requirements, standards, and so forth?
-
What functions and processes are put in place by
an organization to handle expected/unexpected scenarios?
-
What level of capability (i.e., CMM) do organizations
within the domain have?
-
How does the organization achieve its purpose?
-
How is the organization structured so that the
behavior can be mapped onto structure to produce
a smooth running operation?
-
Are formal systems engineering processes used,
either explicitly or implicitly, within the domain?
If not, why not?
-
To what extent is the organizational structure
vertically/horizontally integrated?
Engineering System and Project Development Viewpoint
Four broad classes of questions for development
of the project/engineering system are as follows:
-
Why is the engineering system (i.e., product or service) being developed?
-
From both a customer and organizational perspective,
profiles should describe the goals and objectives of the engineering system?
-
What are the purposes of the engineering system?
-
Who will use it? And where?
-
What factors influence the economics of product development,
choice of technology etc...
-
What are the risks in development?
-
Are formal systems engineering processes used,
either explicitly or implicitly, within the domain?
If not, why not?
-
Who is responsible for system development and operation?
-
What are the roles and responsibilities of the main groups of people
working on the system development (e.g., architects, engineers)?
-
In a high-level sense, what kinds of information passes
among these groups of people?
-
Who is responsible for operating and maintaining the system?
-
What does the engineering system do?
-
From both a customer and organizational perspective,
what will the engineering system do?
-
In what range of environmental conditions will the system be
expected to operate in an effective manner?
-
What are the system inputs and system outputs to/from the external environment?
-
What are the system boundaries? For example, boundaries between:
-
The system and its users;
-
The system and the external environment;
-
Parts of the system that can be adjusted and controled, and those that can't.
-
Profiles should describe operational scenarios for
fragments of the engineering system behavior.
-
How will a user (or the environment) interact with the system during the scenario;
-
How are events and operational scenarios translated into
operations and functional performance characteristics?
-
How do the requirements generated by
scenarios flowdown to the subsystems?
-
Which scenarios support the generation of design ideas?
Which scenarios enable evaluation of a proposed design?
-
What are the important measures of effectiveness for
the application domain?
-
How does the engineering achieve its purpose?
-
What is the lifecycle of a typical product (or service) in the application domain?
-
What standards (or guidelines or specifications) are the important to the application domain/industry?
-
How are systems designed so that they are adaptable to
changes in technology, standards, and regulation?
-
For a typical example of the engineering system, how is the
system behavior mapped onto system structure to produce a system design?
-
How does the application domain partition its activities into
individual functions and processes? In otherwords:
-
How do requirements flow down to individual processes and functions?
-
How will the various system components be used?
-
What are the existing and planned interfaces?
-
How will the system interface with the external environment; parts of the
systems for which the team has no control?
-
How are interfaces between sub-systems defined?
-
Do the interfaces enable a pathway of data (or information or product)
flow that is consistent with the desired behavior?
-
What are the constraints (hardware, software, economic, procedural)
to which the system must comply?
-
What is the build and test procedure for a typical product/service
in the application domain?
-
Will the final form be a model, prototype,
one-of-a-kind implementation, or mass production?
-
How are "risks in development" and "quality control" issues handled?
-
Is time-to-market a key factor in the success of the product?
Profiles should consider the extent to which these viewpoints can
be enhanced through the use of technology, sophisticated techniques
for modeling system behavior, and optimization and trade-off analysis procedures.
Each web-based profile should contain the following sections:
-
Introduction
Profiles should begin with a well written introduction to your application profile.
The introduction should set the stage for the content to follow,
and address some of the big picture issues shown in Figure 1.
(e.g., The goals and objectives of the engineering system).
-
Organization and Management
This section should describe:
-
Why the organization exists.
-
What the organization does.
-
How the organization achieves its purpose.
-
Who in the organization actually does the work.
-
Assessment of Systems Information (i.e., Requirements Engineering)
Create a concept diagram (and text) showing the technical approach or
design concept -- in abstract terms:
-
How will the system be integrated to meet the
performance and functional requirements?
Create a list of typical initial requirements for your application domain.
-
The list (or collection of lists) should reflect the
needs of the project participants, and as appropriate,
indirect requirements such as standards,
environmental and legal regulations.
-
System Behavior and System Structure
Profiles should describe the system behavior and system structure,
as they exist in the early stages of system development.
System Behavior.
Identify and define operational scenarios that cover the range of
anticipated uses of the system product/service.
For each scenario, define:
-
The context (i.e., situation) in which the scenario will occur.
-
A sequence of events (or tasks) that must
be completed for the scenario to play out.
-
Can the tasks be done in any order, or is their an imposed sequence?
-
Requirements that must be satisfied in order
for the system to behave as expected.
Describe the process of requirements flowdown to the subsystems,
and further refinement of requirements via scenarios at the subsystem level.
System Structure.
Develop a small number (i.e., more than one!) of alternative system structures.
For each structure, define:
-
Interactions with the environment and other systems;
-
Physical interconnectivities with interfacing systems,
platforms, or products.
-
Preliminary System Design
Develop a small number of preliminary system designs by mapping the
system behavior onto alternative system
architectures (i.e., more than one architecture).
-
How are the functions identified at the "system behavior" step
mapped onto the system structure components?
For each alternative:
-
Create a functional/physical matrix showing the
sub-systems (or components) used by each scenario.
-
Verify that the range of operations will work by
walking step by step through each scenario (i.e., do the system
interfaces allow for the desired system behavior?).
-
Measures of Effectiveness
Describe the measures of effectiveness reflecting
customer expectations for your application domain.
-
Key measures of effectiveness include simplicity and ease-of-use,
economics, high quality, short time-to-market, and so forth.
-
Does the application domain make use of production functions?
If so, what kinds of production functions make sense?
Present one or two examples showing how
these measures of effectiveness apply in practice.
-
Optimization and Trade-Off Analysis
Take a significant problem within your application area,
and formulate it in terms of a
single- or multiobjective "optimization" problem.
-
What are the design variables?
Are they discrete or continuous?
-
How are requirements translated to optimization constraints?
-
What are the key measures of effectiveness for the application domain?
-
How are design alternatives generated?
-
What are good ways to display and compare the
performance of the design alternatives?
-
How are system trade-offs made?
-
What are the limitations of the methodology you have adopted?
The important point at this stage is choosing a solution pathway
that is appropriate to the problem at hand.
I expect that some projects will lend themselves to the
solution of linear programming problems.
Others may lend themselves to analysis with decision
tables/tree and possibly the use of utility functions.
Both approaches are fine.
What I will be looking for is justification of the problem formulation,
and a critical assessment of the analysis that is conducted (both good and bad).
Use of Online Spreadsheets (Optional).
The purpose of this section will be to explore the use of Java Applets
for analysis of simple systems (and decision making)
within the application domain.
-
Develop a small set of example problems that illustrate how
systems analysis methods can be used for basic decision making
within the application domain.
-
How can Java bar chart, line charts, spreadsheets ... etc .. be used to
convey ideas?
-
Can you find applets on the web that could be customized to
the analysis of simple engineering/business systems?
If the library of Java Applets cannot portray a simply idea,
please let us know and we will consider writing a special applet
for your purpose.
-
Build and Test; Operations and Maintenance
Briefly describe procedures for ``building and testing''
entities in your application domain.
-
What does a typical plan for building the system look like?
-
Are subsystems and components built in-house, or procurred?
-
How would you characterize the overall process of building the
system (e.g., top-down; bottom-up; a combination of bottom-up and top-down?).
-
What role to "operational scenarios" play in testing/validating
the system performance?
Briefly describe procedures for ``operation and maintenance''
of products/services in your application domain.
-
Systems Engineering Challenges
-
What are the near- and long-term systems
challenges facing the industry/application domain?
-
What technologies could the application domain/industry benefit from --
for example, simulation, optimization, decision analysis,
generation of design alternative, and so forth.
-
Contacts and References
-
Provide a list of contact addresses and references for your project.
-
Profiles should contain pointers to on-line case studies (if they exist).
To ensure that the previous sections are accurate, I expect that
you will contact and interview professionals working within the industry/domain.
Where appropriate, provide links to references
and case-studies located on the web.
Student groups may have one or two persons.
There will be three project deliverables:
-
Project Announcement
I want to build a web page that briefly summarizes each project.
Each summary should contain:
-
The project title (with a link to
the project on the web),
-
The authors (with links to their home pages), and
-
An abstract explaining the goals of the project.
(I encourage you to revise/improve your project abstract
up until about the Thanksgiving break).
-
Web-based Presentation
Each group will be required to present their project on the web.
using HTML, Javascript, Java, cool graphics, and so forth.
Segments of projects containing lots of equations may be
delivered in postscript (or PDF or MS Word) format,
with a link from the appropriate web page to the document.
-
Hand in a Final Project Report
Hand in a hardcopy of your project.
Projects are due 5pm, December 15.
Note.
These are hard deadlines. I'm leaving the country on December 22,
and if you don't get your project to me way before then, you won't
get a grade for the semester.
This comment is particularly important for students in ITV-land.
Assessment
In grading the projects I will be looking for:
-
A clear, concise, statement of the problem domain
being considered (longer is not necessarily better);
-
A strong connection between the nature of the problem domain
and the system development and management that emerges;
-
A descriptive presentation of the systems analysis --
a picture that captures the effectiveness measures and limitations
of an ensemble of design alternatives may be worth a thousand words;
-
A critical assessment of the strengths and weaknesses of present-day systems;
-
Discussion of the near- and long-term systems
challenges and opportunities facing the application domain.
Innovative use of web technologies will be appreciated and is strongly encouraged.
REFERENCES
-
International Council of Systems Engineering Applications
Forum Working Group,
Systems Engineering Application Profiles, Version 1.0,
May 1, 1996.
-
Systems Engineering Fundamentals,
Defense Systems Management College Press,
Fort Belvoir, Virginia, October 1999.
Developed in August 1998 by Mark Austin
Copyright © 1999, Institute for Systems Research, University of Maryland