Thursday, December 20, 2007

Risk Management

Risk Exposure = Level of Impact X Probability

Level of Impact: This is an estimate of the overall scale of the impact following an occurrence of risk. This is rated on the following scale: Very high impact, High impact, Medium impact, etc.

Probability: Likelihood of occurrence of an event.

Mitigation: This is an action to avoid the occurrence of the risk or to mitigate/lessen the chances/impact of the risk. On failure of mitigation, contingency plan is used. Mitigation is preventive. You apply mitigation plan even before the risk has occurred (to avoid occurrence of risk).

Early warning: This is an assessment of known parameters which are indications of risk, and are those which if not controlled can lead to occurrence of the risk. This is useful for taking the mitigation actions.

Contingency: Alternative actions to be taken in case, despite applying mitigation strategy, the risk occurs. Generally, risk realization leads to a change in schedule, effort, cost, project control, customer satisfaction, defects, etc. Hence, contingency is applied to identify which parameters would be affected by the risk and how they would be handled. Contingency is corrective. You apply contingency after the risk has occurred.

  1. When a project starts, prepare its risk profile (which is the threat the project poses for the business.)
  2. Pick up (from the PPDB) the most commonly occurring risks the project might be exposed. Record them in the risk tracker.
  3. Identify other probable sources of risk
  4. Classify the risks, identify their Impact on the business
  5. Identify their probability of realization
  6. Identify Mitigation and Contingency plans
  7. Define the threshold for mitigation and Contingency
  8. Revisit the risks at regular intervals (during weekly team meets / client calls).
  9. Note: At any point in time, PM and team should be aware of the three top risks plaguing the project.

Thursday, December 13, 2007

Process implementation...

For long running projects without defined processes, do not attempt a big bang approach. People are resistent to change. A big bang approach will lead only to greater resistance. Try to work out the as-is process and suggest improvements. Apply metrics to see the current level of performance. This will help in understanding areas which can be oiled for maximum efficiency. The measurements also allow for assessing the weakest links, forging of which will lead to enhanced performance.

After you have set up basic metrics in place, reach out to the client team to understand their expectations. Report the metrics to the client team. Facts will provide a handle to justify (realize if process tweak is necessary) the efforts of development team.

Talk with the development team to understand the challenges of implementing a defined process. Come out with a basic ETVX model for the as-is process. Suggest improvements to it. After the process flow has been established in consultation with the project manager, disseminate the information to the entire team via classroom sessions. Randomly check each developer to see if the defined process is being followed. Capture metrics at each stage of the defined process.

Compare the new metrics with the older ones to see the improvement in proces performance.

Wednesday, December 12, 2007

SQA Interview Questions...

  1. What is software quality assurance?
  2. What is a process?
  3. What are the two views of Quality?
  4. What is CoQ, and what are the types of Cost of Quality?
  5. What is the difference between COQ and COPQ?
  6. What is the difference between Verification and Validation?
  7. What is Baselining?
  8. How is a Walkthrough different from Review
  9. Differentiate between a Bug and a Defect.
  10. Define the terms - Code Coverage, Code Inspection, Code Walkthroughs.
  11. How is White box testing different from Black box testing?
  12. What is Regression testing?
  13. What is a metric?
  14. Define: Quality Circle, Quality Control, Quality Assurance, Quality Policy
  15. Differentiate Static Testing from Dynamic Testing.
  16. Differentiate between QA and Testing.
  17. What are the common problems in developing software?
  18. What is the role of a Quality Assurance professional in an organization?
  19. What is Configuration Management?
  20. What are the two types of configuration audits? How is functional config audit different from physical config audit?
  21. What do you understand by Acceptable Quality Level?
  22. What is Benchmarking?
  23. What do you understand by Earned Value Management / Return on Investment?
  24. How is a procedure different from a process?
  25. What is Risk Exposure?
  26. Differentiate between a Risk and an Issue.
  27. How is small q different from Big Q.
  28. How do you differentiate these one from the other - Quality Model, Process Model, Lifecycle Model?
  29. What is DAR? Give a few instances of DAR you have implemented in your projects.
  30. What is CAR? Give a few instances of CAR you have implemented in your projects.
  31. Tell us about a few risks in your projects. How was risk prioritization done?
  32. What is the difference between Contingency and Mitigation?
  33. What metrics do you collect for your projects? How are they aligned with your project goals, engagement goals, and organizational goals?
  34. How did you analyze the metrics you collected?
  35. What is Process Compliance Index? How is PCI derived?
  36. What do you mean by PCB? How do you derive PCBs for your company?
  37. What software lifecycle models does your company use?
  38. What are the various size estimation techniques you know and which ones were u involved in? / How is the size of a project estimated?
  39. How is a Generic Goal different from Specific Goal wrt CMMI?
  40. How is CMMI for Development different from CMMI V1.1
  41. In what ways is Level 3 different from Level 2; Level 2 from the levels below it; and Level 3 from Level 4 and Level 4 from Level 5.
  42. What do you understand by Bi-directional Traceability Matrix? What is foreward traceability, and what is backward traceability?
  43. What is Horizontal Traceability, and what is Vertical Traceability? What are their significance?
  44. Why should a process be tailored / what is process tailoring? / How is process tailoring done?
  45. How do you facilitate process understanding within your organization?
  46. Right from project initiation thru project closure, give a sequence of activities you carry out as SQA for your project.

Process Capability Baseline...

PCB specifies, based on data of past projects, what the performance of a process is. That is, what a project can expect by following a process. The performance factors of a process are primarily those that relate to quality and productivity. PCBs define - Productivity, Quality, Effort Distribution, Defect Distribution, Defect Injection Rate, CoQ, etc.

Using the capability baseline, a project can predict at a gross level the effort that will be needed for various stages, the defects likely to be observed during various development activities, and quality and productivity of the project.

Tuesday, December 11, 2007

Process Assets & Process Database...

Process Assets: Process Assets form the repository to facilitate dissemination of engagement learnings across an organization. A process asset could be any information from an engagement, which can be re-used by future engagements. Typically these include project plans, CM plans, requirements docs, design docs, test plans, standards, checklists, CAR reports, utilities, etc.

Process Database: Process Database is a s/w engineering database to study the processes in an organization with respect to productivity and quality. Its intents are:

a. To aid estimation of efforts and defects.
b. To get the productivity and quality data on different types of projects.
c. To aid in creating process capability baselines (PCBs).