SDOE 605 SYSTEM INTEGRATION AND TEST

MODULE 1: INTRODUCTION
Raymond Pennotti, Ph.D.
Adjunct Professor
Stevens Institute of Technology
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 1
1/21/2020
 Caring for the Customer
Integration, Verification and Validation
from the Outside In

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 2
1/21/2020
 Preliminary Comments
• The principles we will discuss will be illustrated with detailed examples
from specific technical areas. They are readily adaptable to a broad range
of systems and technologies and I encourage class discussion relevant to
your own experience and interests.

• This course addresses practical engineering issues. Your level of

contribution to class discussions and exercises will directly impact the
value of the course to you and others.

• There is no assigned text for this course and the class notes are not
comprehensive. Students who miss classes are expected to consult with
other members of their teams to review class discussions.

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 3
1/21/2020
 Course Objectives
 This is a course on Systems Integration, Verification and Validation. Accordingly,
participants will understand the following upon the conclusion of this course:
• Understand the role of System Integration, Verification and Validation in the Systems
Engineering Lifecycle
• Understand the relationship of Integration, Verification and Validation to Stakeholder Needs,
System Requirements, System Architecture and Design
• Recognize the need to incorporate Integration, Verification and Validation planning as an
integral part of the system requirements and architecture definition processes
• Plan and execute the Integration, Verification and Validation of complex systems of interest
• Design and Build Integration, Verification and Validation systems for complex systems of interest
• Assess and Manage Risk throughout the Systems Engineering Lifecycle
• Select suitable test methods, techniques, and metrics and apply fault diagnosis techniques
• Represent Integration, Verification and Validation resource requirements and issues in a Project
Management context
• Manage customer needs and expectations during Integration, Verification and Validation

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 4
1/21/2020
 Grading
GRADED EVENTS % of Course
Class Participation & In-class Assignments 10%
Team Project Assignment 40%
Individual Project Assignment 50%
TOTAL 100%

Grade Percentage
A 93 - 100
A- 90-92 Email all assignments,
B+ 87-89 comments and questions to
B 83 - 86 rpennotti@gmail.com
B- 80-82
C+ 77-79
C 70 - 76
F <70

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 5
1/21/2020
 Make-up Assignment
for Missed Classes
• Students missing any class will be required to
complete a graded make-up assignment:
– For those classes missed, identify and discuss the three
major conclusions from each session.
– Use class notes that you have reviewed with one or more
students who attended the missed class.
– These reports will impact your grade.

1/21/2020 © Copyright 2015 Stevens Institute of 6

Technology, All rights reserved
  Bell Labs
Dr. Raymond Pennotti
 Research on Cellular Telecommunications
 Systems Engineering, System Test and Field Test
 AT&T Paradyne
 VP Networking Products
 AT&T Network Systems
 TDMA, CDMA Systems Deployment
 Global RF Engineering
 Wireless Business Unit Technical Liaison – Riyadh, Saudi Arabia
 Lucent Worldwide Services & Alcatel-Lucent
 VP Global Deployment and Customer Service – GSM and UMTS Systems – Nuremberg, Germany
 VP Professional Services, Network Integration
 Pinnacle Wireless
 VP System Integration
 Consultant – World Trade Center Projects
 Bell Labs
 Consultant – Telecommunications Carrier Operations
 Stevens Institute of Technology
 Adjunct Professor – School of Systems and Enterprises
 Executive and Leadership Coach (SharedVisionCoaching.com)
 Education and Training
 PhD (EE) –Polytechnic Institute of Brooklyn
 NYU Stern School
 Congressional Fellow – Committee on Science and Technology, U.S. House of Representatives
1/21/2020  Rutgers University – Leadership Coaching for Organizational Development
7
 Course Outline
 Introduction
 System Validation
 System Integration
 System Verification
 Testing
 Fault Diagnosis
 System Integration Project Management Responsibilities
 System Integration Impact on Customer Management

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 8
1/21/2020
 The Role of
Integration, Verification and Validation
in the Systems Engineering Lifecycle

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 9
1/21/2020
 What’s the Big Deal?

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 10
1/21/2020
 Traditional View of System Development –
User Needs
The Waterfall Model
Development
starts
System
Requirements

Architecture Development is
complete

Design

Confirmation
Integration

Verification
and Validation

Operations and
Maintenance
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 11
1/21/2020
 What’s the Big Deal?

Verification and Validation:

Simply confirming that no

mistakes were made

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 12
1/21/2020
 What’s the Big Deal?

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 13
1/21/2020
 What is a System?

© Copyright 2015 Stevens Institute of

14
Technology, All rights reserved
1/21/2020
 There are several definitions of a “system”
and all of them are reasonably consistent

Ubiquitous: A set of interrelated

components working together to
accomplish a common purpose.

INCOSE: An interacting
combination of elements viewed in
relation to function.

Mil-Std 499B: An integrated composite of

people, products, and processes that
provide a capability to satisfy a stated
need or objective.
 A System Is…
a whole that cannot be divided into independent parts
without losing its essential characteristics as a whole.

© Copyright 2015 Stevens Institute of

16
Technology, All rights reserved
1/21/2020 16
 A System Is…
a whole that cannot be divided into independent parts
without losing its essential characteristics as a whole.
It follows from this definition that,
a system’s essential defining properties
are the product of the interactions of its parts,
not the actions of the parts considered separately.

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 17
1/21/2020 17
 A System Is…
a whole that cannot be divided into independent parts
without losing its essential characteristics as a whole.
It follows from this definition that,
a system’s essential defining properties
are the product of the interactions of its parts,
not the actions of the parts considered separately.
Therefore,
when a system is taken apart,
or its parts are considered independently of each other,
the system loses its essential properties.

© Copyright 2015 Stevens Institute of

18
Technology, All rights reserved
1/21/2020 18
 A System Is…
a whole that cannot be divided into independent parts
without losing its essential characteristics as a whole.
It follows from this definition that,
a system’s essential defining properties
are the product of the interactions of its parts,
not the actions of the parts considered separately.
Therefore,
when a system is taken apart,
or its parts are considered independently of each other,
the system loses its essential properties.
Furthermore, when performance of each part taken separately is improved,
the performance of the system as a whole may not be, and usually isn’t.
--Russell Ackoff

© Copyright 2015 Stevens Institute of

19
Technology, All rights reserved
1/21/2020 19
 Why do anything at all?
“Systems Thinking just Complicates Things.”

Innovation Associates

© Copyright 2015 Stevens Institute of

20
Technology, All rights reserved
1/21/2020 20
 Systems Engineering Life Cycle Model –
ISO/IEC 15288
Purpose
– To establish a common framework for describing the life cycle of systems created by humans.
Scope
– Provides a common, comprehensive & integrated framework for describing and managing the
full life cycle of systems for:
• Small, medium and large organizations
• Internal self-imposed use, as well as providing a basis for contractual arrangements (i.e.,
any agreement)
System Concept
– Defines two systems:
1. System-of-interest that provides desired capabilities and services.
2. Enabling systems that provide the system-of-interest with required services in each system
life cycle stage including concept, development, production, utilization, support and
retirement.
Life Cycle Model
– System Life Cycle Model consisting of six stages:
1. Concept, 2. Development, 3. Production, 4. Utilization, 5. Support, 6. Retirement.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 21
 Systems Engineering Life Cycle Model –
ISO/IEC 15288
Purpose
– To establish a common framework for describing the life cycle of systems created by humans.
Scope
– Provides a common, comprehensive & integrated framework for describing and managing the
full life cycle of systems for:
• Small, medium and large organizations
• Internal self-imposed use, as well as providing a basis for contractual arrangements (i.e.,
any agreement)
System Concept
– Defines two systems:
1. System-of-interest that provides desired capabilities and services.
2. Enabling systems that provide the system-of-interest with required services in each system
life cycle stage including concept, development, production, utilization, support and
retirement.
Life Cycle Model
– System Life Cycle Model consisting of six stages:
1. Concept, 2. Development, 3. Production, 4. Utilization, 5. Support, 6. Retirement.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 22
 Systems Engineering Life Cycle

INCOSE Systems Engineering Handbook version 3 2006

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 23
 Systems Engineering Life Cycle Model –
ISO/IEC 15288
Project span
Application Context
of control

em Project
ve sy st Project
h a s Organizations
f oc u
System-of-
interest

Enabling
system

Create and
have monitor projects
sp a
inter n of
est

Project
Project
Perform required Projects
work on or with
System-of- system-of-interest
interest within life cycle
stages
Life cycle stages
(s1, s2, ... ,sn)
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 24
 Systems Engineering Life Cycle Model –
ISO/IEC 15288
Project span
of control
Enabling systems include:
m Project
e s yste • Development Systems
Project
System-of- h a v oc u s Organizations
f
interest
• Verification Systems
Enabling
system
• Validation Systems
Create and
ha v • Manufacturing Systems
monitor projects
e sp
a
inter n of
est
They are systems that need to be
developed in addition
Project to the system of
Project
Perform required
interest. Projects
work on or with
System-of- system-of-interest
interest They are typically not delivered to the
within life cycle
stages customer, but are investments of the
Life cycle stages supplier.
(s1, s2, ... ,sn)
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 25
 Systems Engineering Life Cycle Model –
ISO/IEC 15288
Role of Processes
Agreement Used to arrive at and
Processes satisfy an agreement
Deliverable that
satisfies agreement Used to establish requirements

Used to assess Enterprise

quality and progress Processes
Used to create, support
and monitor projects
System-of-
interest Project
Used to manage
Life cycle stages life cycle stages Processes
(s1, s2, ... ,sn) Used to manage
technical processes
Outcomes used to
Used to create products and assess progress
Technical
services of life cycle stage
Processes
that meet requirements
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 26
 Systems Engineering Life Cycle Model –
ISO/IEC 15288 Process Model ISO/IEC 15288

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 27
 Systems Engineering Life Cycle Model –
ISO/IEC 15288 Process Model ISO/IEC 15288

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 28
 Agile Software Development
A New Methodology?

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 29
 The Values of Agile Development –
The Agile Manifesto
We are uncovering better ways of developing software
by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right,

we value the items on the left more.
The Agile Alliance – February 2001

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 30
 The Twelve Supporting Principles of
Agile Development
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customers’ competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly. The Agile Alliance – February 2001
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 31
 “V” Model View
Stakeholder
Needs
User System
Requirements Validation

Systems
System System
Requirements Verification Engineering
Domain
System
Architecture
Integration
Definition

High-level Unit Test

Design

Detailed Design Component

Engineering
Build Domain
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 32
 Relationships among
SYS 625, SYS 650 and SYS 605

SYS 625 SYS 650 SYS 605

1. Define a need or 1. Break a complex 1. Integrate the

market opportunity system into a set of components
simpler elements

2. Develop an 2. Define how those 2. Verify that the

operational concept elements work system meets its
to address it together to meet the requirements at
need every level

3. Translate 3. Develop a complete 3. Validate that the

stakeholder set of specifications system satisfies the
requirements into for each element operational need
system specifications
 Relationships of SYS/SDOE 625/650/605

SYS/SDOE 625
Systems Engineering
Fundamentals

SYS/SDOE 650
System Architecture
& Design

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 34
 Systems Integration
 Definition
– From Webster's Revised Unabridged
Dictionary (1913) (web1913)
• Integration \In`te*gra”tion\, n.[L.
integratio a renewing, restoring: cf. F.
int[`e]gration.] 1. The act or process
of making whole or entire.

 Definition
– Systems Integration Is an “Entire View” of Missions and Business Processes
Achieved By Combining Capabilities of Platforms, Systems, Operators, & Support to
Maximize Performance
– The Role of a System Integrator Evolves from Providing Products, Systems, & System
Elements… to Providing Functionality or Solutions

As complexity increases, emphasis shifts from system elements to systems integration.

© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 35
 Other
Definitions of Systems Integration
• NASA NPR 7123.1 – NASA Systems Engineering Processes and
Requirements
“The process used to transform the design solution definition into the desired
end product of the WBS model through assembly and integration of lower-
level validated end products in a form consistent with the product-line life-
cycle phase exit criteria and that satisfies the design solution definition
requirements.”
• US Defense Acquisition Guide (DAG)
“… process of incorporating lower level system elements into higher-level
system elements in the design solution or the physical architecture.”
• Robert L. McCaig, Stevens Institute SSE Industry Fellow
“The ‘Meshing’ of Requirements, System Architecture, Schedule, Risk,
Supportability, and Cost to Deliver System Performance and Life Cycle
Supportability On Time and Within Budget.”

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 36
 Integration
• System integration is that part of the system engineering
process that unifies the product components and the process
components into a whole. It ensures that the hardware,
software, and human system components will interact to
achieve the system purpose and/or satisfy the customer’s
need.
• Includes deployment – final integration into the operational
environment for use.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 37
 Verification

• Verification – Did you test things right?

– To establish the truth of correspondence between a
product/system and its specification
– Based on Requirements Database, Traceability
– The comparison of a module's code against its technical
design specifications document is one example
– Are We Building the Product/System/Service Right?

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 38
 Validation
• Validation – Did you test the right things?
– The act of ensuring compliance against an original
requirement. An example is the comparison of the actual
system response of an on-line transaction to what was
originally expected, requested, and finally approved
– Based on Operational or Field Testing
– Are We Building the Right Product/System/Service?

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 39
 Integration, Verification and Validation

© Copyright 2015 Stevens Institute of 40

1/21/2020 Technology, All rights reserved
 “V” Model View
Stakeholder
Needs
User System
Requirements Validation

Systems
System System
Requirements Verification Engineering
Domain
System
Architecture
Integration
Definition

High-level Unit Test

Design

Detailed Design Component

Engineering
Build Domain
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 41
1/21/2020
 “V” Model View
Stakeholder
Needs
User System
Requirements Validation

Systems
System System
Requirements
Engineering
Verification
Domain
System
Architecture
Integration
Definition

High-level Unit Test

Design

Detailed Design Component

Engineering
Build Domain
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 42
1/21/2020
 “V” Model View
Stakeholder
Needs
User Requirements System
and Concept of Validation
Operations
Systems
System System
Requirements Verification Engineering
Domain
Architecture System
Definition Integration

High-level Unit Test

Design

Detailed Design Component

Engineering
Build Domain
© Copyright 2015 Stevens Institute of 43
1/21/2020 Technology, All rights reserved
 Real-life Process of System Development:
Iterative Design
• While we use the waterfall • The real practice of system
and V models to depict the design is iterative and irregular,
general flow of system involving
development activities – system and subsystem models
– from requirements – evolving architecture and designs
– to architecture – repeated comparison, refinement
– to design and verification of the models, the
design, and the implementation
– to integration
– and continuous validation of the
– to verification
evolving system against user needs
– to validation in the operational environment

1/21/2020 © Copyright 2015 Stevens Institute of 44

Technology, All rights reserved
 “V” Model View
Stakeholder
Needs
User System
Requirements Validation
System Model Validation
Validation Planning Systems
System System
Verification Engineering
Requirements
Verification Domain
System Model
Planning System
Verification Architecture
Integration
Definition
Integration
Planning
High-level Design Unit Test

Detailed Design Component

Front-end Engineering
IV&V Build Domain
Activities
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 45
 SYS 605 Project
• The class will be formed into teams
• Each team will be made up of 3-4 individuals
• Team project assignments will be summarized in a paper and
presentation to be given approximately half-way through the
semester. Individual project assignments will be due at the
end of the semester.
• We will use the Tsunami Warning System as the basis for in-
class and some homework exercises; each team will identify
an appropriate system as the basis for their project
• Please identify your teams at the end of the break

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 46
 Scheduling
• I will be unavailable due to another class commitment on the
following date:

– Tuesday, February 18 (replacement for Monday, February 17)

• We will try to complete the course in the remaining classes.

However, this class may need to be rescheduled on a
mutually agreed date during the semester.

1/21/2020 © Copyright 2015 Stevens Institute of 47

Technology, All rights reserved
 SDOE 605 – In-class exercises
Tsunami Warning System (TWS)

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 48
 Deadliest Tsunamis in Recent History
Fatalities1 Year Magnitude Principal areas
225,000+ 2004 9.0 Indian Ocean
100,000 1410 b.c. Crete-Santorini, Ancient
Greece
60,000 1755 8.5 Portugal, Morocco
40,000 1782 7.0 South China Sea
36,500 1883 Krakatau, Indonesia
30,000 1707 8.4 Tokaido-Nankaido, Japan

26,360 1896 7.6 Sanriku, Japan

25,674 1868 8.5 Northern Chile
15,030 1792 6.4 Kyushu Island, Japan
13,486 1771 7.4 Ryukyu Trench, Japan
Source: National Geophysical Data Center, National Oceanic and Atmospheric Administration.

18,550 2011 9.0 Pacific Coast, Japan

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 49
 2011 Tohoku Earthquake and
Tsunami
 A magnitude 9.0 undersea earthquake off the coast of Japan that occurred at 14:46 JST
(Japan Standard Time) on Friday, 11 March 2011.

 The world's fourth largest earthquake since 1900 and the largest in Japan since modern
instrumental recordings began 130 years ago.

 The earthquake triggered powerful tsunami waves that reached heights of up to 40.5
meters in Miyako in Tōhoku's Iwate Prefecture, and which, in the Sendai area, travelled up to
10 km. inland. The earthquake moved Honshu 2.4 m east and shifted the Earth on its axis by
estimates of between 10 cm and 25 cm.

The tsunami obliterated tens of thousands of buildings, devouring almost anything in his
path, and caused widespread devastation, with an official count of around 20,000 people
confirmed to be killed/missing.

In addition the tsunami precipitated multiple hydrogen explosions and nuclear meltdown at
the Fukushima I Nuclear Power Plant
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 50
 Deep or Open Ocean Tsunami
• Everyday wind waves have a wavelength (from crest to crest) of about 100 meters (330 ft) and a
height of roughly 2 meters (6.6 ft)
•Tsunamis come in two main varieties, those generated out to sea and locally occurring waves. A
tsunami in the deep ocean has a wavelength of about 200 kilometers (120 mi). Such a wave
travels at well over 800 kilometers per hour (500 mph), but due to the enormous wavelength the
wave oscillation at any given point takes 20 or 30 minutes to complete a cycle and has an
amplitude of only about 1 meter (3.3 ft). This makes tsunamis difficult to detect over deep water.
Ships rarely notice their passage.
• As the tsunami approaches the coast and the waters become shallow, wave shoaling
compresses the wave and its velocity slows below 80 kilometers per hour (50 mph). Its
wavelength diminishes to less than 20 kilometers (12 mi) and its amplitude grows enormously,
producing a distinctly visible wave. Wave heights may exceed 100 ft.
• A large tsunami may feature multiple waves arriving over a period of hours, with significant time
between the wave crests. The first wave to reach the shore may not have the highest run up.
• About 80% of tsunamis occur in the Pacific Ocean.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 51
 Tsunami Warning System
• The Tsunami Warning System (TWS) in the Pacific, comprised of 26 participating international
Member States, has the functions of monitoring seismological and tidal stations throughout
the Pacific Basin to evaluate potentially tsunamigenic earthquakes and disseminating tsunami
warning information.

• As part of an international cooperative effort to save lives and protect property, the National
Oceanic and Atmospheric Administration's (NOAA) National Weather Service operates two
tsunami warning centers. The Alaska Tsunami Warning Center in Palmer, Alaska, serves as the
regional Tsunami Warning Center for Alaska, British Columbia, Washington, Oregon, and
California. The Pacific Tsunami Warning Center (PTWS) in Ewa Beach, Hawaii, serves as the
regional Tsunami Warning Center for Hawaii and as a national/international warning center for
tsunamis that pose a Pacific-wide threat.

• The objective of the PTWS is to detect, locate, and determine the magnitude of potentially
tsunamigenic earthquakes occurring in the Pacific Basin or its immediate margins. If the
location and magnitude of an earthquake meet the known criteria for generation of a tsunami,
a tsunami warning is issued to warn of an imminent tsunami hazard.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 52
 Tsunami Warning System
• Type I Errors – False Alarms
• False positive: Tsunami warning when no tsunami occurs.
• Economic losses from curtailed business.
• Costs of protection.
• Costs of needless evacuation.
• Potential negative results of needless panic
In 2005, the Pacific Ocean early warning system's high false alarm rate was estimated to be
75 percent. An unnecessary evacuation in Hawaii in 1994 cost an estimated $30 million in
business disruptions and other costs.
• Type II Errors - Misses
•False negative: No tsunami warning when a tsunami occurs.
• Injury and loss of life.
• Damage and destruction of property.
• The 2004 tsunami in the Indian Ocean added up to an overall capital loss of US$15bn in
India, Indonesia, Sri Lanka and Thailand.
• The death toll in Indonesia, Sri Lanka, India and Thailand from the 2004 tsunami was
estimated at more than 225,000 with more than 1.69 million displaced.

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 53
 Tsunami Warning System Architecture

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 54
 Tsunami Warning System Architecture
Project
Boundaries

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 55
 Dart II Deployment

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 56
 The Dart II System

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 57
 Dart II Surface Buoy Architecture

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 58
 Dart II Tsunameter Architecture

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 59
 © Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 60
1/21/2020 61
 Key DART II Performance Requirements

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 62
 Class Exercise
Review the description of the Tsunami Warning System. Assume that you are a non-
technical executive of the NOAA. You are commissioning a development team to
design and build a Tsunami Warning System.

• When you speak to the leader of the project team designing the system, what user
needs do you identify to her?

• What acceptance tests do you require the system to pass?

• What organizational structure do you establish to oversee the development?

• How do you plan to monitor progress on the development?

As the NOAA executive responsible for procuring the system and managing the
associated budget, keep in mind that your career and potentially your job depend
on deploying an effective system on schedule and within budget.
© Copyright 2015 Stevens Institute of
1/21/2020 Technology, All rights reserved 63
 TWS Exercise 1
Stakeholder Needs
• Review the system description of the Tsunami Warning
System (TWS)

• Identify all stakeholders for the system

• List three to five stakeholder needs of importance to each of

the stakeholder groups identified above

© Copyright 2015 Stevens Institute of

1/21/2020 Technology, All rights reserved 64
 Team Project
Form a team of 3-4 students and choose a real system or problem for which
you have reasonable domain knowledge. An appropriate system for this
project would have 10 or more components integrated into 4-7 subsystems.

1. Describe your system and identify the Active and Passive Stakeholders
2. List the major Stakeholder Needs to be Validated

Due February 3 (These are the first two of nine parts for the team project)

1/21/2020 © Copyright 2015 Stevens Institute of 65

Technology, All rights reserved
 Scheduling
• I will be unavailable due to another class commitment on the
following date:

– Tuesday, February 18 (replacement for Monday, February 17)

• We will try to complete the course in the remaining classes.

However, this class may need to be rescheduled on a
mutually agreed date during the semester.

1/21/2020 © Copyright 2015 Stevens Institute of 66

Technology, All rights reserved