Software Development Methods and Tools

Chapter 8

Overview:

1. Software Requirements Specification

2. Top Level: Architecture & Methodology1. Methodology, risks, metrics, reviews,

documentation

3. Detailed Design1. Modularizing, interface design, coding style &

techniques, reviews

2. Verification & validation, documentation!

Software Development Considerations Safety risk & relationship to device FDA level

– what is the role of the software re: the general device usage?

Defining objectives & assumptions Group responsibilities Subcontract? Monitoring & verification? Chronologies, contingencies, consequences,

criteria?

Development Models:

Waterfall – requirements first, then step 1, verify, step 2, verify, …

Incremental Delivery – delivery of parts (functions) in a stepwise fashion

Sprial – determine objective 1, evaluate risks & mitigate, evaluate, determine objective 2, ...

Clean room – Formally set up requirements. Code & statistically test to requirements (no device.)

Software Development and Engineering Management Planning for safety

(FDA!) Planning for risk

assessment Planning for method

Waterfall Incremental delivery Spiral Cleanroom Code and fix, …

Software design levels: Top-level1. Design alternatives and tradeoffs

2. Software architecture

3. Choosing a methodology

4. Structural analysis

5. Object Oriented design

6. Choosing a language

7. Software risk analysis

8. The Software Requirements Traceability Matrix

9. Software Review

Software design levels: Detailed

1. Design techniques

2. Performance predictability and design simulation

3. Module specification

4. Coding

5. Design support tools

6. Design as a basis for verification and validation testing.

Details to follow ………=>

Design alternatives and tradeoffsA investigation into various potential

methodologies to satisfy requirements of the device software design …

Various aids are used, including dataflow diagrams, control flow diagrams, customer desires, maintainability issues, redundancy issues, self test issues, …

The end result is an architecture model…

Software architecture – high level Module definitions & tasks & interfaces File names, tables, data structures, alternatives Algorithms to be used, others dropped Objects defined Change protocol Memory use, normal & extreme Templates for I/O, test, processing Final design diagrams (flow, data, control, etc.)

Choosing a methodology

Developers biases & skills must be accounted for, then …

Structured Analysis – analysis of the programming requirements as an embodiment of the data flow in the system. OK for small/medium projects –

Object-Oriented Design – design based upon objects & operations on those items, not on data flows per se.

Choosing a Language: Concerns Strong type checking Separate compilation Used-defined data types Data encapsulation Data abstraction

Kind of Programs More Effective Languages

Less Effective Languages

Structured Data Ada, C/C++, Pascal Assembler, Basic

Quick and Dirty Project

Basic Ada, Assembler, Pascal

Fast Execution Assembler, C Interpreted Languages

Mathematical Calculations

Fortran Pascal

Easy to Maintain Ada, Pascal C, Fortran

Dynamic Memory Usage

C, Pascal Basic

Limited Memory Environments

Assembler, Basic, C Ada, Fortran

Real Time Program Ada, Assembler, C Basic, Fortran

String Manipulation Basic, Pascal C

Language Suitability for Programming Situations

Making a choice…

Clarity, simplicity, and unity of language concept

Clarity of program syntax Naturalness of application Support for abstraction Ease of verification Programming environment And familiarity, ease of use, etc.

Language Pros Cons

Ada Some software engineering techniques are embedded in the language. Portable, broad range of language constructs. Built in microprocessing

Large, overkill for many applications. Development systems are expensive to purchase. Life cycle costs are up front

Assembler Very fast, low-level programming when other languages are unsuitable

High maintenance cost due to level or readability. High probability of errors, not portable, old, low level language

Basic Good beginner language. Straight forward commands.

Slow, unstructured, difficult to maintain

C Wide usage, portable, fast, powerful. Recently became an ANSI standard language

Too powerful for the inexperienced programmer.

Cobol Good for large amounts of data, simple calculations, business record processing

Bad for scientific applications, poor support of complex calculations, slow.

Fortran Well suited for scientific and engineering applications.

Old technology

Modula-2 Pascal-like, yet modular. Not widely used, no language standard, several dialects.

Pascal Flexible data typing, structured, good beginner language.

Monolithic, confining

Pros and Cons of Software Languages

Software Risk Analysis

Software Hazard Analysis – hazards id’d, normal, maintenance, failure conditions, … rank order & correct.

Software Fault Tree Analysis – undesired states id’d, analysis of outcome, correct

Real Time Logic – is a risk potentially possible given the model of the system…

Requirements Traceablity MatrixTabular (ie Excel) listing of requirements versus

design entities, with all change orders, etc. identified as time goes on…

Assurance of completeness and provides data to anyone concerned with traceability…

Software Review(s):

Periodic design reviews are mandatory & may include: Inspections of design and code……. Code walk-throughs……. Code reading……. Dog-and-pony shows…….

Design Techniques:

Good software design practice is more than a matter of applying one of the latest design methodologies. Thorough requirement generation, requirements tracking, requirements analysis, performance predictability, system simulation, and uniform design reviewing are all activities that contribute to the development of safe and effective software designs.

Performance Predictability and Design Simnulation: Try to predict performance of your system in

advance… Single processor – try to use mathematical

modeling techniques, then select processor. Multiple processors – up front design

specifications are even more important as interactions may cause problems…

Module Specifications:

Detailed specifications of module elements (mspecs) are mandatory in proper design…

name, pseudocode, I/O details, data structures, etc.

Coding:

Generally the last phase of design (now), heavily dependent on proper specifications up front, particularly the mspecs.

Readability and documentation (in-line) is mandatory.

Design Support Tools:

Use available CASE (computer aided software engineering) tools! Documentation Proof of design strategy Backup of documents Improved quality, reliability, deliverability..

Design as the Basis for Verification and Validation Activity: Verification: product satisfies expectations

Design reviews Code reviews

Validation: satisfies design and coding rules…

Summary:

Top level design Architecture – language – risks – metrics- reviews

Detailed design Predict – simulate – code - document