CIS 375 SOFTWARE ENGINEERING

University Of Michigan-Dearborn

Dr. Bruce Maxim, Instructor

Software Quality:

Assess Quality:
    1. Correctness;
    1. Maintainability;
    1. Integrity = å [1 - threat * (1 - security)];
    1. Usability =
    1. DRE - defect removal efficiency;

Quality:

(Engineering definition)
    1. Of Design - characteristics of product specified by designer.
    2. Of Conformance - degree to which specifications were followed during manufacture.

Quality Assurance:

Consists of :

Auditing and reporting functions of management.

Goal:

To provide data to management to allow informal decision making regarding the artifact (software).

Total Quality Management:

(TQM)
    1. Develop visible and repeatable processes.
    2. Examine intangibles affecting processes and optimize their impact.
    3. Concentrate on user’s application of the product and improve the process.
    4. Examine uses of product in the market place.

Software Quality Assurance:
    1. Software requirements conformance - is the basis for measuring quality.
    2. Specified standards define developmental criteria and guide software engineering process.
    3. There is an implicit set of requirements which must be met.

Software Quality Assurance Group:

Duties:
    1. Prepare SQA plan.
    2. Participate in developing project software description.
    3. Review engineering activities for process compliance.
    4. Audit software product for compliance.
    5. Ensure product deviations are well documented.

Structured Walkthrough: (Design review)

Peer review of some product - found to eliminate 80% of all errors if done properly.

Why Do Peer Review?
    1. To improve quality.
    2. Catches both coding errors and design errors.
    3. Enforce the spirit of any organization standards.
    4. Training and insurance.

 

Formality Timing:

~ After analysis.

~ After design.

~ After compilation (first).

~ After test run (first).

~ After all test runs.

Roles In Walkthrough:
    1. Presenter (designer/producer).
    2. Coordinator (not person who hires/fires).
    3. Secretary (person to record events of meeting, build paper trail).
    4. Reviewers
    1. Maintenance oracle.
    2. Standards bearer.
    3. User representative.

Guidelines For Walkthrough:
    1. Keep it short (< 30 minutes).
    2. Don’t schedule two in a row.
    3. Don’t review product fragments.
    4. Use standards to avoid style disagreements.
    5. Let the coordinator run the meeting.

Formal Approaches To SQA:
    1. Proof of correctness.
    2. Statistical quality assurance.
    1. Clean room process (combine #’s 1 & 2).

Software Reliability:

Measures:

= MTTF (mean time to failure) + MTTR (mean time to repair).

Reliability Models:
    1. Predicts reliability as a function of chronological time.

      2. VS

    2. Predicts reliability as a function of elapsed processor time.

Reliability Models That Are Derived From Hardware Reliability Assumptions:

    1. Debugging time between errors has exponential distribution - proportional to # of remaining errors.
    2. Each error is removed as it is discovered.
    3. Failure rate between errors is constant.

Models Derived From Internal Program Characteristics

Seeding Models:

Take errors and arbitrarily place them into the code, to see how long it takes to catch the seeded errors.

Criteria For Evaluating Models:
    1. Predictive validity.
    2. Capability (produce useful data).
    3. Quality of assumptions.
    4. Applicability (can it be applied across domain types).
    5. Simplicity.

Maintenance:

(Longest life cycle phase)

Evolving system vs. Declining:
    1. High maintenance cost.
    2. Unacceptable reliability.
    3. System adaptable to change?
    4. Time to effect change.
    5. Unacceptable performance.
    6. System functions limited in usefulness.
    7. Other systems? (faster, cheaper).
    8. High cost to maintain hardware.

Maintenance Team:
    1. Understand system.
    2. Locate information in documentation.
    3. Keep system documentation up to date.
    4. Extend existing functions.
    5. Add new functions.
    6. Find sources of errors.
    7. Correct system errors.
    8. Answer operations questions.
    9. Restructure design and code.
    10. Delete obsolete design and code.
    11. Manage changes.

Types Of Maintenance:
    1. Corrective (21%) fixing errors in original product.
    2. Adaptive (25%) fixing errors created by fixing other errors.
    3. Perfective (50%) client needs changes.
    4. Preventative (4%) prevent new errors.

Maintenance Difficulty Functions:
    1. Limited understanding of hardware and software (maintainer).
    2. Management priorities (maintenance is low priority).
    3. Technical problems.
    4. Testing difficulties (finding problems).
    5. Morale problems (maintenance is boring).
    6. Compromise (decision making problems).

Maintenance Cost Factors:
    1. Type supported applications.
    2. Staff turnover.
    3. System life span.
    4. Dependence on changing environments.
    5. Hardware characteristics.
    6. Quality of design.
    7. Quality of code.
    8. Quality of documentation.
    9. Quality of testing.