Before The Project

1
Before The Project

• Chapter 7
• Pragmatic Programmer

2
The Requirements Pit

• Tip 51 Dont Gather Requirements Dig for Them
• Tip 52 Work with a User to Think Like a User
• Tip 53 Abstractions Live Longer than Details
• Tip 54 Use a Project Glossary

3
Overspecifying

• Dont be too specific. Good requirement documents
  remain abstract.
• Requirements
• Are NOT architecture
• Are NOT design, NOR user interface
• Are need

4
The Specification Trap

• Tip 57 Some Things Are Better Done than
  Described
• Seamless approachspecification and
  implementation are different aspects of the same
  process each should flow directly into the next,
  with no artificial boundaries.

5
Requirements Engineering

• Bernd Bruegge

6

• System Identification
• Development of a system is not just done by
  taking a snapshot of a scene (domain)
• Definition of the system boundary
• What is inside, what is outside?
• How can we identify the purpose of a system?
• Requirements Process
• Requirements Engineering Definition of the
  system in terms understood by the customer
• Requirements Analysis Technical specification of
  the system in terms understood by the developer.

7

• Requirements Engineering
• Very challenging activity
• Requires collaboration of people with different
  backgrounds
• User with application domain knowledge
• Developer with implementation domain knowledge
• Bridging the gap between user and developer
• Scenarios Example of the use of the system in
  terms of a series of interactions between the
  user and the system
• Use cases Abstraction that describes a class of
  scenarios

8

• Requirements Validation
• Critical step in the development process,
• Usually after requirements engineering or
  requirements analysis. Also at delivery.
• Requirements validation criteria
• Correctness
• The requirements represent the clients view.
• Completeness
• All possible scenarios through the system are
  described, including exceptional behavior by the
  user or the system
• Consistency
• There are functional or nonfunctional
  requirements that contradict each other
• Realism
• Requirements can be implemented and delivered

9

• Additional Requirements Validation Criteria
• Traceability
• Each system function can be traced to a
  corresponding set of functional requirements

• With AOSD we can improve traceability of
  requirements.
• Goal can we map requirements to aspects?

10

• Types of Requirements Engineering
• Greenfield Engineering
• Development starts from scratch, no prior system
  exists, the requirements are extracted from the
  end users and the client
• Triggered by user needs
• Re-engineering
• Re-design and/or re-implementation of an existing
  system using newer technology
• Triggered by technology enabler
• Interface Engineering
• Provide the services of an existing system in a
  new environment
• Triggered by technology enabler or new market
  needs

Example Eclipse as new technology enabler
11

• Actors
• Actors constitute everything that is external to
  the system and that communicates and interacts
  with the system.
• human users, external hardware and other systems
• Actors communicate by sending and receiving
  stimuli to and from the system. Each actor has a
  name.
• Graphical Notation A stick figure with the name
  of the actor.

12

• Scenarios
• A narrative description of what people do and
  experience as they try to make use of computer
  systems and applications M. Carrol,
  Scenario-based Design, Wiley, 1995
• A concrete, focused, informal description of a
  single feature of the system used by a single
  actor.
• Scenarios can have many different uses during the
  software lifecycle

13

• Types of Scenarios
• As-is scenario
• Used in describing a current situation. Usually
  used during re-engineering. The user describes
  the system.
• Visionary scenario
• Used to describe a future system. Usually
  described in greenfield engineering or
  reengineering.
• Can often not be done by the user or developer
  alone.
• Evaluation scenario
• User tasks against which the system is to be
  evaluated
• Training scenario
• Step by step instructions designed to guide a
  novice user through a system

14

• Heuristics How do I find Scenarios?
• Ask yourself or the client the following
  questions
• What are the primary tasks that the system needs
  to perform?
• What data will the actor create, store, change,
  remove or add in the system?
• What external changes does the system need to
  know about?
• What changes or events will the actor of the
  system need to be informed about?
• To answer these questions, develop scenarios!

15

• Example Accident Management System
• What needs to be done to report a Cat in a Tree
  incident?
• What do you need to do if a person reports
  Warehouse on Fire?
• Who is involved in reporting an incident?
• What does the system do if no police cars are
  available? If the police car has an accident on
  the way to the cat in a tree incident?
• What do you need to do if the Cat in the Tree
  turns into a Grandma has fallen from the
  Ladder?
• Can the system cope with a simultaneous incident
  report Warehouse on Fire?

16

• Scenario Example Warehouse on Fire
• Bob, driving down main street in his patrol car
  notices smoke coming out of a warehouse. His
  partner, Alice, activates the Report Emergency
  function from her FRIEND laptop.
• Alice enters the address of the building, a brief
  description of its location (i.e., north west
  corner), and an emergency level. In addition to a
  fire unit, he requests several paramedic units on
  the scene given that area appear to be relatively
  busy. He confirms his input and waits for an
  acknowledgment.
• John, the Dispatcher, is alerted to the emergency
  by a beep of his workstation. He reviews the
  information submitted by Alice and acknowledges
  the report. He creates allocates a fire unit and
  two paramedic units to the Incident site and
  sends their estimated arrival time (ETA) to
  Alice.
• Alice received the acknowledgment and the ETA.

17

• Observations about Warehouse on Fire Scenario
• Concrete scenario
• Describes a single instance of reporting a fire
  incident.
• Does not describe all possible situations in
  which a fire can be reported.
• Participating actors
• Bob, Alice and John
• Next goal, after the scenarios are formulated
• Find the use case that specifies all possible
  instances of how to report a fire
• What roles are the played by the participating
  actors?

18

• Use Case Example ReportEmergency
• The FieldOfficer activates the Report Emergency
  function of her terminal. FRIEND responds by
  presenting a form to the officer.
• The FieldOfficer fills the form, by selecting the
  emergency level, type, location, and brief
  description of the situation. The FieldOfficer
  also describes possible responses to the
  emergency situation. Once the form is completed,
  the FieldOfficer submits the form, at which
  point, the Dispatcher is notified.
• The Dispatcher reviews the submitted information
  and creates an Incident in the database by
  invoking the OpenIncident use case. The
  Dispatcher selects a response and acknowledges
  the emergency report.
• The FieldOfficer receives the acknowledgment and
  the selected response.

19

• Use Case Example ReportEmergency ctd
• Use case name ReportEmergency
• Participating Actors
• Field Officer (Bob and Alice in the Scenario)
• Dispatcher (John in the Scenario)
• Exceptions
• The FieldOfficer is notified immediately if the
  connection between her terminal and the central
  is lost.
• The Dispatcher is notified immediately if the
  connection between any logged in FieldOfficer and
  the central is lost.
• Nonfunctional Requirements
• The FieldOfficers report is acknowledged within
  30 seconds. The selected response arrives no
  later than 30 seconds after it is sent by the
  Dispatcher.

20

• Use Cases
• A use case is a flow of events in the system,
  including interaction with actors
• It is initiated by an actor
• Each use case has a name
• Each use case has a termination condition
• Graphical Notation An oval with the name of the
  use case
• Use Case Model The set of all use cases
  specifying the complete functionality of the
  system

21

• Use Case Associations
• Relationship between use cases
• Important types
• Consists of
• Extends
• Uses

22

• Consists of Association for Use Cases
• Not explicitly named in UML
• Problem A function in the original problem
  statement is too complex to be solvable
• Solution Describe the function as the
  aggregation of a set of simpler functions. The
  associated use case is refined into smaller use
  cases
• ManageIncident
• CreateIncident
• HandleIncident
• CloseIncident

23

• Extends Association for Use Cases
• Problem The functionality in the original
  problem statement needs to be extended.
• Solution An extends association from a use case
  A to a use case B indicates that use case B is an
  extension of use case A.
• That is, the use case ReportEmergency is
  complete by itself , but can be extended by the
  use case Help for a specific scenario in which
  the user requires help

24

• Uses Association for Use Cases
• Problem Need to reuse existing assets and
  resources
• Solution The uses association from a use case A
  to a use case B indicates that an instance of the
  use case A can perform all behavior described for
  the use case B
• Example The use case ViewMap describes
  behavior that can be used by use case
  OpenIncident

25

• How to Specify a Use Case
• Actors (Description of Actors involved in use
  case)
• Entry condition (This use case starts when...)
• Flow of Events (Free form natural language text)
• Exit condition (This use cases terminates
  when...)
• Special Requirements

26

• Use Case Example Allocate a Resource
• Entry Condition
• The use case starts after the Resource Allocator
  has selected an available Resource.
• The Resource is currently not allocated
• Flow of Events
• The Resource Allocator selects an Emergency
  Incident.
• The Resource is committed to the Emergency
  Incident.
• Exit Condition
• The use case terminates when the resource is
  committed.
• The selected Resource is now unavailable to any
  other Emergency Incidents or Resource Requests.
• Special Requirements
• The Field Supervisor is responsible for managing
  the Resources

27

• Heuristics How do I find use cases?
• Select a narrow vertical slice of the system
  (i.e. one scenario) and discuss it in detail with
  the user to understand the users preferred style
  of interaction
• Select a horizontal slice (i.e. many scenarios)
  to define the scope of the system. Discuss the
  scope with the user
• Use mock-ups as visual support
• Find out what the user does
• Task observation (Good)
• Questionnaires (Bad)

28

• Is there Life after Scenarios and Use Cases?
• Functional Decomposition says yes
• Every use case is refined into a set of lower
  level use cases
• The use cases consists of lower level use cases
• The use case is extended by another use case
• This refinement is repeatedly done until the
  lowest level use cases are machine instructions
  that can be executed by the target machine

29

• Problems with Functional Decomposition
• High cost of recompilation
• Adding a new device usually requires compilation
  of every file that uses the device
• Leads to unmaintenable code
• The better way is to start with functional
  decomposition and then to find objects
• Object identification
• Sequence Diagrams

30
Modeling a Briefcase BriefCase Capacity
Integer Weight Integer Open() Close()
Carry()
31
A new Use Case for a Briefcase BriefCase
Capacity Integer Weight Integer Open()
Close() Carry() SitOnIt()
32

• Questions
• Why did we model the thing as Briefcase?
• Why did we not model it as a chair?
• What do we do if the SitOnIt() operation is the
  most frequently used operation?
• The briefcase is only used for sitting on it
  during video conferences. It is never opened nor
  closed. Is it a Chairor a Briefcase?
• How can we live with our mistake?

33

• Summary
• Requirements Engineering
• Greenfield Engineering, Reengineering, Interface
  Engineering
• Scenarios
• Great way to establish communication with client
• As-Is Scenarios, Visionary scenarios, Evaluation
  scenarios, Training scenarios
• Use cases Abstraction of scenarios
• Pure functional decomposition is bad
• Leads to unmaintainable code
• Starting with object identification is bad
• May lead to wrong objects, wrong attributes,
  wrong methods
• The key to successful analysis
• Start with use cases and then find the
  participating objects
• If somebody asks What is this?, do not answer
  right away. Return the question or observe What
  is it used for?

34
From Bernd Bruegge

• CMU/Munich
• Notes on Software Lifecycle

35

• Engineering Complex Systems
• Based on modeling A model of a system describes
  a specific aspect of the system under
  consideration.
• Main principles used in developing models
• Abstraction
• Decomposition
• Hierarchy
• Encapsulation
• Terminology
• Notation Language to express each model
• Process Guidelines for the orderly construction
  of the models (SEI Capability maturity model -
  Humphrey)
• Product A description of a model
• Tool Artifact that supports the building of
  models and enforces rules about the models
  (completeness, consistency, unambiguity)

36

• Hierarchy
• Bring order into chunks (subsystems) obtained by
  abstraction and decomposition
• Class (Object) identification
• Attributes
• Operations (Methods)
• Define relations between classes
• Called associations
• 2 important hierarchies
• "Part of" hierarchy
• "Is-kind-of" hierarchy

We will also deal with aspect hierarchies
37

• Other ways to deal with complexity
• Start with an existing system
• Use templates
• Use techniques and tools
• Build the system incrementally and iteratively
• Use models
• Use a Software development methodology
• Software lifecycle

38

• Categories of software development methodologies
• Object-oriented methodology
• Systems are modeled as a collection of
  cooperating objects
• Structured Methodology
• Based on functional (algorithmic)
  decomposition
• Data-driven Methodology
• Structure of system is derived by mapping
  system inputs to outputs.
• E,g, Jackson System Development
• Aspect-oriented Methodology
• Support for crosscutting abstractions
• E.g. Demeter, AspectJ, HyperJ

39

• Models to Describe Systems
• Greek Philosophers used two models to the
  universe
• Demokrit Everything is composed of atoms
• Heraklit Everything flows (Panta Rhei
  everything changes/moves)
• A good software design methodology provides at
  least three models (Why not just two?)
• Structural model
• What is the structure of the system?
• What are the objects and how are they related?
• Functional model
• What are the functions of the system?
• How is data flowing through the system?
• Control model
• How does the system react to external events?
• How is the event flow in the system ?

40

• Software Development Methodologies
• Structured Analysis (Yourdon and DeMarco, 1978)
• Structured Design (Yourdon and Constantine, 1979)
  
• OMT (Rumbaugh et al, 1991)
• Object-Oriented Modeling Technique
• Object model What are the objects in the system?
  
• Functional model What are the functions of the
  system?
• Dynamic model How does the system react to
  external events?
• Other object-oriented methodologies
• HOOD (European Space Agency, 1989)
• CRC (Class, Responsibility Collaboration,
  Wirfs-Brock, 1991)
• OOA (Yourdon Coad, 1991)
• Booch method (Booch, 1991)
• OOSE (Jacobson, 1992)

41

• UML
• UML (Grady Booch, Ivar Jacobsen and James
  Rumbaugh)
• Structural Model
• Class Diagrams Describes the structure of the
  system in terms of classes and objects
• Functional Model
• Use Case Diagram Describes the external behavior
  of the system from a functional point of view
• Control Model
• Sequence Diagrams Describes the dynamic
  interaction between objects identified in the
  structural model
• Activity Diagrams Describes the dynamic behavior
  of a single object

42

• CASE (Computer Aided Software Engineering)
• Automate and aid a particular activity
• Use information from one activity to another one.
  
• OMTool (Rumbaugh, 1991) A front end CASE tool
  only for class diagrams
• X-based, C templates (skeleton code), Suns, HPs
  and PCs
• Lifecycle CASE tools have an underlying model of
  system development that spans many activities
  (dated information 1997)
• OTE Object Team Enterprise, Cayenne Software,
  for OMT
• StP/OMT Software through Pictures, Interactive
  Development Environments, CASE for many
  methodologies
• Objectory Object Factory, Objectory, CASE tool
  for OOSE
• ROSE Rational, Case tool for the UML methodology

43

• Methodology Definition
• Methodology A collection of techniques for
  building models - applied across the development
  of a software system (software life cycle)

44

• Software Life Cycle
• Software development goes through a progression
  of states (software development activities)
• Conception
• Childhood
• Adulthood
• Retirement

45
Examples of Software Development Activities
(Pfleeger) Requirements Analysis What is the
problem? System DesignWhat is the
solution? Program Design What are the
mechanisms that best implement the
solution. Program Implementation How is the
solution constructed? Testing Is the problem
solved? Delivery Can the customer use the
solution? Maintenance Are enhancements
needed?
Problem domain
Implementation domain
46

• Software Lifecycle
• Definition
• Set of activities that constitute a software
  project
• Typical Lifecycle questions
• Which activities should I select for the software
  project?
• What are the dependencies between activities?
• How should I schedule the activities?

47

• Inherent Problems with Software Development
• Requirements are constantly changing
• The client does not know them in advance
• Frequent changes are difficult to manage
• Identifying checkpoints for planning and cost
  estimation is difficult
• Phased Development
• New system must be backward compatible with
  existing system
• There must be a distinction between the system
  under development and the already released
  systems

48

• Life-Cycle Model Variations on a Theme
• Many models have been proposed to deal with the
  problems of defining activities and associating
  them with each other
• The waterfall model
• First described by Royce in 1970
• There seem to be at least as many versions as
  there are authorities - perhaps more

49
The Waterfall Model of the Software Life
Cycle Requirements Analysis and Definition
System and Software Design
System Testing
Implementation and Unit Testing
50

• Problems with Waterfall Model
• Managers love waterfall models
• Nice milestones
• No need to look back (linear system)
• Always one activity at a time
• Easy to check progress during development 90
  coded, 20 tested
• However, software development is iterative
• While a design is being developed, problems with
  requirements are identified
• While a program is being coded, design and
  requirement problems are found
• While a program is tested, coding errors, design
  errors and requirement errors are found

51
Alternative

• Allow iteration

52
Alternative Lifecycle Model Allow
Iteration Revise, Review -gt List of revisions for
each phase Requirements (inconsistent,
incomplete, ambiguous) Phases Requirements
Elicitation Analysis Design Implementation Testing
Delivered System
53

• Spiral Model (Boehm)
• Identify risks
• Assign priorities to risks
• Develop a series of prototypes for the identified
  risks starting with the highest risk.
• Use a waterfall model for each development (round
  or cycle)
• If a risk has successfully been resolved,
  evaluate the results of the round and plan the
  next round
• If a certain risk cannot be resolved, terminate
  the project immediately

54

• Activities (Rounds) in Boehms Spiral Model
• Concept of Operations
• Software Requirements
• Software Product Design
• Detailed Design
• Code
• Unit Test
• Integration and Test
• Acceptance Test
• Implementation
• For each round go through these steps
• Define objectives, alternatives, constraints
• Evaluate alternative, identify and resolve risks
• Develop, verify next level product
• Plan next activity (round, phase)

55

• Different Types of Prototypes
• Illustrative Prototype
• Develop the user interface with a set of
  storyboards
• Implement them on a napkin or with a user
  interface builder (Visual C, ....)
• Good for first dialog with client
• Functional Prototype
• Implement and deliver an operational system with
  minimum functionality
• Then add more functionality
• Order identified by risk
• Exploratory Prototype ("Hacking")
• Implement part of the system to learn more about
  the requirements.
• Good for paradigm breaks

56

• Types of Prototyping cont
• Revolutionary Prototyping
• Also called specification prototyping
• Get user experience with a throwaway version to
  get the requirements right, then build the whole
  system
• Disadvantage Users may have to accept that
  features in the prototype are expensive to
  implement
• User may be disappointed when some of the
  functionality and user interface evaporates
  because it can not be made available in the
  implementation environment
• Evolutionary Prototyping
• The prototype is used as the basis for the
  implementation of the final system
• Advantage Short time to market
• Disadvantage Can be used only if target system
  can be constructed in prototyping language

57

• Prototyping vs Rapid Development
• Revolutionary prototyping is sometimes called
  rapid prototyping
• Don't confuse prototyping with rapid development
• Prototyping is a technical issue It is a
  particular model in the life cycle process
• Rapid development is a management issue. It is a
  particular way to control a project
• Prototyping can go on forever if it is not
  restricted
• Time-boxed prototyping

58

• Class vs Project
• In class, we will introduce software development
  activities in a certain order constrained by the
  lectures schedule
• In the project, we must be able to deal with
  iteration, out of order activities, revisions and
  refinements (based on new information obtained
  during the project)
• Your goal
• Learn about the software development activities
• Gain a better understanding of the difficulties
  of the software development
• Combine the current state of the art knowledge
  with tools and techniques to produce a quality
  software system delivered in time and within
  budget.

59

• Standards for Software Development
• IEEE (Institute of Electrical and Electronics
  Engineers)
• IEEE Standards
• IEEE 1074-1995 Software Lifecycle
• IEEE 1058.1-1987 Project Management
• IEEE 1042-1987 Configuration Management
• OMG (Object Management Group) Committed to
  provide software connectivity across
  heterogeneous platforms and languages
• CORBA (Common Object Request Broker Architecture)

60

• IEEE Software Engineering Standards
• Other important standards
• IEEE 610 Glossary of Software Engineering
  Terminology
• IEEE 830 Guide for Software Requirements
  Specification
• IEEE 1002 Standard Taxonomy for Software
  Engineering Standards
• Standards are rapidly changing and are revised
  every couple of years
• Revisited every 5 years
• Standards older than 5 years Reasonable to
  assume that the present state is not wholly
  reflected

61

• Other Standards
• ISO (International Standard Organization)
• OSI Hierarchy (Open System Interconnection)
• EDI standard (for electronic data interchange)
• ISO 9001 (Standard for Software Development)
• CCITT (International Consultative Committee on
  Telephony and Telegraphy)
• A group composed of the world's telecommunication
  companies
• X.25 Standard for packet-switched network layer
  services
• X.400 Message Handling
• X. 500 Directory Standard
• ANSI (American National Standards Institute)
• Official Representative of the US to ISO and
  CCITT
• ASCII

62

• Processes, Activities and Tasks IEEE 1074
• Processes consists of Activities which in turn
  consist of tasks
• Example
• The Design Process consists of the following
  Activities
• Perform Architectural Design
• Design Database (If Applicable)
• Design Interfaces
• Select or Develop Algorithm (If Applicable)
• Perform Detailed Design ( Object Design)
• The Design Database Activity has the following
  Tasks
• Review Relational Databases
• Review Object-Oriented Databases
• Make a Purchase recommendation
• ....

63

• Software Development Activities in COM 3205
• Focus on Development
• Planning
• Requirements Analysis
• Design
• System Design
• Object Design
• Implementation
• Coding
• Unit Testing
• Integration Testing
• System Testing
• System Delivery

64

• Software Process Model used in COM 3205
• Activities Planning, Requirements Analysis,
  System Design, Object Design, Unit Testing,
  Integration Testing, System Testing, Delivery
• Iterative Lifecycle model
• Called Micro/Macro Model by Booch
• A lot of iterations during a particular software
  development activity (micro iteration)
• Zero or more iterations across activities (macro
  iteration)
• Build at least two prototypes
• Illustrative prototype
• Functional Prototype
• Time-boxed prototyping
• Every activity has a start and termination date

65

• Roles in COM 3205
• Software development roles (every student)
• Analyst, Designer, Programmer, Tester
• Management roles (every student)
• Project leader
• API Engineer (Architecture Team Liaison)
• HCI Engineer (HCI Team Liaison)
• Configuration manager
• CASE Modeler
• Web Master
• Planner

66

• Requirements Analysis
• Analyze, understand and record the problem that
  the client is trying to solve (given in the
  problem statement)
• Define the system
• Specify the boundaries of the systems
• Specify the goals and constraints
• Specify the use cases (use case model)
• Specify the object, functional and dynamic model
• Client and developer must agree on the
  specification (requirements analysis document)
  which is used as the basis for the design

67

• Design
• Create a solution that meets the specifications
  outlined in the requirements analysis phase
• Design is a complex process and highly iterative
• Parts of the design
• User interface design Design of the system as
  it will be seen by the users (end user,
  maintainer, client)
• System design Define the structure of the
  system, that is, its modular components and the
  relationship among the components
• Object design Make decisions about
  implementation of each of the components
  (signature type of parameters and return
  results)

68

• Boundary between Analysis and Design
• Boundary between analysis and design is vague,
  but certain guidelines for what should be
  described during analysis and what should be
  dealt with during construction
• Analysis is application-oriented
• Analysis is independent of the implementation
  environment
• Analysis model describes the elements of the
  application as service modules
• Analysis model should not be too elaborate, as
  some of this work must be adapted to the chosen
  implementation environment

69

• Implementation
• Major product of this phase is the source code
• 3 activities Coding, unit testing and
  integration testing
• Coding Write the source code for some component
  of the system
• Unit testing Subject component to a number of
  tests for reliability and validity
• Integration testing Test groups of unit-tested
  components according to an integration strategy.

70

• System Testing
• Entire software system is subject to a variety of
  tests (Alpha testing Acceptance test at
  developer site).
• Major goal is to make sure all components created
  and tested during implementation function
  together as a system.
• Question Is the problem solved?
• Verification Are we building the product right?
• Validation Are we building the right product?
• Tests whether the product works as intended.
  Requires careful planning and coordination.

71

• Delivery
• Time during development when we help the users to
  understand and feel comfortable with the product
• Question to ask Can the customer use the
  solution?
• Documentation
• Developer Documentation
• User Documentation
• Administrator Documentation
• Operator Documentation

72

• Maintenance
• System development is complete when the system is
  operational in its intended environment.
• Any work done that changes the system after it is
  in operation is considered maintenance.
• Question to ask Are enhancements needed?
• Maintenance is not repair or prevention of
  breaks
• Loop constructs do not wear out!
• Software does not degrade
• Software systems are built to incorporate change.

73

• Summary
• Software life cycle
• The development process is broken into individual
  pieces called software development activities
• No good model for modeling the process (black
  art)
• Existing models are an inexact representation of
  reality
• Nothing really convincing is available
• Software development standards
• IEEE
• MIL
• Standards help, but must be taken with a grain of
  salt
• What are we using in COM 3205 Agile Software
  Development

74
(No Transcript)
75
Communication

• Bernd Bruegge

76
Communication is important

• A Communication Example
• "Two missile electrical boxes manufactured by
  different contractors were joined together by a
  pair of wires.
• Pair of Wires
• Box 1
• Box 2

77

• A Communication Example ctd
• Thanks to a particular thorough preflight check,
  it was discovered that the wires had been
  reversed.
• Box 1
• Box 2

78

• After the Crash...
• "The postflight analysis revealed that the
  contractors had indeed corrected the reversed
  wires as instructed.
• Indeed, both of them had.

79

• Communication is Important
• Communication Mode
• Type of information exchange that has defined
  objectives and scope
• Scheduled Planned Communication
• Event DrivenUnplanned Communication
• Communication Mechanism
• Tool or procedure that can be used to transmit or
  receive information
• Synchronous Sender and Receiver are available at
  the same time
• Asynchronous Sender and Receiver are not
  communicating at the same time.