738 to go.

Day 4….

  • Whether positive or negative, variances implies that the process is not under control. In either of the situations, we need to get into root cause analysis and eliminate the variances, and it could be by changing the processes.
  • Process Assets
    • PAL (Process Asset Library) is defined as “A well indexed, searchable respiratory of organizational Process Assets
    • The PAL exists to show special examples, templates and work aids — things that help the folks in your organization follow the process more efficiently and effectively. VERY RARELY is live project data in the PAL. Now, you may have centralized project files on the same server as your PAL, but the PAL is for Process Assets, not project artifacts. This becomes especially important if there is any confidentiality or security constraints on any of your projects.
    • Your project file structure should be something that supports how you work
    • Process Assets would include: policies, procedures, guidelines, forms, checklists, templates etc, and this would go into PAL whereas project specific documents such as a project plan can be placed under project specific configuration management (in your case it would be VSS). This goes to say the template of the project plan will be in PAL whereas the actual plan will be in VSS of the respective projects.
  • “While conducting an appraisal several years back, I witnessed an organization that included a section in the project plan called the ‘PPP’ – Policy, Processes, and Procedures. In that section, they listed the specific PPPs (and templates) – and their associated version numbers – that they would be following on THAT project.”
  • DAR addresses resolution of problems not only in projects but in all functions of the organization
  • PPQA (Product and Process Quality
    • PPQA is the protector of the status quo. They are charged with ensuring that the behaviors exhibited on the project are those expected by management.
    • “Actually, Verification and PPQA look at some of the same work products through very different lenses. When a developer participates in a design review, they are looking for “design elegance.” In addition, they are asking themselves questions like, “Is that the way I would have designed it?” “Does it cover all of the requirements?” “Will it work?” “Can it be coded effectively?” PPQA, on the other hand, reviews the design specification to determine if the designer started with the appropriate template, if the design spec was developed following the appropriate methods and procedures, if the
      spec adheres the organizational design spec standards, etc.
    • PPQA does not imply any product testing is done, and although cmmi defines a’product’ as an example of a ‘work product’, PPQA does not include testing of that product, because work products are only checked for conformance to process descriptions, standards, and procedures. And because this list does not say ‘product or customer reqs’ then the PPQA PA does not *need* to check that the final product works, only that non-final-product work products are OK. So the intent of PPQA is to have great designs, test plans and trace matrices, and then whatever code comes out of the developer is not necessarily tested.
    • PPQA works best AFTER processes have been enhanced and have come to be accepted as value-added by those who use them.
    • Establishing PPQA personnel as internal consultants establishes their credibility for the future process verification role.
  • V&V (Validation and Verification)
    • Verification is checking whether the product is built right or not. Purpose of verification is to ensure the product meets its requirements.
    • Validation is Wether the right product has been built or not. Validation ensures that the product fullfills its “intended” use in its “intended” environment
    • VAL and VER should be applied throughout the lifecycle.
    • At every phase (after the initial requirements/contract) you verify the work (design or further requirements decomposition) against existing functional and contractual requirements (sometimes identifying needed changes to those requirements). This can be through peer reviews, formal technical exchanges with the users and customers, and other methods. Completing the RTM also promotes this activity.
    • VAL is also performed throughout the lifecycle to ensure that what you’re building will really meet the business need (and work). In early stages this may include mock ups (bread boards, frames for wind tunnel tests, etc), story boards (for system flow, user interfaces), proof of concept prototypes, response studies (can we really hit the database, retrieve the data, and format it in that timeframe?), and anything else that answers the questions, 1) does this really meet the need and 2) will it function in the end environment (which might include vacuum, underwater, etc). Less robust
      (but better than nothing) is simple presentations to the user groups for their agreement.
  • On testing
    • “I agree completely that the model does not care who does it, but that it gets done (with some provisions for objectivity as stated in the text). The biggest confusion I see is what they’re checking for. if folks are checking for compliance to standards, templates, and processes they get credit in PPQA. If they’re checking for conformance to CMMI, they get credit in OPF. If they’re checking conformance to documented requirements, they get credit in VER. If they checking for working in the operational environment, they get credit for VAL. All of these can happen at the same time, in the same process. _what you’re checking for_, far less than the title on the business card of the person doing the work, tells you which PA is applicable.
    • The SEI defines quality assurance as ‘A planned and systematic means for assuring management that the defined standards, practices, procedures, and methods of the process are applied.’