Upload
uta-winters
View
32
Download
3
Embed Size (px)
DESCRIPTION
Software Development Methods and Tools. Chapter 8. Overview:. Software Requirements Specification Top Level: Architecture & Methodology Methodology, risks, metrics, reviews, documentation Detailed Design Modularizing, interface design, coding style & techniques, reviews - PowerPoint PPT Presentation
Citation preview
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