Software Quality Control

- SFQ is pertaining to conformance to the functional requirements.

- The SFQ is measured by the level of end user satisfaction.

- The usability and the intuitiveness and responsiveness of the use cases are referred, so as to determine the simplicity / complexity of the operations.

- SFQ compliances with the original design, and desired testability.

- Example: Voice of the Customer can be compared with the level of intuitiveness and responsiveness to measure the quality.

- Project Manager – Controls the software engineering work performed during the software development.

- Designer – Assists the team to complete the overall design of the software project implementation.

- Technical Advisors – Supports to implement all technical aspects and imposes the quality practices.

- Checkers/Testers - Performs the complete testing of the software project at various levels.

- Quality Assurance Manager – Conforms the software product is as per the expected result with proper guidance and co-ordination with the development team.

- Quantifying the dimensions of the software product, to what extent the rate of the product is met.

- Qualitative and quantitative approaches provide the aggregate view of the product.

- Linear continuum need to be supplemented by the identification of the critical programming bugs.

- Consequences that might lead to catastrophic outages need to be properly identified.

- The critical application characteristics measurement involves the structural attribute measurement of the application architecture, coding, in-line documentation.

- Quality being part of every day operations, is the internal impact.

- Quality becomes as a part of setting and managing the objectives, practices.

- The open up of operations to customer audits, is the external impact.

- Procedures and record-keeping improve dramatically.

- The implementation of this standards will obviously takes the work to keep audits and the appropriate follow-ups fluent.

Transcendental View : Quality can be recognized and not defined.

User View: Quality as suitable for the needs.

Product View : Quality as related to the inherent characteristics of the product.

Value-based View: Quality is dependent on the number of customers those who are willing to pay for the software product.

Development View : Quality that is in conformance to specification.

Following are the benefits of SQC:

- Increased productivity of the development team.

- Improved Product Quality: Test statistics and defect tracking are more precise and up to date.

- Decreased re-work costs as the detection of defects are found earlier in the software project development lifecycle in every stage.

- Increased confidence levels in existing product management and future product development.

- Increased credibility as the software produced will be highly qualitative.

The following are the activities of project control:

- Verify the integrity of the database files.

- Check the transcription errors while inputting and referencing the data.

- Verify the data consistency.

- Perform the internal review of documents.

- Perform the completeness check.

- Compare the existing results with previous results.

a. Review of requirement.

b. Review of design.

c. Review of code.

d. Review of deployment plan .

e. Review of test plan.

f. Review of test cases.

a. Unit Testing

b. Integration Testing

c. System Testing

d. Acceptance Testing

The activities that are involved in Software Quality Control are Reviews and Testing.

Reviews:

a. Review of requirement.

b. Review of design.

c. Review of code.

d. Review of deployment plan .

e. Review of test plan.

f. Review of test cases.

Testing:

a. Unit Testing

b. Integration Testing

c. System Testing

d. Acceptance Testing

Control charts are suitable for tracking items such as:

Production failures

Defects by life cycle phase

Complaint/failures by application/software

Response time to change request

Cycle times/delivery times

Mean time to failure

Risk can be anything that leads to failure / defect / error in the apllication or process.

We can avoid risk by applying proper risk matrix in the process.Risk Matrix shows the controls within application systems used to reduce the identified risk, and in what segment of the application those risks exist.

Consider,Team members are leaving from the organization in the middle of the project is the risk for the Manager.For that he can take the preventive action by ask for the bond from the employee or can have the countable backups in the project.

Noise variable factors either cannot be controlled or are difficult and or expensive to control during the design or actual production stage.

Design of experiments

according to me i track bug by defect tracking tool and i report it through defect life cycle. i i was wrong please correct me

The CMM is a way to communicate capabilities.

The ISO is a way to communicate the process.

Generally after the tester writes the Test cases it is reviewed by the peer and then by the lead, sometimes we may also have a review by having walkthrough with the Architect and Business Analyst.

Secondly when we go for the execution phase, and when the tester logs a defect it will first be reviewed or a triage meeting we be done to validate if the defect is valid or not.

There is nothing called as a bad defect. If the defect is not valid( in terms if it is the actual requirement) then it is considered as invalid and not a bad defect.