Software Quality

Get Started. It's Free
or sign up with your email address
Software Quality by 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 Software engineers shall act consistently with the public interest.

1.2.2. CLIENT AND EMPLOYER 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 Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

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

1.2.5. MANAGEMENT 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 Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

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

1.2.8. SELF 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 Internal Audit On behalf of management

2.1.2. 2nd patry Supplier Audit On behalf of customer

2.1.3. 3rd party Certification audit 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) This is the document result of audit activity consist of : Section I Section II Section III 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 One auditor will audit all phases of SDLC in one project Through SDLC of one project Identify weak areas of implementation

2.4.2. Horizontal One auditor only focus in one phases of SDLC One auditor may assign into more then one project Across projects Based on earlier findings

3. 6. Quality Measurement

3.1. Definitions

3.1.1. Measurement consist of: Entities Attributes Rule / Scales

3.1.2. Kinds of measurement Base / Primitive Measurement Derived Measure / Matric

3.2. Software Size Measurements

3.2.1. Function Point Analysis Definitions Function points are a unit measure for software 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. Important Terms and Definition Five Standard Functions Data Functions Transactional Functions Steps 1. Determine the type of count. 2. Identify the scope and boundary of the count. 3. Determine the unadjusted FP count. 4. Determine the Value Adjustment Factor (VAF). 5. Calculate the Adjusted FP Count. Reference

3.2.2. SLOC (Source Line of Code) 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 The defect removal efficiency (DRE) gives a measure of the development team ability to remove defects prior to release.

3.3.2. Formula 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 Is the ratio of defects to size Defect density is typically measure per thousand lines of code (KLOC) 1.0 defects/KLOC typically represents a good quality project Microsoft Applications which have about 10 – 20 defects/KLOC during in-house testing and 0.5/KLOC in released product.

3.4.2. Formula 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 Definitions A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives. Process Oriented Audit whole process To prevent defect QA Tasks Documenting and improving organization’s processes Developing and enforcing standards Implementing a metrics program Establish a review/inspection process

4.2.2. QC Definitions A set of quality related activities designed to evaluate a developed work product (project deliverables) Quality control is used to verify that deliverables are of acceptable quality and that they are complete and correct. Audit the product Identify the defect Product oriented Control Cycle Test Find Error Fix Error Retest

4.3. Verification v.s Validation

4.3.1. Verification Are you building the product right? That is, are you meeting the specified requirements? The purpose of Verification process is to make sure the product meet the specified requirements.

4.3.2. Vlidation Are you building the right product? That is, are you meeting the operational need? 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 Definitions Characteristics relating to achievement of the essential purpose for which the software is being engineered. The output should be as per specification Sub-Characteristic Suitability Accurateness Interoperability Compliance Security

5.1.2. Reliable Definition it should function accurately for a long period of time and also function correctly over all ranges and combination data Characteristics relating to capability of software to maintain its level of performance under stated conditions for a stated period of time. Sub-Characteristics Maturity Fault tolerance Recoverability

5.1.3. Usablility Definitions Usability only exists with regard to functionality and refers to the ease of use for a given function. easy to use Sub-Characteristics Understandability Learnability Operability

5.1.4. Efficientcy Definitions With minimum resources This characteristic is concerned with the system resources used when providing the required functionality. Sub Characteristics Time behavior Resource behavior

5.1.5. Maintainability Definitions The ability to identify and fix a fault within a software component is what the maintainability characteristic addresses. Sub-Characteristics Analyzability Changeability Stability Testability

5.1.6. poratbility Definitions Should be able to be executed on different machines and environments This characteristic refers to how well the software can adopt to changes in its environment or with its requirements. Sub-Characteristics Adaptability Installability Conformance Replaceability

5.2. 5 KPI’s of Good Enough Software

5.2.1. Utilitarian Strategy The art of qualitatively analyzing and maximizing net positive consequences in an ambiguous situation. There is no right or wrong project estimate, just an integrated, dynamic estimation process.

5.2.2. Evolutionary Strategy On the Project Level Ongoing process education, experimentation and adjustment, rather than clinging to a notion of the “One Right Way to develop software” On the Product Level Planning and building the product in layers, which allows concurrent design, coding, and testing. On the Problem Level Keeping track of history, and learning about failure and success over time.

5.2.3. Heroic Teams Ordinary skillful people working in effective collaboration Programmers must exercise initiative 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 Upper management pays attention to projects. Upper management pays attention to the market. The organization identifies and resolves conflicts between projects. In conflicts between projects and organizational bureaucracy, projects win. Project experience is incorporated into the organizational memory

5.2.5. Dynamic Processes "clarify and delegate" strategy Portability Scalability 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 The Cost of Quality is the total amount the company spends to achieve the quality of its product.

6.3.2. Quality Related Costs Prevention Cost of preventing customer dissatisfaction, including bugs or weaknesses in software, design, documentation, and support. Example Appraisal Cost of inspection (testing, reviews, etc.). Example Internal Failure Cost of dealing with bugs and issue found during development and testing. Example External Failure Cost of dealing with errors that affect your customers, after the product is released. Example