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-level 1. 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 tradeoffs A 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 DataAda, C/C++, PascalAssembler, Basic Quick and Dirty Project Basic Ada, Assembler, Pascal Fast ExecutionAssembler, C Interpreted Languages Mathematical Calculations FortranPascal Easy to MaintainAda, PascalC, Fortran Dynamic Memory Usage C, PascalBasic Limited Memory Environments Assembler, Basic, CAda, Fortran Real Time ProgramAda, Assembler, CBasic, Fortran String ManipulationBasic, PascalC 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.
LanguageProsCons AdaSome 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 AssemblerVery 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 BasicGood beginner language. Straight forward commands. Slow, unstructured, difficult to maintain CWide usage, portable, fast, powerful. Recently became an ANSI standard language Too powerful for the inexperienced programmer. CobolGood for large amounts of data, simple calculations, business record processing Bad for scientific applications, poor support of complex calculations, slow. FortranWell suited for scientific and engineering applications. Old technology Modula-2Pascal-like, yet modular.Not widely used, no language standard, several dialects. PascalFlexible 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 Matrix Tabular (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…
Your consent to our cookies if you continue to use this website.