|
Do You Have a Verification Plan? |
|
|
|
|
Project management is about planning and execution. A plan that begins with how you want the project to conclude. As electronics become more complex, verification increases. A good plan contains goals using metrics, with optimal resource usage and realistic schedule estimates.
When managers and their teams engage in planning, the results of that process typically do not address the problems that cause slips, or productivity and quality issues. Most plans focus solely on task performance rather than defining the verification problem, independent of its solution.
 Most teams don’t do complete verification planning. They leap to verification environment development before design. Which may lead to an unchanged or inflexible plan? In other words, the verification plan isn’t really a plan, it’s merely a set of incomplete discussion notes that atrophy as the project moves forward.
What is good planning? Verification planning needs to change from a focus on ‘how’ to a focus on ‘what.’ By starting with the important goals of what needs to be verified, the team can ensure the plan is complete and balanced. The plan in this case is more than an engineering specification of how the verification is to be accomplished.
The five basic steps of verification planning are:
1.) Analyze the device specifications
2.) Scope the verification objectives
3.) Identify the feature set of the design
4.) Design detailed coverage models
5.) Select aggregate metrics to track progress
All projects begin with several forms of specifications. There are customer requirements, resource and schedule limitations, build versus buy constraints, systems architecture limitations, and hardware and software design objectives must be considered comprehensively to develop a good plan.
The biggest risk to the project is not anticipating the moving target. Some teams attempt to capture all their requirements and then move through the project sequentially, sometimes called the ‘waterfall method’. In reality the process is quite iterative and does not allow for managing the frequency and burden of those iterations.
The most common failure at the scoping stage is not requiring a comprehensive verification discussion with those involved. All stakeholders must participate in scoping objectives: management; marketing; systems designers; hardware designers; software designers; and the verification team.
The verification team needs to drive the discussions, continuously challenging the team to fill the gaps and identify the unverifiable choices — a key design-for-verification objective. If any of these points of view are missed, the gaps and risks will remain.
Historically, engineers have designed tests, implemented checkers and used code coverage. Test lists have become obsolete as a metric because they have become too numerous to specify or implement. Total coverage is the only means to have a complete picture of the verification status of a project. Functional coverage correlates directly to the features. Assertion coverage relates to functional coverage and also to the implementation integrity. Hardware and software code coverage tell us how well we have exercised the design.
The scoping process results in a list of the features to be verified. The specification must describe those features so that they can be measured. Coverage is used to define the metrics of verification, derived from design features.
The typical failure at this stage of planning is lack of review of the coverage models. Judgment is crucial because it’s a lot better to have verified 100% of the most critical functionality than to have critical functionality lost in a coverage model that is too detailed.
Management is all about planning and executing. Tracking progress is the only way to know your team is executing. Increasingly, teams define milestones that expose possible system integration issues. This requires a fine-grained definition of features that must be working at each milestone. By using coverage to define those features, the project milestone becomes important for much more than simply marking a box in the schedule as complete.
http://www.cadence.com/
|
Most teams don’t do complete verification planning. They leap to verification environment development before design. Which may lead to an unchanged or inflexible plan? In other words, the verification plan isn’t really a plan, it’s merely a set of incomplete discussion notes that atrophy as the project moves forward.
