I have a question. When people performa a review to assure than a coding standard is being used, is it considered a PPQA audit or a verification activity (VER)?
The correct answer is, it depends upon the nature of the review. If your documented software development process states that the coding standard is used to write code. Then a process audit of the software development process would be looking at the coding standard and determining if it was indeed being used by the developers. That would be a Process and Product Quality Assurance (PPQA) audit activity. If your documented verification process stated that a code peer review involves comparing the code to the coding standard, then that would be a Verification (VER) activity. And if your documented processes specified both of these conditions, then the answer to your question is both a PPQA audit activity and a VER activity. How you view the code review against the coding standard is therefore context dependant.
If you are asking this question because you are preparing your Direct and Indirect Evidence for your PIIDs and a SCAMPI A appraisal, then you will need to explain the context so the appraisal team will be able to correctly evaluate the evidence.
Showing posts with label verification. Show all posts
Showing posts with label verification. Show all posts
Monday, August 3, 2009
Monday, June 16, 2008
Interpreting RD SP 1.2
Please help me understand Requirments Development (RD) Specific Practice (SP) 1.2 Develop the Customer Requirements. The Typical Work Products listed for this practice are
How are work products 2 and 3 different from the first work product?
The expected component for SP 1.2 is “Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.” There are many different ways to accomplish this Specific Practice as well as there are many different work products that will be created by accomplishing this SP. Your question is regarding the list of Typical Work Products. Typical Work Products are part of the Informative Component and are NEITHER required NOR expected. They are provided to give you some idea or hint, if you need it, as to what types of work product(s) result from transforming needs etc. into customer requirements.
Customer requirements are the most obvious output or work product from this SP. The other two may only be evident or applicable when providing a custom-built product. In this situation the customer may be placing some restrictions on how you perform verification and/or validation. Possibly on the use of certain test facilities, use of certain test data, etc. The specific constraints would be specified by the customer and/or be the result of requirements analysis.
In my opinion, it is not that important to be concerned about the second and third items in the list of Typical Work Products. What is important is performing the practice and creating the list of customer requirements. The proper performance of this practice will determine what the true work products are for your organization. And, in point of fact, you may end up calling all three examples of Typical Work Products “customer requirements.”
- Customer requirements
- Customer constraints on the conduct of verification
- Customer constraints on the conduct of validation
How are work products 2 and 3 different from the first work product?
The expected component for SP 1.2 is “Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.” There are many different ways to accomplish this Specific Practice as well as there are many different work products that will be created by accomplishing this SP. Your question is regarding the list of Typical Work Products. Typical Work Products are part of the Informative Component and are NEITHER required NOR expected. They are provided to give you some idea or hint, if you need it, as to what types of work product(s) result from transforming needs etc. into customer requirements.
Customer requirements are the most obvious output or work product from this SP. The other two may only be evident or applicable when providing a custom-built product. In this situation the customer may be placing some restrictions on how you perform verification and/or validation. Possibly on the use of certain test facilities, use of certain test data, etc. The specific constraints would be specified by the customer and/or be the result of requirements analysis.
In my opinion, it is not that important to be concerned about the second and third items in the list of Typical Work Products. What is important is performing the practice and creating the list of customer requirements. The proper performance of this practice will determine what the true work products are for your organization. And, in point of fact, you may end up calling all three examples of Typical Work Products “customer requirements.”
Subscribe to:
Posts (Atom)