System Design and Implementation AMS505 6'4 Winter 2001

1
System Design and ImplementationAMS505 6.4
Winter 2001

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Overview

• design allocating functions to modules
• hardware versus software
• commercial off-the-shelf (COTS) software versus
  custom software

3
Allocation of Functions

• Determination of major computational components
  of the system
• Process of deciding which system functions will
  be accomplished by which elements of the system
• human, hardware, software, database,
  documentation, procedures
• Control complexity by dividing it into manageable
  units
• Traceability of functions to subsystems
• Subdivide further to implement functionality

4
System Design

• Allocation of functionality to type
• Analysis of tradeoffs between competing criteria
• Very much driven by current state of technologies

5
Allocation to Modules

• In an ideal world, done only based on engineering
  criteria
• In practice, reasons for allocation often for
  most serious constraints
• geographic
• environmental
• contractual
• legal
• project control
• criticality

6
Allocation Heuristics

• determine areas most likely to change
• high risk
• poor understanding
• new technology
• develop a trial subsystem definition
• high priority requirements first
• minimize external interfaces (coupling)
• group similar functions (cohesion)
• isolate areas of likely change (information
  hiding)
• limit complexity through partitioning
  (testability)
• target subsystems at particular expertise domains

7
Iteration

• examine next-level partitioning
• map back to a concept of operations
• do scenario analysis
• look at verification and validation strategies
• have domain experts review subsystems
• examine alternatives

8
Trade-offs

• Project
• pre-established cost and schedule bounds
• risks associated with cost and schedule estimates
• Business
• most profitable configuration (short and long
  term)
• market for system
• time to market
• competitors
• Technical
• present and emerging technologies
• bleeding edge pain versus market direction
• Maintainability

9
Trade-offs (II)

• Manufacturing and supply
• resource availability
• quality issues
• Human issues
• availability of trained people
• human interfaces
• Organizational politics
• Security
• Environment
• heat, cold, vibration, weathering
• interfaces to the world
• foreign systems, sensors, input/output data
• rates of response
• Legal
• liability, regulations, intellectual property

10
Hardware versus Software

• Hardware
• large engineering cost
• large per-unit cost
• fast
• can act directly on physical world
• difficult to encode complex behaviour
• changes late in the design cycle are expensive
• expensive to change once deployed
• relatively easy to configuration manage

• Software
• large engineering cost
• per-unit cost 0
• slower
• acts on physical world indirectly through
  hardware
• easy to encode complex behaviour
• changes late in the design cycle are expensive
• may be cheap to change once deployed
• difficult to configuration manage, especially
  hardware/software combinations

11
Software Maintenance

• Software isnt maintained in the classic sense
• Hardware maintenance consists of
• preventive maintenance (e.g., oiling, replacing
  worn parts)
• corrective maintenance (e.g., repairing or
  replacing failed parts)
• Software maintenance consists of modifications to
  correct deficiencies or adapt to changes in the
  real world
• you cant oil it
• it doesnt wear out
• the parts dont fail

12
Hardware Failure Curve
13
Software Failure Curve (Ideal)
defect removal
failure rate
residual defects (constant)
time
14
Software Failure Curve (Actual)
Huh?
failure rate
time
15
Custom vs COTS software

• Custom
• developed specifically for client requirement
• typically, complete source code of product
  developed in house or under contract
• customer may have limited or unlimited
  intellectual property rights to final product
• developer retains some rights for modification
  and resale to other customers
• normally has a user-base of one (the original
  client)
• client responsible for funding 100 of future
  maintenance

• COTS
• developed to meet a business opportunity
• typically, source code not available, only
  finished product
• customer generally has no intellectual property
  rights pays a per-unit license fee for use
• developer retains all rights for modification and
  resale to other customers
• normally has relatively large user-base
• future maintenance based on business model of
  supplier

16
COTS Software

• COTS software can be used many ways
• use an existing package as-is (e.g., MS Word)
• use a generic package specifically designed for
  customization to requirements (e.g., PeopleSoft,
  SAP)
• use an existing product but have a special
  version made for you (e.g., SIC-F becomes LFCS)
• use a large-grained existing product inside a
  custom product (e.g., use Oracle as the database
  in a custom application)
• develop a custom product based on a source code
  framework (e.g., use IBM's "San Francisco"
  framework for MIS development)
• develop a custom product integrating many small
  products (e.g., calendar display tool, text entry
  tool, GUI module, etc.)

17
Decision COTS versus custom

• COTS software typically
• less expensive than developing from scratch
• higher quality than initial custom release
• more difficult to control
• custom software typically
• free of intellectual property issues, license
  fees
• more expensive to maintain
• exact fit to customer requirement
• purchasing COTS software different more like
  buying a car than designing a bridge
• may not meet all requirements
• best compromise from available products

18
Next ClassQuality, Verification and Validation