Software Development

Fundamentals

1
Objectives
• Provide basic software information that all systems engineers should
know
• Understand typical software development sequence
• Understand importance of good software requirements
• Understand how software requirements are used to develop code
• Gain brief familiarity with different methods of software design

2
Objectives (2)
• Provide basic software information that all systems engineers should
know
• Recognize different software languages and their usages
• Gain familiarity with typical software components
• Understand basics about microprocessors and software trade-offs

3
Introduction
• Software Development Sequence
• Requirements to Design to Code

• Software Requirements
• Specifying requirements rather than implementation
• Requirements specification examples
• Software Change Requests

4
Introduction (2)
• Analysis and Design
• Translation of requirements into design
• High level overview of analysis design methods
• Design Examples

5
Introduction (3)
• Code
• Assembly Language
• High Level Language
• Modula-GM
• C
• C++
• How to choose between assembly language and high level language

6
Introduction (4)
• Typical Software Components
• Operating Systems
• Serial Communications
• Diagnostics
• Hardware I/O
• Algorithms

• Calibrations

7
Introduction (5)
• Microprocessor Resources
• Throughput Utilization
• ROM Usage
• RAM Usage
• I/O Types

• Microprocessor Selection Considerations

8
Introduction (6)
• Software Verification
• Reviews
• Checks
• Tests

9
Target Audience
• New systems engineers
• particularly engineers in the SySEP
• Only very limited knowledge of systems or software at Delphi-D is
assumed
• Goal is to provide familiarity with concepts that frequently arise
• Goal is not to provide an in-depth examination of each topic covered

10
Software Development
Fundamentals

Software Development
Sequence

11
Software Life Cycle - Waterfall
• Software developed in successive stages
• Stages consist of a single activity
• Interaction between consecutive stages only

12
Software Life Cycle - Waterfall
• Replace with file waterfall.tif

13
Software Life Cycle - Spiral Model
• Many iterations of software development and software release
• Ideally performed on a function-by-function basis
• Typically performed on sets of requirements changes
• Must plan so that all requirements eventually implemented

14
Software Life Cycle - Spiral Model
• Replace with file spiral.tif

15
Software Development Process Flow

Requirements
Review

Design
Design
Review

Code
Code
Review

Integration
and Test

16
Software Development Process Flow -
Requirements
Requirements
Review

• Provided by customer and/or systems engineer

• Reviewed either internally or with the provider

17
Software Development Process Flow - Design

Design
Design
Review

• Design developed based on the requirements

• Design review conducted to verify that design satisfies requirements

18
Software Development Process Flow - Code

Code
Code
Review

• Code developed based on the design

• Code review conducted to verify that code properly implements
design

19
Software Development Process Flow -
Integration and Test

Integration
and Test

• Software integrated into complete package

• Tested on development bench and/or via simulation

20
Software Development
Fundamentals

Software Requirements

21
Software Requirements
• All software requirements are documented
• Documentation includes all required functionality
• including inputs and outputs
• Documentation includes all implementation constraints
• Characteristics of good requirements
• Changes to requirements occur via SCR, and requirements
documentation is updated

22
Product Definition Document (PDD)
• All requirements must be documented in the PDD
• this includes direct customer requirements for software
• all internal software requirements
• embedded manufacturing test requirements
• service requirements
• PDD can reference other documents
• software requirements frequently documented in a Software Requirements
Document (SRD)

23
Software Requirements Process
• The absolute most important part of software development!
• Baseline requirements for each function as an input to the design
process
• Focus on what is required, not implementation details

24
Obtaining Software Requirements
• Sometimes provided directly by customer
• Sometimes developed by the systems engineer
• based on customer requirements
• In either case, systems and software engineers involved in
requirements elicitation
• increases understanding and eliminates hand-offs

25
Allocating Requirements to Software
• Requirements are allocated to different disciplines by systems
engineers
• step 2 of systems common process
• Allocating to proper function is critical
• trade-offs between hardware and software
• If software engineers do their job correctly, the software will perform
the exact function documented in the requirements

26
Requirements Management
(When is it performed?)
Customer Product
Interface Mech Dwg

Interface
Cust. Reqts

(ICDs)
Docs
BOTC - new
Process -modified
-clarified Available Reuse
Objects Create Initial
Mech Dwg
Documented Generate DE & Document
Customer Generate Create ICDs
Customer Customer "Reqts Customer Reqts
Review / PCEs for reqts for DE-to-DE Internal Reqts
Reqts Analysis Business Allocation
Requirements Approve changes / product instrumentation,
Analysis Report" Review of reqts Review(s)
RAR adds interfaces manuf, service
PCEs

DE Create Initial
Baseline New Reuse Object PDD
Processes Team Interface Cust Reqts Reqts

Analysis
and

Report
- preliminary

Reqts
Documents
Procedures allocation + RAR
DE's Additional Requirements

- implementation / Create Initial

reuse affects SRS
DE Design
Standards
and Best
Practices
Steps of Reqts Management:
(repeat for each stage of reqts - customer, product, derived)

Gov't
- Acquire (elicit) requirements from the customer Complete

Initial
PDD
Regulations - Analyze the requirements (includes traceability) Product Reqts
- Allocate requirements among elements of the system
All coordinated reqts (those requiring
- Document the requirements
DE Lessons cooperative design solutions) must
- Baseline the requirements be noted
Learned /
System - Control and assess changes to the requirements
Knowledge - Track and report on requirements status

27
PDD Discussion Exercise
• What if the only software requirements are those received directly
from the customer?
• What are some of the possible outcomes (positive and negative) from
this scenario?
• What can we do to address the negative outcomes from this
scenario?

28
Characteristics Of A Good Software
Requirement
• Necessary
• Essential that the software performs this function
• If removed, a product deficiency will exist
• Should be traceable to a higher level requirement
• Concise
• States only what must be done
• Easy to read and understand
• Each requirement is documented separately

29
Characteristics Of A Good Software
Requirement (2)
• Unambiguous (Clear)
• One engineering interpretation
• Precise
• Detailed
• Implementation Free
• States what is required
• Does not state how the requirement should be met
• Biggest problem with software requirements at Delphi-D

30
Characteristics Of A Good Software
Requirement (3)
• Complete
• No missing sections
• No TBDs
• Any TBDs should include plan for resolution
• Consistent
• No conflicts with other requirements
• No duplication of another requirement
• Same term is used for the same item in all requirements

31
Characteristics Of A Good Software
Requirement (4)
• Feasible (Implementable)
• Microprocessor resources available
• Required Information available
• Maintainable
• Changes can be made easily, completely, and consistently
• Verifiable
• Method exists to check that the product meets the requirements
• Objectively testable as a single requirement

32
Software Requirements Examples
• Replace with file bua_req.doc, sir_req.doc, pt_scr1-6.tif

33
Software Requirements Reviews
• All software requirements reviewed with systems and software
• Reviews completed by function
• cannot review entire software requirements in one meeting
• Review meeting format
• systems peer reviews
• software peer reviews

34
When Should Requirements Reviews Occur?
• Critical that reviews conducted prior to the next logical phase of
development process
• Requirements reviews should occur prior to beginning of software
design

35
rements Reviews
• To improve the software work product
• To exchange information and lessons learned between developers
• Not to evaluate the developer

36
Advantages of Requirements Reviews
• Common understanding of what the product must do
• Early resolution of areas of confusion
• Identification of incomplete or missing items
• Minimizes propagation of errors throughout the software
development process
• Minimizes rework and schedule delays
• Baseline of feasible, clear, consistent, and testable requirements

37
Software Development
Fundamentals

Software Change Control

38
Software Change Control
• Requirements will change as the program progresses
• Disciplined approach to documenting and controlling software
changes
• Process initiated after software item is baselined
• Document requested changes for software related items
• Software Change Requests (SCRs) in CSS
• Request for System Modification (RSM) in Powertrain

39
Categories for SCRs
• New allocated requirement
• Allocated requirement change
• Changed implementation
• Software coding error
• Planned change

40
Key Information Contained on SCR
• SCR Status
• SCR Description
• Test Plan
• SCR Type
• Functional Area and Program(s) affected
• Assigned to
• Target delivery date and level
• Associated Review Number
• Resolution

41
Blank SCR
• Replace with file blank_scr.tif

42
Sample Completed SCR
• Replace with files example_scr.tif and pt_scr0-6.doc

43
Initiated by Customer,
Systems or Software
Software Change Control
Identify Targeted
Software Release Process
Approve or Reject
SCR

Review Proposed Change

with Customer/Sys/SW

Assign SCR for

Resolution

Review SCR against

SCR Checklist

Implement in Software
or Requirements Spec

Software Released and

Change Verified

SCR Closed

44
SCR Usage
• SCRs must be retained for history of the program
• SCRs must be written to modify or correct a problem associated with
the software
• SCRs must be tracked to closure
• SCRs must be written for every independent change

45
Automated Software Change Control
• Automated software change reporting and tracking system
• Creating
• Reporting
• Tracking
• Action Request System (ARS) user tool
• Ingress relational database
• Depending on Product Line, used by customers, systems engineers,
and software engineers

46
SCR Tool Features
• Paperless system
• Separate databases for each project or group of
projects
• Automated numbering scheme
• Customized reporting capabilities
• Status history for progression of resolution activity
• Metrics collection and reporting
• Multiple query and sort capability
• Automatic status notification
47
Software Change Control Metrics
• Tracked each month as part of software status report
• Number of software changes
• Number of each category of software changes
• Percent of each categories of software changes

• Why would we collect this data?

48
Software Change Control Metrics Example
• Replace with file metrics.xls

49
SCR Exercise - 1
Situation: The current software (dev_07) for the 2000 DBC 7.2 program does not
satisfy the specification. The specification calls for a diagnostic check to be
executed only when speeds are less than a calibration value (KE_Speed) and
when the vehicle is in drive. As the systems engineer for the program, you have
determined that the software incorrectly executes the diagnostic check whenever
the vehicle speed is less than 20 mph.

Write an SCR to request this change

Discuss what steps you would take to approve this SCR

50
SCR Exercise - 2
Situation: The current software (dev_04) for the 2001 Warren PCM program
satisfies the specification. As systems engineer for the program, you believe it is
necessary to add a new diagnostic to detect a stuck coolant temperature sensor.

Write an SCR to request this change

Discuss what steps you would take to approve this SCR

51
Software Development
Fundamentals

Analysis and Design

52
Analysis and Design Process
• Various methods used within Delphi-D
• Functional Decomposition
• Structured Analysis and Structured Design
• Object Oriented Design concepts
• Flowcharts
• Pseudo Code
• Probably the weakest aspect of software development at Delphi-D

53
Analysis and Design Methods
• Three broad categories of classification for structured methods
• Process: what is being done
• Control: when it is being done
• Data: what is being manipulated
• All formal methods start out assuming one of these is most important

54
Functional Decomposition
• Focus is on what is being done (Process)
• System viewed as one large process
• Primary process continuously divided into sub-processes
• repeated until simple, primitive processes remain
• Order of execution defined second (Control)
• Organization of data is final step (Data)

55
Functional Decomposition Tradeoffs
• Advantages
• Models are fairly easy to understand
• Widely used and intuitively appealing
• Disadvantages
• Models are unstable to requirements changes
• Missing information not easily detected
• Often drives a specific implementation

56
Event Response
• System viewed as a blackbox with pre-planned responses to external
events
• External events identified (Control)
• Responses defined as separate processes (Process)
• Data requirements derived from need to link processes (Data)

57
Event Response Tradeoffs
• Advantages
• Fairly reproducible models
• Models are fairly easy to understand
• Disadvantages
• Method assumes requirements are complete and consistent
• Results are unstable if requirements change

58
Object Oriented
• Focus is on what is being manipulated in the system (Data)
• System is viewed as a set of objects
• Attributes and relationships of objects defined
• Dynamic behavior of data described next (Control)
• Objects definition and lifecycle defined last (Process)

59
Object Oriented Tradeoffs
• Advantages
• Very reproducible models
• Models stable with requirements changes
• Early detection of missing definition
• Disadvantages
• Not initially easy to understand
• Does not handle external events well

60
Advantages of Analysis and Design Process
• Helps identify ambiguous requirements prior to coding
• Better understanding of the problem
• Provides (allows for) traceability of requirements
• Provides faster response to customer change
• Improves maintainability
• Identify areas sensitive to change

61
Advantages of Analysis and Design Process
• Design and code reuse
• Modular (structured) software development
• minimize coupling
• the degree of interdependence between two modules
• maximize cohesion
• the measure of strength of functional relatedness of elements within a module
• Mechanism for document standardization
• More efficient coding

62
Flowcharts
• One of original methods of design
• Uses pre-determined structures
• Demonstrates flow of the software
• Does not provide good overview of product
• pre-supposes high level design

63
Pseudo-code
• When used, it is typically for assembly language programs
• Similar to a high level language
• does not compile
• does not have as much formality
• Easy to develop software from pseudo-code
• Does not provide good overview of product
• pre-supposes high level design

64
Object Oriented Example - An Information
Model
Air_Delivery_Door
select the
Buttons @door_id
is controlled by position of
@ button_id + door_current_position
+ button_type + door_desired_position
+ active_state + door_status
C
+ button_status
+
speed may be
determines if override affected by
Defrost_Blower_Override
condition exists and
@Override_id
Rotary_switch R3 controls the blower
+ Override_status
@ switch_id + sensor_id (R)
+ switch_type + door_id (R)
+ active_state
position may affect
+ switch_status
C supply data for the speed of the
+

Blower
is controlled by selects the @blower_id
speed of + blower_current_speed
Sensors + blower_desired_speed
@sensor_id + blower_ramp_rate
+ sensor_value + blower_status
+ sensor_status
+ gets data from

65
Object Oriented Example - State Transition
Diagram
Defrost Mode Inactive
1. Post status = defrost mode inactive
2. Gen_event: Disable blower override ::= blower_id
Defrost Mode Active ::= overrride_id

Defrost Mode Inactive ::= override_id

Defrost Mode Inactive ::= override_id

Check sensor for enable Check sensor for disable

1. Post_status = check sensor 1. Post_status = check sensor
2. Get sensor data (sensor_id, sensor_value) 2. Get sensor data (sensor_id, sensor_value)
3. If (sensor_value < 150) then 3. If (sensor_value < 150) then
Gen_event:Enable blower override ::= blower_id Gen_event:Override Active ::= override_id
Gen_event:Override Active ::= override_id Gen_event:Enable blower override::= blower_id
Else Else
Gen_event:Override Not Active ::= override_id Gen_event:Disable blower override ::= blower_id
Gen_event: Override Not Active ::= override_id

Override Active ::= override_id

Override Not Active ::= override_id
Timer expired ::= override_id

Timer expired ::= override_id

Defrost Mode Active Override Enabled
Defrost Mode Active Override Disabled 1. Post status = defrost mode active override enabled
1. Post status = defrost mode active override disabled 2. Gen_event: Activate Recheck Timer::= timer_id, time
2. Gen_event:Activate Recheck timer::= timer_id, time

Override Active ::= override_id

Override Not Active ::= override_id

66
Design Examples
• Replace with files teamwork.doc, flowchart.doc, and priorit.pcode

67
Software Development
Fundamentals

Software Languages

68
Software Languages
• Assembly Language
• High Level Language
• Modula-GM
•C
• C++
• How to choose between assembly language and high level language

69
Assembly Language - Background
• Low-level programming language
• Instructions correspond closely to the instruction set of a given
computer
• Different instruction set for each microprocessor
• One-to-one translation of programming instructions to machine
instructions
• Most efficient use of memory
• Originally used by all product lines at Delphi-D

70
Assembly Language - Future
• Still in use by some areas of Delphi-D
• SIR and Audio most prominent users
• Use at Delphi-D is reducing
• SIR and Audio transitioning to C

71
Assembly Example
• Replace with file priorit.asm

72
Resulting Assembly Listing
• Replace with file priorit.asmlist

73
High-Level Languages
• Requires less knowledge of computer on which program will be
executed
• embedded systems still require knowledge though
• Can be translated into several different machine languages
• Supports data structures and program logic
• Several machine instructions for each program statement

74
Modula-GM - Background
• Developed by Delco Electronics and Intermetrics in 1986
• Very efficient language
• Provides limited functionality and flexibility
• Supports commonly used programming concepts
• including fixed point math
• Strongly typed language
• Many errors identified at compile time
• At one time, used by HVAC, Powertrain, and Chassis
• Outstanding language for embedded software development

75
Modula-GM - Future
• Still in use by various areas at Delphi-D
• some Powertrain programs
• most Chassis programs
• some HVAC programs
• Limited future due to proprietary nature of the language
• Limited availability of compilers
• HC11, GMPX, CASM
• Limited software development tool availability

76
Modula-GM Example
• Replace with files priorit.def and priorit.imp

77
Resulting Assembly Listing
• Replace with file priorit.mgmlist

78
C - Background
• Originally very inefficient language, but significant improvements in
recent years
• approaching efficiency of Modula-GM
• Provides outstanding functionality and flexibility
• but does not expressly include features commonly used at Delphi-D
• does not provide fixed point math implementation
• Weakly typed language
• Many errors identified at run time

79
C - Background (2)
• Development tool support in industry is outstanding
• Most commonly used language for embedded software development
in industry

80
C - Future
• The software development language of the future at Delphi-D
• Used in all product lines
• Most new programs developing in C

81
C Example
• Replace with files priorit.h and priorit.c

82
Resulting Assembly Listing
• Replace with file priorit.clist

83
C++
• Extensions to C which include many good programming features
• strong type checking
• data hiding
• Industry support is growing, but more needed
• Too inefficient for use in most current automotive embedded
applications
• Not currently in use for production programs
• Embedded C++ (EC++)
• possible language of the future for embedded systems

84
C++ Implementation and Resulting Assembly
Code
• No C++ compiler available for embedded targets at Delphi-D
• Safe to say substantially more code required

85
Reasons to Use High Level Language
• Faster Development
• Fewer engineers per program
• Reduced cycle time
• Fewer Errors
• Less time wasted debugging
• Increased customer satisfaction
• Less risk of field problems
• Reuse Facilitated
• More modular design
• Increased understanding
• Portable from one target to another

86
Reasons to Not Use High Level Language
• More Memory Required
• More Throughput Required

87
Assembly Versus High Level Language -
Considerations
• Volume
• As volume increases, assembly gains advantage
• Size of Software Package
• As size increases, ability to manage assembly decreases
• Target Microprocessor
• 8-bit processors with few registers are manageable in assembly
• More complex processors (e.g. CASM, GMPX) become more difficult in
assembly
• Schedule Constraints

88
Assembly Versus High Level Language -
Considerations (2)
• Existing Code
• Reuse of existing software can save engineering cost and risk
• Available Tools
• Compiler must be efficient for the target if high level language to be used
• Toolset must be available at/to Delphi-D
• Roll-Out Plans
• Potential target changes make high level language more attractive

89
Exercise - 1
Situation: For a MY 2001 SIR product, a set of minor software changes need to be
made to the 2000 SDM-G assembly language software. The program is using an
8-bit Motorola HC08 microprocessor. The program is relatively small, at about
20K bytes of program space.

What language would you choose to do the MY 2001 program?

What considerations led you to choose that language?

90
Exercise - 2
Situation: The Powertrain product line has just won new business with a new
customer. As such, it is necessary to develop a MY 2003 PCM. Volume is
substantial. The software required will be one of the largest programs ever
developed at Delphi-D. For the first model year, a 32-bit Motorola GMPX will be
used. After that, a new low cost microprocessor will likely be available.
Currently, assembly, Modula-GM, and C code exists for various PCMs.

What language would you choose to do the program?

What considerations led you to choose that language?

91
Exercise - 3
Situation: The Audio product line has just won new business with an existing
customer. Volume is substantial. The development time for the software is only
4 months. Software code size is estimated to be either 30K in assembly language
or 40K in C. Unfortunately, the microprocessor family mandated by the customer
has program space of either 32K (for $4.50) or 48K (for $5.25). Some existing C
code (25%) could be reused; slightly more assembly code (35%) could be reused.

What language would you choose to do the program?

What considerations led you to choose that language?

92
Software Development
Fundamentals

Typical Software
Components

93
Typical Software Components
• Operating System
• Serial Communications
• Diagnostics
• Hardware I/O
• Algorithms

94
Operating System
• Calling sequence for all algorithms
• Two main types in use at Delphi-D
• Cyclic Executive
• Pre-emptive Executive

95
Cyclic Executive
• Each task executes at a set point in time
• 5 mS
• 20 mS
• 100 mS
• Tasks generally have no priority
• Some high priority interrupts can occur
• serial communications
• execution time must be low

96
Pre-Emptive Executive
• Tasks execute once during their prescribed period
• Higher priority tasks can interrupt lower priority tasks
• All tasks have an assigned priority

97
Operating System Example
A program has the following tasks:
10 mS
Task A 1 mS
Task B 1 mS
20 mS
Task C 2mS
Task D 3mS
Task E 1mS
40 mS
Task F 4mS
Task G 2mS

98
Operating System Example (2)
• Replace with file cyclic.xls

99
Serial Communications
• Communication with all other devices in the vehicle
• Communication with diagnostic tools
• Different hardware and software implementations
• CAN
• Class 2
• UART
• Critical part of every program

100
Diagnostics
• Designed by systems engineers to meet
• customer requirements
• manufacturing requirements
• service requirements
• Self-check of operation of controller and associated hardware
• Identified problems are recorded as diagnostic failures
• fault codes accessible by diagnostic tool
• May set a diagnostic light in vehicle

101
Hardware I/O
• Software that provides the interfaces between the software and the
hardware
• Defined by systems and software engineers
• Varies for every microprocessor
• Typically developed part in assembly and part in high level language
• Translates all external inputs into software values
• Generates external outputs from software values

102
Hardware I/O Example
• Replace with file hw_io.doc

103
Algorithms
• Applications software
• Fundamental part of every program
• Unique part of every program
• Varies by product line and customer

104
Calibrations
• Run time constants
• Allows single software set to be used for multiple applications
• Represent values that vary between vehicles
• Software is written such that it operates with any valid calibration
value
• Amount of calibrations varies greatly
• 40 bytes for some Security products
• 80K bytes for some Powertrain products

105
Calibration Example
• Calculation of Vehicle Speed
• As wheel revolves, pulses are sent to the microprocessor
• Depending on tire size, a pre-determined number of pulses per mile
• The number of pulses per mile is the calibration value
• Software processes the received pulses and based on time between
pulses and calibration value, calculates vehicle speed

106
Software Development
Fundamentals

Microprocessors

107
Microprocessor Resources - A Software
Perspective
• RAM
• KAM (non-volatile memory)
• Program Space
• ROM
• FLASH
• EEPROM
• Execution rate (throughput)

108
Microprocessor Resources - A Software
Perspective (2)
• Inputs and Outputs
• Discrete outputs
• Discrete inputs
• Analog inputs
• Timers
• PWM outputs
• Interrupts
• General timer channels

109
Program Space
• Each assembly language instruction requires
• x bytes of program space
• y execution cycles to execute
• The values for x and y vary from instruction to instruction
• Heavily dependent on the microprocessor

110
Sample sheets from HC11 book
• Replace with file motorola1-4.tif

111
Example - 1
• Implement the following: If a counter is not equal to zero, decrement
the counter
bytes cycles
2 3 LDAA counter
2 3 BNE label
1 2 DECA
2 3 STAA counter

• 7 bytes, 11 cycles (direct page memory)

112
Example - 2
• Implement the following: If a counter is not equal to zero, decrement
the counter
bytes cycles
3 4 LDAA counter
2 3 BNE label
1 2 DECA
3 4 STAA counter

• 9 bytes, 13 cycles (extended page memory)

113
Example - 3
• Implement the following: If a counter is not equal to zero, decrement
the counter
bytes cycles
3 6 TST counter
2 3 BNE label
3 6 DEC counter

• 8 bytes, 15 cycles (direct or extended page memory)

114
Microprocessor Selection Considerations
• Program Timing
• Development Configurations
• Production intent configuration required at EDU?
• Program Volume
• Programming Language
• Development Tools
• Instrumentation
• In-vehicle instrumentation
• Bench instrumentation

115
Microprocessor Selection Considerations (2)
• Program Space
• Flash
• OTP
• ROM
• RAM
• EEPROM
• Throughput

116
Microprocessor Selection Considerations (3)
• A/D
• 8-bit or 10-bit accuracy
• Discrete I/O
• Timer Channels
• Mathematical Accuracy
• Communications
• CAN
• Class 2
• UART
• SPI

117
Microprocessor Selection Considerations (4)
• Special Wake Up Conditions
• Wake Up on ignition
• Controlled power down sequence
• Bus wake up
• COP Watchdog
• Temperature Range
• EMC
• Package Type

118
Software Development
Fundamentals

Software Verification

119
Software Verification
• Historically viewed as 8 week period at end of program where final
testing is done
• Common Software Process distributes these activities through the
entire software development
• Verification consists of
• Reviews
• Checks
• Tests
• Program team determines which are appropriate and when

120
Software Verification - Reviews
• Formally inspect work product to provide evidence that it satisfies the
requirements
• Software Peer Review Work Instruction
• Similar to requirements reviews
• Systems engineers likely invited to design reviews
• Systems engineers not typically invited to code reviews

121
Software Verification - Checks
• Formally check that the work product satisfies
• Standards
• Lessons Learned
• Best Practices
• Historically the primary means of performing verification
• Role of systems engineer varies depending on product line

122
Software Verification - Desk Checks
• Typically performed by a software engineer at a desk
• Source listings of code utilized
• Software specific checks
• Language specific
• different checklists for different languages
• Example items
• memory utilization,
• conformance to standards
• flag usage

123
Software Verification - Bench Checklists
• Typically performed by systems or software engineers
• Combination of software and functional checks
• Language independent
• Example items
• throughput utilization
• interrupt handling
• conformance to requirements

124
Software Verification - Checks
• Replace with files desk_check.txt and bench_check1.txt and
bench_check2.txt

125
Software Verification - Checks
• Replace with hardcopies from SIR

126
Software Verification - Tests
• Exercise executable object code to detect defects
• Exercise executable object code to ensure it satisfies requirements

127
Software Verification - Tests
• Develop test cases based on requirements
• List inputs
• List expected outputs
• Develop procedures based on test cases
• Step by step instructions
• Execute test procedures
• Document results
• Resolve issues

128
Questions

129