Software Quality

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Rocket clouds
Software Quality von Mind Map: Software Quality

1. Software Engineering Code Ethics

1.1. Preamble

1.1.1. Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large

1.1.2. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems

1.1.3. software engineers have significant opportunities to do good or cause harm

1.1.4. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession

1.2. Principles

1.2.1. PUBLIC

1.2.1.1. Software engineers shall act consistently with the public interest.

1.2.2. CLIENT AND EMPLOYER

1.2.2.1. Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

1.2.3. PRODUCT

1.2.3.1. Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

1.2.4. JUDGMENT

1.2.4.1. Software engineers shall maintain integrity and independence in their professional judgment.

1.2.5. MANAGEMENT

1.2.5.1. Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

1.2.6. PROFESSION

1.2.6.1. Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

1.2.7. COLLEAGUES

1.2.7.1. Software engineers shall be fair to and supportive of their colleagues.

1.2.8. SELF

1.2.8.1. Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

2. Audit

2.1. Audit Types

2.1.1. 1st party

2.1.1.1. Internal Audit

2.1.1.2. On behalf of management

2.1.2. 2nd patry

2.1.2.1. Supplier Audit

2.1.2.2. On behalf of customer

2.1.3. 3rd party

2.1.3.1. Certification audit

2.1.3.2. On behalf of Certification body

2.2. The Processes

2.2.1. Audit plan

2.2.2. Audit

2.2.3. Audit reporting

2.2.4. Follow up

2.3. Audit Records

2.3.1. Audit Plan

2.3.2. Non-Conformance Statement (NCS)

2.3.2.1. This is the document result of audit activity

2.3.2.2. consist of :

2.3.2.2.1. Section I

2.3.2.2.2. Section II

2.3.2.2.3. Section III

2.3.2.2.4. Section IV

2.3.3. Audit report for Senior Management meeting

2.3.4. Minutes of Management review meeting

2.4. Audit Startegies

2.4.1. Vertical

2.4.1.1. One auditor will audit all phases of SDLC in one project

2.4.1.2. Through SDLC of one project

2.4.1.3. Identify weak areas of implementation

2.4.2. Horizontal

2.4.2.1. One auditor only focus in one phases of SDLC

2.4.2.2. One auditor may assign into more then one project

2.4.2.3. Across projects

2.4.2.4. Based on earlier findings

3. 6. Quality Measurement

3.1. Definitions

3.1.1. Measurement consist of:

3.1.1.1. Entities

3.1.1.2. Attributes

3.1.1.3. Rule / Scales

3.1.2. Kinds of measurement

3.1.2.1. Base / Primitive Measurement

3.1.2.2. Derived Measure / Matric

3.2. Software Size Measurements

3.2.1. Function Point Analysis

3.2.1.1. Definitions

3.2.1.1.1. Function points are a unit measure for software

3.2.1.1.2. is a structured technique of problem solving. It is a method to break systems into smaller components, so they can be better understood and analyzed.

3.2.1.1.3. Important Terms and Definition

3.2.1.2. Five Standard Functions

3.2.1.2.1. Data Functions

3.2.1.2.2. Transactional Functions

3.2.1.3. Steps

3.2.1.3.1. 1. Determine the type of count.

3.2.1.3.2. 2. Identify the scope and boundary of the count.

3.2.1.3.3. 3. Determine the unadjusted FP count.

3.2.1.3.4. 4. Determine the Value Adjustment Factor (VAF).

3.2.1.3.5. 5. Calculate the Adjusted FP Count.

3.2.1.4. Reference

3.2.2. SLOC (Source Line of Code)

3.2.2.1. is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code.

3.3. Defect Removal Efficiency (DRE)

3.3.1. Definition

3.3.1.1. The defect removal efficiency (DRE) gives a measure of the development team ability to remove defects prior to release.

3.3.2. Formula

3.3.2.1. DRE = Quantity of Bugs during Software Testing / (Quantity of Bugs during Software Testing + Quantity of Bugs found by User)

3.3.3. reference

3.4. Defect Density

3.4.1. Definitions

3.4.1.1. Is the ratio of defects to size

3.4.1.2. Defect density is typically measure per thousand lines of code (KLOC)

3.4.1.3. 1.0 defects/KLOC typically represents a good quality project

3.4.1.4. Microsoft Applications which have about 10 – 20 defects/KLOC during in-house testing and 0.5/KLOC in released product.

3.4.2. Formula

3.4.2.1. total defect / total LOC in (KLOC)

4. Definition

4.1. Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

4.2. QA v.s QC

4.2.1. QA

4.2.1.1. Definitions

4.2.1.1.1. A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.

4.2.1.1.2. Process Oriented

4.2.1.1.3. Audit whole process

4.2.1.1.4. To prevent defect

4.2.1.2. QA Tasks

4.2.1.2.1. Documenting and improving organization’s processes

4.2.1.2.2. Developing and enforcing standards

4.2.1.2.3. Implementing a metrics program

4.2.1.2.4. Establish a review/inspection process

4.2.2. QC

4.2.2.1. Definitions

4.2.2.1.1. A set of quality related activities designed to evaluate a developed work product (project deliverables)

4.2.2.1.2. Quality control is used to verify that deliverables are of acceptable quality and that they are complete and correct.

4.2.2.1.3. Audit the product

4.2.2.1.4. Identify the defect

4.2.2.1.5. Product oriented

4.2.2.2. Control Cycle

4.2.2.2.1. Test

4.2.2.2.2. Find Error

4.2.2.2.3. Fix Error

4.2.2.2.4. Retest

4.3. Verification v.s Validation

4.3.1. Verification

4.3.1.1. Are you building the product right?

4.3.1.2. That is, are you meeting the specified requirements?

4.3.1.3. The purpose of Verification process is to make sure the product meet the specified requirements.

4.3.2. Vlidation

4.3.2.1. Are you building the right product?

4.3.2.2. That is, are you meeting the operational need?

4.3.2.3. The purpose of Validation process is to ensure the product fulfills its intended use when place in its intended environment.

5. Quality Goals

5.1. Software Quality Characteristics

5.1.1. Functionality

5.1.1.1. Definitions

5.1.1.1.1. Characteristics relating to achievement of the essential purpose for which the software is being engineered.

5.1.1.1.2. The output should be as per specification

5.1.1.2. Sub-Characteristic

5.1.1.2.1. Suitability

5.1.1.2.2. Accurateness

5.1.1.2.3. Interoperability

5.1.1.2.4. Compliance

5.1.1.2.5. Security

5.1.2. Reliable

5.1.2.1. Definition

5.1.2.1.1. it should function accurately for a long period of time and also function correctly over all ranges and combination data

5.1.2.1.2. Characteristics relating to capability of software to maintain its level of performance under stated conditions for a stated period of time.

5.1.2.2. Sub-Characteristics

5.1.2.2.1. Maturity

5.1.2.2.2. Fault tolerance

5.1.2.2.3. Recoverability

5.1.3. Usablility

5.1.3.1. Definitions

5.1.3.1.1. Usability only exists with regard to functionality and refers to the ease of use for a given function.

5.1.3.1.2. easy to use

5.1.3.2. Sub-Characteristics

5.1.3.2.1. Understandability

5.1.3.2.2. Learnability

5.1.3.2.3. Operability

5.1.4. Efficientcy

5.1.4.1. Definitions

5.1.4.1.1. With minimum resources

5.1.4.1.2. This characteristic is concerned with the system resources used when providing the required functionality.

5.1.4.2. Sub Characteristics

5.1.4.2.1. Time behavior

5.1.4.2.2. Resource behavior

5.1.5. Maintainability

5.1.5.1. Definitions

5.1.5.1.1. The ability to identify and fix a fault within a software component is what the maintainability characteristic addresses.

5.1.5.2. Sub-Characteristics

5.1.5.2.1. Analyzability

5.1.5.2.2. Changeability

5.1.5.2.3. Stability

5.1.5.2.4. Testability

5.1.6. poratbility

5.1.6.1. Definitions

5.1.6.1.1. Should be able to be executed on different machines and environments

5.1.6.1.2. This characteristic refers to how well the software can adopt to changes in its environment or with its requirements.

5.1.6.2. Sub-Characteristics

5.1.6.2.1. Adaptability

5.1.6.2.2. Installability

5.1.6.2.3. Conformance

5.1.6.2.4. Replaceability

5.2. 5 KPI’s of Good Enough Software

5.2.1. Utilitarian Strategy

5.2.1.1. The art of qualitatively analyzing and maximizing net positive consequences in an ambiguous situation.

5.2.1.2. There is no right or wrong project estimate, just an integrated, dynamic estimation process.

5.2.2. Evolutionary Strategy

5.2.2.1. On the Project Level

5.2.2.1.1. Ongoing process education, experimentation and adjustment, rather than clinging to a notion of the “One Right Way to develop software”

5.2.2.2. On the Product Level

5.2.2.2.1. Planning and building the product in layers, which allows concurrent design, coding, and testing.

5.2.2.3. On the Problem Level

5.2.2.3.1. Keeping track of history, and learning about failure and success over time.

5.2.3. Heroic Teams

5.2.3.1. Ordinary skillful people working in effective collaboration

5.2.3.2. Programmers must exercise initiative

5.2.3.3. Bored People don’t work hard. If there is an exciting environment that fosters responsible heroism, good software will follow

5.2.4. Dynamic Infrastructure

5.2.4.1. Upper management pays attention to projects.

5.2.4.2. Upper management pays attention to the market.

5.2.4.3. The organization identifies and resolves conflicts between projects.

5.2.4.4. In conflicts between projects and organizational bureaucracy, projects win.

5.2.4.5. Project experience is incorporated into the organizational memory

5.2.5. Dynamic Processes

5.2.5.1. "clarify and delegate" strategy

5.2.5.2. Portability

5.2.5.3. Scalability

5.2.5.4. Durability

6. General Strategy

6.1. Common Faults in Software

6.1.1. Incorrect calculations

6.1.2. Incorrect data edits

6.1.3. Ineffective data edits

6.1.4. Incorrect coding/implementation of business rules

6.1.5. Difficult to maintain and understand

6.2. Causes of Software Faults

6.2.1. Faulty requirements definition

6.2.2. Client-developer communication failures

6.2.3. Logical design errors

6.2.4. Coding errors

6.2.5. Documentation errors

6.3. Quality Cost Analysis

6.3.1. Definitions

6.3.1.1. The Cost of Quality is the total amount the company spends to achieve the quality of its product.

6.3.2. Quality Related Costs

6.3.2.1. Prevention

6.3.2.1.1. Cost of preventing customer dissatisfaction, including bugs or weaknesses in software, design, documentation, and support.

6.3.2.1.2. Example

6.3.2.2. Appraisal

6.3.2.2.1. Cost of inspection (testing, reviews, etc.).

6.3.2.2.2. Example

6.3.2.3. Internal Failure

6.3.2.3.1. Cost of dealing with bugs and issue found during development and testing.

6.3.2.3.2. Example

6.3.2.4. External Failure

6.3.2.4.1. Cost of dealing with errors that affect your customers, after the product is released.

6.3.2.4.2. Example