Chapter 2 - Elaborating on the Acceptance Process

Chapter 1 introduced the acceptance process and how it fits into the overall product development lifecycle. The description was was deliberately simple. This chapter introduces some ways to vary the acceptance process to deal with more complex situations including complex organizations and products.

The Role of the Usage Decision

Thus far we have focused almost entirely on the readiness and acceptance decisions. What about the usage decision? It turns out that the usage decision doesn’t directly impact the acceptance decision because it happens after the product is already accepted.

Separating the Acceptance Decision from the Usage Decision

When a software product is being selected or built specifically for a Product Owner by another party, the Product Owner may decide to accept the software as suitable before offering it to the users who will then make the usage decision individually as illustrated in Figure 9.
Figure 9
Figure 9 Acceptance and Usage Decisions and Criteria
Almost all products have many users and each is likely to have their own usage criteria which while it may have influenced the acceptance criteria used during the readiness and acceptance decisions, may in fact be quite different from it. In some cases, the use of the product is not optional, such when software is used to carry out a specific job such as a call center agent or airline reservations system. In these cases the usage decision is made on behalf of the users by their management; this decision need not follow immediately after the acceptance decision as there may be other prerequisites for usage such as user training.
While a user could, in theory, choose not to use the software, the consequence of losing their job would make this decision highly unlikely. The user’s feedback, however, might influence subsequent releases of the software as we’ll see in Feedback from the Usage Decisions.

Determining the Acceptance Criteria

The acceptance decision is made based on some criteria including both functionality and quality related elements. The minimum level of functionality (represented by MMF) and the minimum level of quality (MQR) should be determined well in advance of the acceptance decision to give the Product Development Team of the software a reasonable chance at being able to satisfy them. Therefore, the decisions about the MMF and MQR come before the Acceptance Decision as shown in Figure 9 – Acceptance and Usage Decisions and Criteria.

Feedback from the Usage Decisions

Note that the usage decisions made by individual users after the acceptance decision do not directly affect the acceptance decision but it may, through sales data, post-sales support data or focus groups affect the definition of MMF or MQR for subsequent releases of the product. This is illustrated in Figure 10 - Usage Decision Feedback.
Figure 10
Figure 10 Usage Decision Feedback
While the MQR tends to be fairly constant from one release to the next, the Product Owner may revise the quality criteria for a subsequent release based on the feedback received from users. For example, user testing of an alpha release might reveal that the response times specified in the MQR are not fast enough in practice and might cause the product owner to make them more stringent for the beta or final release.
The MMF for each release tends to be unique because it is the list of functionality that needs to be included to warrant having the release. Feedback from users can influence the MMF based on requests for missing functionality, suggestions for how existing functionality should be changed, and through bug reports.
Feedback from users of Alpha and Beta releases often results in changes to the MMF or MQR of the final release.

Acceptance in Complex Organizations

The simple acceptance process described previously will suffice in many organizations. But there are some organizations whose structure is very complex as are the products they develop. These organizations require a decision-making process that mirrors the complexity of the organization or product. The decisions may be made in series as each decision maker examines the product but this leads to longer elapsed times before the value of the product can be realized. The common solution is to have either the readiness or acceptance testing activities and decision be made in parallel by several organizations each with veto power over the acceptability of the product.
Note to readers: If these scenarios don’t apply to your organization, feel free to skip ahead to 2.31Accepting Complex Products1

Parallel Acceptance Decisions

Many organizations have other departments who are responsible for operating and supporting the system once it is deployed. These departments need to have a say in the acceptance decision. This is reflected in Figure 11– Parallel Acceptance Decisions; it shows several acceptance decisions being made in parallel, each based on a different set of acceptance criteria.
Figure 11
Figure 11 Parallel Acceptance Decisions
When there are several organizations involved in the acceptance decision each with their own area of specialty, each may insist in conducting its own activities independently of each other. Each makes their own decision regarding the release candidate and any one of them can effectively veto the others.
Examples of such stakeholders, and their area of interest, could include:
  • Business Unit – Functionality is acceptable.
  • Operations Department – The product can be managed and supported in production.
  • Corporate Branding – Product complies with branding requirements.
  • Corporate Security – Product has complied with security requirements.
  • Usability Group – Product complies with usability requirements.
This approach introduces risk if the MMF and MQR used by each stakeholder are not included in the MMF and MQR used by the Product Development Team. Ideally, each stakeholder would participate at least part-time in the Product Development Team to ensure that the team truly understands the acceptance criteria and designs the best possible solution to the business need. This participation could be for the entire duration of the project or for one or two iterations focused on that stakeholders needs.
Figure 12 – A Product Development Lifecycle with Parallel Elaboration and Acceptance by Product Owner and Operations -- illustrates the scenario where the Product Owner is the party who has conceived the software as a solution to a business problem and the operations department is tasked with supporting the system once it is put into production.
Figure 12
Figure 12 A Product Development Lifecycle with Parallel Elaboration and Acceptance by Product Owner and Operations

Parallel Readiness Decisions

In some cases several organizations do their own readiness assessment of the release candidate and make independent readiness decisions. The product will not be handed over to the product owner for the acceptance decision if either organization deems the product “not ready” until any additional work they identify has been completed and they deemed the software “ready”. This is illustrated in Figure 13 – Parallel Readiness Decisions.
Figure 13
Figure 13 Parallel Readiness Decisions
Examples of potential stakeholders with parallel readiness decisions include:
  • Product Development Team - Code is passing all unit tests and functional tests
  • Security Team – Design has passed security review
  • Data Architecture Team – Data architecture has been approved
  • Legal Department – All embedded technologies have been suitably licensed.
Again, each of these stakeholders should be considered members of the whole team, even if only part-time, to ensure that the MMF/MQR are addressed by what the Product Development Team builds.
Whether a decision is deemed to be part of readiness or acceptance is somewhat arbitrary. The choice is usually based on when the decision maker wants to get involved and which side of a larger organizational boundary the stakeholder sits. For example, in some organizations the security department may be considered a business function who must accept the release candidate while in others it may have a presence in or near the IT department or product development group and thereby choose to participate when the readiness decision is made. Of course, it is usually preferable to involve these parties much earlier in the project in a more collaborative fashion so that readiness assessment is conducted incrementally as the product is developed.

Accepting Complex Products

Organizations that build large, complex products typically use a more complex version of the acceptance process that involves multi-stage acceptance. Large complex products typically require large numbers of people, too many to work in a single team. While the large complex products are typically composed of components, the teams that build them may be organized in several ways. Each component may be built and owned by a component team or teams may be organized around the functionality provided to the users. The latter approach is called “feature crews” and is widely used by the Developer Division of Microsoft [MillerCarterOnLargeScaleAgile]. The manner in which these people are organized impacts the acceptance process. The kinds of problems found during the acceptance process can be a good indication of the appropriateness of the way we have organized our teams.

Accepting the Output of Component Teams

A common way of subdividing work in large organizations is to decompose the product into components that are built and verified in parallel by separate component teams that each specialize in their resptive technologies and technical or user domains. When this organizational solution is used, each component should have its own readiness assessment prior to conducting readiness assessment on the integrated product. This is illustrated in Figure 14 - Component Teams with Serial Decisions.
Figure 14
Figure 14 Component Teams with Serial Readiness Decisions
Each component must go through a component readiness decision before being integrated into the larger product for subsequent product-level readiness decision. The integrated product is then turned over to the Product Owner for the acceptance decisions. The readiness assessment activities may go by various names including “component testing” or “system testing” for the components and “system testing” or “integration testing” for the entire product. Each component has its own MMF and MQR; hopefully, these are directly tracable from the MMF/MQR for the readiness and acceptance decisions made about the entire product.
This reveals several of the weaknesses of this approach to complex products. First, because the components cannot be directly understood and therefore accepted by the Product Owner, some intermediary, usually an architect has to be responsible for translating Product Owner requirements into component requirements. This effectively transfers product ownership of the component from the Product Owner to the intermediary thereby reducing the degree to which the component team is accountable to the real Product Owner. It is also possible for the component requirements to drift from what is actually required. Second, the product readiness cannot easily be assessed until all of the components have passed their respective readiness decisions and are integrated to form the product. This delays the product readiness assessment until after the “big bang” integration of the components, which is rather late in a project to discover that some of the component requirements were misunderstood. This problem can be somewhat overcome through the use of continuous code integration (CI) practices combined with incremental integration [BasLarmanOnScalingAgile] and incremental acceptance testing but in practice it is much harder to do incremental delivery using component teams (compared to feature teams) and feature teams will typically be able to deliver product-quality software for individual features earlier. It also perpetuates the technical component ghetto by isolating the technical component developers from any understanding of the business.

Accepting the Output of Feature Teams

Another way of organizing the development of large complex products is to use feature teams/crews [BasLarmanOnScalingAgile, EcksteinOnLargeScaleAgile and MillerCarterOnLargeScaleAgile]. Each feature team is responsible for building and verifying a feature based on the Product Owner’s acceptance criteria. Building each feature may involve modifying several components but the team includes expertise on each component and ensures that the components are properly integrated as part of their feature readiness assessment. Therefore, the product readiness assessment and the product acceptance testing are both focused on feature integration rather than on component integration. This scenario is illustrated in Figure 15 – Feature Teams with Serial Acceptance Decisions.
Figure 15
Figure 15 Feature Teams with Serial Acceptance Decisions
Each feature’s readiness decision is made based on the MMF and MQR specific to that feature as determined by the Product Owner (ideally with input from the Product Development Team); no intermediary is required to translate the Product Owner’s requirements into component requirements. The feature readiness decision is a prerequisite for the corresponding feature’s acceptance decision which should use roughly the same acceptance criteria. Meanwhile, the product is integrated and a product-level readiness decision is made based on the product’s MMF and MQR. The product-level MMF should simply be an aggregate of the feature-level MMFs Therefore the interactions between features need to be included as part of the MMF for each affected feature or as separate feature interaction features. When the product-level readiness and all feature-level acceptance decisions are positive, the product-level acceptance decision can be made.
This style of organization and acceptance is usually preferable to component teams because it ensures each team is working with a real end Product Owner and is responsible for delivering a whole product, not just an internal component. See the sidebar Feature Crews on Microsoft Office for an example of how this works in practice in Chapter 9 – Product Manager’s Perspective.
If the Product Owner is a highly-constrained resource, having a large number of feature teams contending for their participation may reduce the effectiveness of this approach. If the interactions between features are a larger risk factor than the risk of technical integration with the technical components, it may be more appropriate to reduce the number of feature teams by delegating more of the work to component teams so that feature interactions can be addressed with single feature teams rather than between them.

Accepting Customizable Products

Many products are built by one organization for sale to another organization, their customer. When the product needs to be customized for each customer there are two distinct acceptance phases for the two different products in question. The first product is the generic product built by the selling organization to the requirements specified by the product manager. The second product is the one built to the specification of the purchasing customer. The construction of the latter product may include either configuration or custom coding in addition to the generic customizable product.
The first acceptance decision is when the product manager accepts the customizable product as saleable to the customers. This acceptance process could be any of the variants described previously including Accepting Complex Products.
The second acceptance decision is when the acquirer of the customizable product accepts the product as customized to their own situation. There is a single acceptance decision for each version of the customizable generic product and one acceptance decision per version of the customized product as shown in Figure 16 – Accepting customizable products.
Figure 16
Figure 16 Accepting customizable products
Sidebar: Accepting Configurable ERP Products. Many software products are sold as generic implementations of a business process that can be configured to suit a business’ specific needs. Two good examples of this are ERP systems such as SAP’s ERP product and Microsoft’s Dynamics. Both provide generic implementations of core business processes such as time-reporting and payroll, supply ordering and accounts payable, product order processing and accounts receivable. The out-of-the-box implementations of these processes can be modified though configuration data or extended by plugging in custom-written procedures. For a particular customer’s installation of the ERP system, it goes through two completely distinct acceptance processes. First, the product owner at the configurable product vendor defines the goals of the next release by synthesizing new feature ideas from the product definition team, bug reports from previous releases and new feature requests from new and existing customers. This gets turned into the functional (MMF) and non-functional (MQR) requirements for the release. The ERP product is built, goes through readiness assessment by the product development team, acceptance testing by the product management team and professional testers before being declared “ready to ship” to customers.Meanwhile, the customers are defining their own goals and objectives for the installation based on the expected feature set of the new release and their specific business context. Each customer should have its own product owner for the customized product. They may do business process modelling and gap analysis between their business process and the “out-of-the-box” product to define their own MMF and MQR. When the product ships, their own product dvelopment team installs it into their own development system and does the customization and/or configuration. If this is their first installation of the product then they adjust the various configuration parameters and implement new plug-in procedures. If this is an upgrade from a previous version of the ERP system then much of the work consists of reapplying the configuration from their previous system and doing regression testing of the functionality. In both cases, the release candidate(s) should traverse the full acceptance process with the customer’s product development team making the Readiness Decision and the customer’s product owner making the acceptance decision which is based on the MMF and MQR defined by the customer’s product owner for their specific installation of the ERP system, not the MMF and MQR defined by the vendor’s product owner for the generic product. In an interesting paradox, ERP systems would seem to be imminently suitable to agile customization and incremental acceptance testing because they work right out of the box and customization evolves the product from a generic one to a customized one. But many ERP systems lack the tools to automate the build and regression testing. See the sidebar “What it takes to do Incremental Acceptance” and the papers [MeszarosOnAgileERP] and [AstonOnAgileERP] for more information on what needs to be available and might be missing in your ERP system.

Exit vs. Entry Criteria

Many of the decisions in the acceptance process involve handoffs between parties. Each handoff involves two sets of criteria. The party making the handoff may have some exit criteria that must be satisfied before they are prepared to make the handoff. The party receiving the handoff may have some criteria to be satisfied before they are prepared to receive the handoff. These criteria can be assessed at separate exit and entry decisions as illustrated in Figure 17 – Separate Exit vs. Entry Decisions & Criteria.
Figure 17
Figure 17 Separate Exit and Entry Decisions and Criteria
This effectively results in a situation where there is no “no man’s land” between the Build and Accept phases as shown in Figure 18:
Figure 18
Figure 18 Acceptance Process with Separate Exit/Entry Criteria for Acceptance
When the Product Development Team and product owner parties have a good working relationship they should be able to agree upon a single set of criteria that satisfies both their needs and have a single decision point based on the agreed upon set of criteria as illustrated in Figure 19 – Single Decision Point with Combined Exit and Entry Criteria.
Figure 19
Figure 19 Single Decision with Combined Exit and Entry Criteria
The two parties would agree on which party does the assessment for each criterion and who makes the decision based on the assessment. Typically it is the party doing the handoff that will do the assessment and the receiving party may be interested in seeing the results.
The main entry criterion for the acceptance phase is that the Product Development Team has deemed the software ready for acceptance testing. Secondary criteria may include whether the Product Owner is sufficiently prepared to conduct the acceptance testing. The decision to enter the acceptance phase should take all the criteria into account.
For example, a Product Development Team’s Readiness Decision should be made based on a combination of:
  • Entry criteria for acceptance testing provided by the Product Owner including:
  • All features in MMF functional with no known severity 1 & 2 bugs open.
  • Stress tested at 110% of rated capacity for 48 hours with less than 1 failed transaction per 1000.
  • Regression test of previous release features executed with 100% pass rate.
  • Exit criteria for construction provided by the Product Development Team such as:
  • 90% code coverage by unit tests.
  • Data architecture reviewed and approved.
  • Static analysis has identified no deficiencies.
  • Security review completed with no high priority issues open.

In practice it is highly preferable for the readiness criteria to include all the Product Owner’s acceptance criteria. This avoids finding bugs during the acceptance testing phase.
Sidebar: Representing the Acceptance Process with Stages and Gates Many companies employ a process involving stages and gates to manage their product development pipeline. These processes were described in section 1.X (Processes with Stages and Gates). The gates serve as decision points between stages. The main goal is to manage the allocation of resources (funding being the most common) among and within projects. The gates at the exit of stages typically involve go/no-go decisions with the go decisions leading to progressively larger ed resource commitments and in the subsequent stages.A typical sequential Stage-GateTM process starts with a new idea evaluated at an initial gate to decide whether the idea is worth pursuing. A sample process is illustrated in Figure S-0.At the idea stage usually a fixed amount of resources are allocated to the product to develop the idea further and build a business case in the next stage. The next gate determines whether the idea warrants advancing to full-scale development. If so, resources are assigned for developing the product; if not, the project is killed. The next gate typically involves deciding whether development of the product is complete. If so, the product enters the testing and validation stage; if not, it may stay in development until it runs out of resources, in which case the project may revert back to the previous stage to determine whether additional resources would be warranted. The exit gate of the testing and validation determines whether the product is ready for launch, that is to be sold or used.
Figure S-0
A sample Stage-Gate Process(TM) [source: is fairly typical]
Many software development processes can be cast in terms of stages and gates. The Rational Unified Process [KruchtenOnRUP] describes 4 phases -- Inception, Elaboration, Construction, Transition. Each phase has an associated milestone. The emphasis within a phase is placed on a specific set of activities, but the process does not preclude performing other activities outside that core. Thus the phases can be viewed as stages in which many kinds of activities take place and the same activities may be repeated or iterated across many different stages. The milestones at the end of each phase could be treated as gates.Agile software development processes may also be cast in terms of stages and gates, but with a different spin to capture their iterative and incremental nature. When an iterative and incremental process is unwound, it can still be viewed as a stream of gates and stages, with funding incrementally allocated at release ends. This can especially be very effective if high-value features are deployed in early releases so that the project starts generating value as soon as possible and can become partially self-sustaining [DenneHuangOnSoftwareByNumbers]. In this variation, rather than stages having distinct purposes and gates having different types of decisions, the stages, activities within stages, and gates are replicated. Each stage-gate pair represents an iteration for implementing the next set of features to be developed, together with a continuation or funding decision. The gates are used to approve additional funds for the next iteration based on what was learned in previous iterations [HighsmithOnAgileProjectManagement, ErdogmusOnEconomicsOfAgile]. (This is an instance of the application of the principles discussed in the Chapter 1 Sidebar Recasting a Sequential Processes through Workflow-Schedule Independence and Parallelization.)We reorganize part of Stage3, Gate 4, Stage 4, and Gate 5, into a custom process for software products: the Acceptance Process. While it could be argued that Gate 4,Go To Testing, assumes the Product Development Team has in fact tested the software extensively, in most organizations the majority of testing occurs in Stage 4, Testing and Validation. We propose that much of thetesting activity below the level of business, user, or customer requirements of the product be pushed back into Stage 3, Development, and become part of the readiness assessment activity within that stage. This effectively makes the readiness decision part of Gate 4, Go to Testing, and leaves Stage 4 focussed on customer or user acceptance testing. Then Gate 5, Go to Launch, would represent the Acceptance decision. The variations on who makes which decision and when are described in Chapter 3 – The Decision Making Model.How is the Acceptance Process for releasecandidatesof a product expressed in terms of stages and gates and how does the result relate to the typical Stage-Gate processTM? We relax the normal requirement of having a gate between each pair of subsequent stages and separate the preparation for a decision associated with a gate into a distinct stage that immediately preceeds the gate. We also allow stages to be nested to have inner stages and gates. Figure S-1 – The Acceptance Process as Nested Stages and Gates illustrates this through an example. The stages Build, Accept , and Use in Figure S-0 correspond to the stages Development, Validation and Testing, and Launch in Figure 0. it.
Figure S-1
The Acceptance Process as Nested Stages and Gates
Inside the Build stage on the top, Build 1 is the first release candidate that development asks their readiness assessors to evaluate. It has several severity 1 bugs that must be fixed and is missing some key features. Development fixes these bugs and adds the missing functionality. After several more tries, Build N finally makes it all the way through Readiness Assessment and is released to the product owner for acceptance testingA positive readiness decision inside the Build stage automatically satisfies the criteria for Gate 4 therefore the project enters into the Accept stage. The product owner conducts acceptance testing only to discover some key issues. These are provided to the Product Development Team who addresses them in Build N1 after several intermediate builds (not shown) that fail their readiness assessment. Note that at this point the project is still considered to be in the Accept stage despite the fact that the ball is in The Product Development’s court to fix the bugs.The product owner finds no significant issues with this build and accepts the software as finished, satisfying Gate 5’s criteria.The project now moves to the Use stage. After a few weeks of usage, a user experiences a severe crash that is traced back to a missed scenario. The product owner asks the Product Development Team for a fix. Development comes up with a fix in Build N2, which passes readiness assessment and acceptance testing (mostly regression testing plus a new test case covering this bug) and Build E is put into production. The project stays in the Use stage (often referred to as “Warranty”) until the criteria to exit the Use stage are met; this may be decided by the passage of an agreed-upon period of time during which the product is covered under The Product Devleopment Team’s warranty.At the end of the Build stage and during the Accept stage, each release candidate is assessed for whether it satisfies functional and non-functional criteria. However typically, the transitions from the Build stage to the Accept and Use stages involve also business and political factors that may have little to do with whether the software meets the functional and non-functional requirements (See Chapter X – System Requirements Model). Examples of such factors include:•A need to free up the product development team for other work•Changing who pays for modifications:before acceptance it is usually the product development team while after acceptance it is typically the product owner.•Changing the funding source from capital to expense.•Management pressure to shortcut a gate due to a misalignment of project goals with incentives. While these factors may play a critical role in gate decisions, they are outside the scope of this guide.
Sidebar: Quality Gates and the Acceptance Process. (Microsoft Quality Gates examples as MMF/MQR criteria for readiness and acceptance decisions.)<TBA>


This chapter introduces the concept of the acceptance process as a way to think about the activities related to making the decision to accept software. The acceptance decision is the culmination of a process that involves several organizations each with specific responsibilities. Each release candidate is passed through the decision points of the acceptance process on its way to the making the final acceptance decision. There are three major decision points between software construction by the Product Development Team working with their Product Owner and software usage by the end user. First, the Product Development Team must decide whether the software-intensive product in its current form, known as the release candidate, is ready for acceptance testing. If it is, the Product Owner must decide whether the release candidate meets their acceptance criteria before the product can be made available to the end users. Ultimately, each end user must decide for themselves whether they want to use the software. This usage decision has very little influence on the current acceptance decision although it may influence the acceptance criteria for future releases of the product.
While each user potentially makes their own usage decision, the readiness and acceptance decisions are normally each a single decision. Each decision point or "gate" should have well-defined criteria to guide the decision making. These criteria should be known in advance by both the Product Development Team and the product owner. Complex organizations may have several readiness or acceptance decisions being made in parallel, each based on their own criteria (for example, operational acceptance); the release candidate’s progression through the process may be vetoed by failing to satisfy the criteria of any of the parallel decisions. Complex products may require multiple Product Development Team teams each with their own readiness, and potentially acceptance decisions prior to an overall readiness and acceptance decision for the integrated product; the release candidate can be sent back for further work from any of the decision points.
The acceptance described in this chapter applies to both sequential and agile projects but in slightly different ways. The phased nature of sequential projects means that all testing is done within a separate testing phase and the acceptance process describes what goes on within that phase. Agile projects traverse the entire development lifecycle for each feature or user story. Therefore, the acceptance process is executed at several levels of granularity with the finest grain execution being at the individual feature level and the largest being at the whole product (or feature integration) level.

What’s Next?

In Chapter 3 – Decision Making Model we examine the roles and responsibilities of the various parties involved in making the decisions which make up the acceptance process. We also describe the roles played by the parties who provide the data on which the decisions are based.


[BasLarmanOnScalingAgile] Vodde, Bas. and Larman, Craig "Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”, Addison-Wesley Professional, Agile Software Development Series series., 2008
[HighsmithOnAgileProjectManagement] Highsmith, Jim “Agile Project Management: Creating Innovative Products”, AWP 2004 ISBN-13: 978-0321219770
[MeszarosOnAgileERP] Meszaros, Gerard, et al “Agile ERP - You Don’t Know What You’ve Got ‘Till its Gone”,
[AstonOnAgileERP] Aston, Janice, et al “Agile ERP – Overcoming the Challenges”,
[EcksteinonLargeScaleAgile] Jutta Eckstein, "Agile Software Development in the Large: Diving Into the Deep", Dorset House, 2004
[ErdogmusOnEconomicsOfAgile] Hakan Erdogmus, “The Economic Impact of Learning and Flexibility on Process Decisions”, IEEE Software, Vol 22, No 6 (Nov. 2005), pp. 76-83
[DenneHuangOnSoftwareByNumbers] Mark Denne and Jane Cleland-Huang, "Software by Numbers: Low-Risk, High-Return Development", Prentice-Hall, 2003
[KruchtenOnRUP] Philippe Kruchten, "The Rational Unified Process: An Introduction", Addison-Wesley, 2003
[MillerKarterOnLargeScaleAgile] Ade Miller and Eric Carter, “Agile and the Inconceivably Large”, Proc. Agile 2007, IEEE Press, 2007

Last edited Nov 5, 2009 at 6:48 PM by rburte, version 3


No comments yet.