1 / 24

Software Development Methods and Tools

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

zytka
Download Presentation

Software Development Methods and Tools

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Development Methods and Tools Chapter 8

  2. Overview: • Software Requirements Specification • Top Level: Architecture & Methodology • Methodology, risks, metrics, reviews, documentation • Detailed Design • Modularizing, interface design, coding style & techniques, reviews • Verification & validation, documentation!

  3. 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?

  4. 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.)

  5. Software Development and Engineering Management • Planning for safety (FDA!) • Planning for risk assessment • Planning for method • Waterfall • Incremental delivery • Spiral • Cleanroom • Code and fix, …

  6. Software design levels: Top-level • Design alternatives and tradeoffs • Software architecture • Choosing a methodology • Structural analysis • Object Oriented design • Choosing a language • Software risk analysis • The Software Requirements Traceability Matrix • Software Review

  7. Software design levels: Detailed • Design techniques • Performance predictability and design simulation • Module specification • Coding • Design support tools • Design as a basis for verification and validation testing. Details to follow ………=>

  8. 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…

  9. 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.)

  10. 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.

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

  12. Language Suitability for Programming Situations

  13. 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.

  14. Pros and Cons of Software Languages

  15. 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…

  16. 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…

  17. Software Review(s): • Periodic design reviews are mandatory & may include: • Inspections of design and code……. • Code walk-throughs……. • Code reading……. • Dog-and-pony shows…….

  18. 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.

  19. 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…

  20. Module Specifications: Detailed specifications of module elements (mspecs) are mandatory in proper design… name, pseudocode, I/O details, data structures, etc.

  21. 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.

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

  23. Design as the Basis for Verification and Validation Activity: • Verification: product satisfies expectations • Design reviews • Code reviews • Validation: satisfies design and coding rules…

  24. Summary: • Top level design • Architecture – language – risks – metrics- reviews • Detailed design • Predict – simulate – code - document

More Related