Software Development Methods and Tools

Document Sample
Software Development Methods and Tools Powered By Docstoc
					Software Development
Methods and Tools

   Chapter 8
Overview:

1.        Software Requirements Specification
2.        Top Level: Architecture & Methodology
     1.    Methodology, risks, metrics, reviews,
           documentation
3.        Detailed Design
     1.    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-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
Language Suitability for Programming Situations

   Kind of Programs      More Effective        Less Effective
                         Languages             Languages
   Structured Data       Ada, C/C++, Pascal    Assembler, Basic
   Quick and Dirty       Basic                 Ada, Assembler,
   Project                                     Pascal
   Fast Execution        Assembler, C          Interpreted
                                               Languages
   Mathematical          Fortran               Pascal
   Calculations
   Easy to Maintain      Ada, Pascal           C, Fortran
   Dynamic Memory        C, Pascal             Basic
   Usage
   Limited Memory        Assembler, Basic, C   Ada, Fortran
   Environments
   Real Time Program     Ada, Assembler, C     Basic, Fortran
   String Manipulation   Basic, Pascal         C
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.
 Pros and Cons of Software Languages

Language    Pros                                         Cons

Ada         Some software engineering techniques are     Large, overkill for many applications. Development
            embedded in the language. Portable, broad    systems are expensive to purchase. Life cycle costs are
            range of language constructs. Built in       up front
            microprocessing

Assembler   Very fast, low-level programming when        High maintenance cost due to level or readability. High
            other languages are unsuitable               probability of errors, not portable, old, low level
                                                         language

Basic       Good beginner language. Straight forward     Slow, unstructured, difficult to maintain
            commands.

C           Wide usage, portable, fast, powerful.        Too powerful for the inexperienced programmer.
            Recently became an ANSI standard
            language

Cobol       Good for large amounts of data, simple       Bad for scientific applications, poor support of complex
            calculations, business record processing     calculations, slow.

Fortran     Well suited for scientific and engineering   Old technology
            applications.

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


Pascal      Flexible data typing, structured, good       Monolithic, confining
            beginner language.
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…
Summary:

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


   Detailed design
       Predict – simulate – code - document