Microsoft Solution for Supplier
Enablement
Services Guide
Microsoft Corporation
Service Release 1, May 2002
Applies to:
Microsoft Solution for Supplier
Enablement
Microsoft Commerce Server 2002
Microsoft
BizTalk Server 2002
Summary: Learn about the four phases of a services
engagement for the Microsoft Solution for Supplier Enablement (MSSE).
Contents
Introduction
Vision/Scope
Planning
Development
Stabilization/Release
URL Resources
Introduction
This Services Guide for the Microsoft® Solution for Supplier Enablement
(MSSE) discusses the four phases of a services engagement for this
solution and provides guidance for the successful completion of each
phase. The four phases are:
- Phase 1: Vision / Scope
- Phase 2: Planning
- Phase 3: Development
- Phase 4: Stabilization / Release
Reader Guidance
Anyone reading this guide should also read the product documentation
for Microsoft BizTalk® Accelerator for Suppliers Service Release 1 (AFS),
Microsoft BizTalk Server, and Microsoft Commerce Server, each of which
contains specific and detailed information about the corresponding
products. Additionally, readers should review the other Microsoft Solution
for Supplier Enablement guides.
Vision/Scope
You use the vision/scope phase of a typical service engagement for the
MSSE to scope out the following issues:
- Project size
- Business factors driving the project
- Complete assessment of the current situation of the customer
- Determination of the high-level decision-making criteria for the
project deliverables
- High-level milestones for the project
The primary deliverable for the vision/scope phase is a vision/scope
document that has been approved by all relevant parties. This document,
when properly written according to Microsoft Solutions Framework (MSF)
principles, serves as the main source of the statement-of-work provided by
the solution implementers. Although this document may refer to other
documents for specific information and measurements, it should contain
enough detail for all team members to understand the vision and scope of
the project.
The vision/scope document should bear the signature of all the lead
stakeholders of the project, in approval and acceptance of its contents.
It should be backed up by other documents containing more specific
information and measurements, but it should provide a good basis for all
team members to gain a clear understanding of the project parameters.
Completion and approval of the vision/scope document and any related
documents constitute completion of the vision-approved
milestone.
For a comprehensive introduction to the MSF, see the "Microsoft
Solutions Framework Overview" white paper, which can be found at http://www.microsoft.com/business/services/mcsmsf.asp.
The remainder of this section provides details about the various
sections that should be included in a vision/scope document, and provides
a collection of questions that are useful in determining the vision for,
and scope of, an MSSE project.
The Vision / Scope Document
The vision/scope document is the primary deliverable of the
vision/scope phase of an MSSE project. As defined by the Microsoft
Solutions Framework (MSF), the vision/scope document should contain the
following sections:
- Executive Summary
- Opportunity / Problem Statement
- Business Benefits
- Vision Statement
- Decision-Making Criteria
- User Profiles
- Solution Concept
- Usage Scenarios
- Project Team
- Critical Success Factors
- Risk Management
- Initial Project Schedule
The remainder of this section discusses the expected content of these
sections, as they apply to the MSSE.
Executive Summary
This section should contain a brief but comprehensive summary of the
various factors that lead to undertaking the MSSE project, including the
business motivation and objectives, the features to be implemented, the
project timeline, and the anticipated outcome.
Opportunity / Problem Statement
This section should contain a complete description of the problems this
MSSE project is trying to solve, or the opportunities this MSSE project
intends to address. The information in this section will drive many of the
decisions made in the planning phase of the project.
In the realm of supplier enablement, likely candidates for these
problems and/or opportunities are the following:
- Major buyers moving to electronic procurement over the Internet
- Protecting the current set of buyers from eroding due to their moves
toward electronic procurement
- An opportunity exists to increase business with existing buyers
through early adoption of supplier enablement
- Reducing expenses by increasing the efficiency of the sales cycle
- Deepening relationship with existing buyers by providing additional
ways to interact
- Acquiring multiple new customers with one technology investment
Although the implementation of the MSSE may address other problems and
opportunities, those listed above are likely to be common to many supplier
enablement scenarios.
Business Benefits
This section should list the anticipated business benefits that the
completion of this project will yield. These benefits should correspond to
the problems and/or opportunities stated in the previous section.
Articulation of the project benefits will help drive the acceptance tests
that will be written in the planning and development phases.
In a services engagement, a clear statement of the business benefits is
very important, because it helps to establish a clear set of exit criteria
for the project.
Vision Statement
This section should state the project vision. This section provides the
project team and the customer with a common understanding of what the
project will achieve, and helps to:
- Establish an agreement with the customer about the goal(s) of the
project
- Establish the decision-making criteria for the project
- Make project trade-offs
Decision-Making Criteria
This section should address the three standard, potentially
conflicting, factors of any project: ship date, resources, and features.
Constraining more than one of these factors results in a much greater
chance that the project will not succeed in all respects.
Part of the process of determining the vision and scope of a project is
determining in advance the relative priorities of the three factors being
discussed here. For example, if the ship date is critical, features may
need to be cut to a minimum, and more resources applied; or it might be
sufficient to trim features, or to add resources, but not both.
Alternatively, if resources are limited, and features are already
minimized, the ship date may be the only variable factor.
In any event, this section of the vision/scope document should provide
information about the relative importance of the ship date, resources, and
features for the MSSE project.
User Profiles
This section should describe the roles of the various users of the
MSSE, focusing primarily on those users within the supplier organization.
Depending on the supplier, the number of unique types of users will vary,
and consequently the number of different types of tasks performed by any
one user will also vary. For example, is the organization large enough so
that two different groups of people handle catalog publication and order
processing? Or does one group handle both tasks?
Although the buyer and the trading partner also represent distinct user
roles in the overall scenario, you do not need to consider these users in
this section. They are outside the realm of the supplier, which this
solution addresses.
Solution Concept
This section should outline the solution approach and architecture at a
high level. The outline should contain sufficient information to begin the
planning phase. The outline should consider the following aspects of the
solution:
- Required hardware
- Required software
- Integration with existing systems
- Performance requirements
This section should not be too detailed, and should not attempt to take
the place of the functional specification that is delivered in the
planning phase.
In practice, this section can be constructed from various sections of
the MSSE Architecture Guide and the MSSE Deployment Guide
including those sections that are relevant to the solution being
developed.
Usage Scenarios
This section should describe the basic scenarios in which the MSSE will
be used. This should correspond to the roles defined in the User Profile
section, and should be divided according to the three basic areas of
functionality: catalog publishing, remote shopping, and purchase order
reception.
For example, with regard to catalog publishing, the following types of
issues should be considered:
- From where did the catalog data originate? Was it imported into the
Commerce Server Product Catalog System or was it entered manually in the
Commerce Server Product Catalog System using Commerce Server Business
Desk?
- After the catalog data is in the Commerce Server Product Catalog
System, will it be maintained there? Or will it be maintained elsewhere
and periodically imported into Commerce Server?
- How often will new versions of the catalog be published?
- Will individual products in the catalog be available for remote
shopping?
Project Team
This section should identify the roles on the project team and their
corresponding responsibilities. It should also discuss issues related to
team interaction, such as the frequency of various meetings and the
combination of attendees at those meetings, how common team documents and
other project information will be maintained, and so on.
The MSF team model defines a set of roles and corresponding
responsibilities that have been found to be a constructive way to organize
a project team. Although the names of various roles and precisely how the
various responsibilities are distributed may vary in different
organizations, the different responsibilities described should be
attributed to a role. Further, some responsibilities tend to conflict with
each other and are better distributed to unique roles. For example, a
person who develops a particular software product should not be the same
person who tests that product.
The various project roles defined by the MSF are described below.
Product Management
The goal of the product management role is satisfied customers. Product
management team members engage in the following types of activities:
- Act as a customer advocate
- Drive the project vision and scope
- Work with customers to define and maintain requirements
- Develop and refine the business case for the project
- Manage customer expectations
- Drive feature versus schedule decisions
- Manage marketing and public relations
- Act as product evangelist
Program Management
The goal of the program management role is to deliver the project
within the defined constraints. Program management team members engage in
the following types of activities:
- Drive the development process
- Manage the product specification
- Facilitate communication and negotiation within the team
- Maintain the project schedule
- Report project status
- Drive high-level trade-off decisions
Development
The goal of the development role is to build the solution as specified.
Development team members engage in the following types of activities:
- Specify the features of the physical design and options
- Estimate time and effort to complete each feature
- Build the features
- Prepare the solution for deployment
Logistics Management
The goal of the logistics management role is to ensure smooth rollout
of a manageable and supportable product. Logistics management team members
engage in the following types of activities:
- Act as an advocate for operations, support, and delivery channels
- Manage procurement
- Manage product deployment
- Drive manageability and supportability trade-off decisions
- Manage operations, support, and delivery channel relationships
User Education
The goal of the user education role is to enhance user performance and
reduce support costs. User education team members engage in the following
types of activities:
- Act as an end-user advocate on the team
- Define user requirements
- Design and develop performance support systems
- Drive usability and user performance enhancement trade-off decisions
Test Management
The goal of the test management role is to ensure a high-quality
product. Test management team members engage in the following types of
activities:
- Ensure all issues are known
- Develop testing strategy and plans
- Manage test execution and the reporting of results
Critical Success Factors
This section should identify the key factors that will influence the
success of the project. The identified factors may be those that have
either a positive or a negative impact on the project. Relevant factors
may include people, processes, technology, management, and competition.
They may be internal or external to the supplier for whom the solution is
being built.
The factors identified in this section are important because they help
determine when the project is successfully completed. Reaching a common
understanding with the customer about such issues at an early stage in the
project definitely contributes to a harmonious project conclusion.
Risk Management
This section should establish a common understanding between you and
your customers about risk management and risk management procedures. All
projects have risks that can hinder the critical success factors of the
project. To minimize the impact of these risks, they must be identified as
early as possible so that mitigating plans can be developed.
Educating the customer about risks that can affect the success of the
project is an important discipline to develop and foster. Often, these
risks are outside the control of the project team, such that they cannot
be avoided even with excellent planning.
These risks must be identified and brought to the attention of the
customer as early as possible. And since new risks can arise during the
course of the project, risk management must be ongoing through the life of
the project.
There are a wide variety of possible risks to a project. The following
list identifies a number of common types of risks that should be
considered, grouped into schedule risks, resource risks, and scope
risks.
Schedule Risks
- Tasks that are exceptionally complicated
- Tasks with a duration longer than two weeks
- Tasks on the critical path
- Tasks that have several predecessor tasks
- Tasks with overly optimistic time estimates
- Tasks that depend on external groups
- Start-to-start and finish-to-finish dependencies
- Dependencies with lags
- Major milestones
- Unforeseen issues (for example, reorganizations and office moves)
- Unstated assumptions
Resource Risks
- Tasks with one key individual assigned
- Tasks using scarce resources
- Tasks for which the resource are mismatched
- Tasks that require a large number of resources
- Unavailability of appropriate tools
- Tasks which rely on third-party vendors for their completion
- Tasks which rely on resources within another group for their
completion
Scope Risks
- Uncertainty of new technology
- Changing customer requirements
- Tasks with significant business impact
- Overly aggressive performance requirements
The following techniques can be helpful in mitigating many of the risks
identified above:
- Add resources to tasks for cross-training
- Establish independent parallel efforts
- Schedule high-risk tasks earlier in the development phase
- Reduce project scope
- Add review tasks
- Shift more experienced people to difficult tasks
- Intentionally design redundancy into the solution
- Change the approach to eliminate high risk tasks
- Add prototyping tasks to prove concepts
With respect to the MSSE, a particular class of solution-specific risks
need to be considered and identified as early as possible. These include:
- Overall quality of the implementation by the trading partner(s)
- Varying interpretations of XML standards
- Degree of implementation of XML standards
- Degree of error handling implemented by the trading partner(s)
- Network reliability
- Anticipated catalog and purchase order sizes
- File size limitations
- Details of existing supplier infrastructure
A variety of risk management techniques and information are part of MSF
and can be found on the Microsoft Solutions Framework site at http://www.microsoft.com/business/services/mcsmsf.asp.
Initial Project Schedule
This section should provide an initial project schedule. Whether or not
the initial project schedule is realistic, given the features to be
included and the resources to be engaged, will be determined as the
schedule is refined during the planning phase. In any event, it should be
possible to establish solid milestones, if not their associated dates, in
the initial project schedule.
The following table shows an example of an initial project schedule for
a typical MSSE project.
Project Phase |
Milestone |
Description |
Vision / Scope |
1 |
Vision/scope approved |
Planning |
2 |
Project plan approved |
Development |
3 |
Supplier catalog architecture complete
and tested |
Development |
4 |
Catalog publication to all trading
partners complete and tested |
Development |
5 |
Order reception from all trading partners
complete and tested |
Development |
6 |
Remote shopping implementation for all
trading partners complete and tested |
Development |
7 |
Code complete |
Stabilization / Release |
8 |
Zero bug bounce (ZBB) |
Stabilization / Release |
9 |
Final code deployed into
production |
Note An operations
representative, probably working through the logistic management team,
should be involved in the vision/scope phase of the project. Experience
suggests that when this is not done, significant delays in the
successful deployment into a production environment are common. For more
information, see the MSSE Operations Guide.
Project Assessment Questions
One of the keys to success in the vision/scope phase of an MSSE project
involves figuring out the right questions to ask, and then getting the
answers to those questions. This process helps formulate the correct
vision for the project and leads to an accurate assessment of the scope of
the project.
The purpose of this section is to provide you with some of these
questions. They are divided into several different categories.
Assessment of Existing Infrastructure
- Does the supplier have a Web site? Do they already sell their
products on the Web site? What operating system and Web server platform
do they use for the Web site?
- Does the company already have a product catalog? Do they have
multiple product catalogs? If so, what format is the catalog data in?
How is the catalog organized?
- Are any of the products configurable?
- Does the supplier have a corporate discount strategy?
- Does the company operate a warehouse?
- Does the company use an ERP system? Multiple ERP systems?
- Does the company have subsidiaries with which it must interact? If
yes, how diverse is the geographical base?
- Does the supplier have a Private Key infrastructure (PKI)? If yes,
using what platform?
Assessment of Existing Business Processes
- Who is in charge of the product offerings? What is the flow of
information from creation to publication?
- How does the supplier take orders today?
- What needs to happen before the supplier can ship the order?
- Does the company have to buy any products on-demand from other
suppliers?
- How does the company ship products to customers? What geographies
are covered?
- How is inventory controlled? What are the replenishment policies?
- What kind of authorization is needed on special orders and new
customers? Is the authorization based on quantity or on total cost, or
both?
Assessment of Trading Partners
- Who are the relevant trading partners and what business document
standards do they support?
- What business documents do the trading partners expect to exchange?
- Does each trading partner have any special business processes?
- Which trading partners are suppliers and which trading partners are
buyers? Are some both suppliers and buyers?
- For trading partners that are buyers, are the catalogs published to
them customized in any way?
- How many purchase orders per day are being processed from these
trading partners? What percentage of those purchase orders are being
migrated to the solution that is being considered?
- How sensitive is the information to be exchanged by the proposed
solution?
Assessment of Planned Market Differentiators
- Are there any specific ways in which the supplier wants to
differentiate itself from its competitors? For example, using
personalization, auto-replenishment, and so on.
Planning
The deliverables of the planning phase are as follows:
- Functional specification. Describes the solution to be built
and includes the solution design goals, requirements, features, and
dependencies.
- Master project plan. Describes how the solution will be
built.
- Master project schedule. Describes when and in what order the
solution will be built.
The planning phase ends with the project plan approved
milestone, which signals approval to build the solution.
Planning Phase Tasks by Role
The following tasks, listed by role, are performed during the planning
phase.
Program Manager
- Own and drive the schedule, including rolling individual schedules
into a master schedule.
- Own the project feature set, and communicate this through the
functional specification.
- Own the budget for the project.
- Own progress reporting.
- Coordinate resources.
- Facilitate team communication.
- Drive critical decisions and make trade-offs based on project
constraints.
Product Manager
Development Lead
- Lead the development team in building the prototype.
- Ensure that the prototype, as built, meets customer expectations.
- Build the prototype to drive the functional specification.
- Serve as the technology expert.
- Contribute to high-level designs.
- Evaluate alternative technologies.
- Develop proof-of-concept prototypes.
- Mitigate development risks early.
Test Lead
- Lead test team in ensuring product quality.
- Ensure that all issues are known and addressed prior to project
completion. Issues include flaws in the code and documentation, and
deviations from the functional specification.
- Develop comprehensive test strategies, plans, and schedules.
User Education Lead
- Act as the advocate for the end user.
- Help ensure product usefulness.
- Ensure product usability.
Logistics Manager
- Act as the advocate for operations and product support.
- Help ensure a deployable product.
- Help ensure a manageable product.
- Help ensure a supportable product.
- Understand the product infrastructure and support requirements.
- Develop installation and support plans.
Determining the Project Size
This difficult task is important because an accurate estimate is
required to properly determine the project budget, schedule, and resource
requirements. To accomplish this task you need to determine the required
functionality of the product and compare that to the functionality
provided by the MSSE. This functionality includes both the out-of-the-box
functionality provided by Microsoft BizTalk Accelerator for Suppliers
(AFS) Service Release 1 and the functionality enhancements discussed in
the associated documentation.
It is important to have a thorough understanding of the AFS
architecture in order to be able to determine the size of an MSSE project.
Refer to the MSSE Architecture Guide or to the AFS online help for
this information.
Determining the answers to the questions in the following sections is
critical to properly estimate the size of the MSSE project.
General Questions
Message Standard Selection Questions
- What standard(s) are current trading partners using?
Out-of-the-box, AFS supports the cXML 1.1, cXML 1.2, SAP XML, and
xCBL 3.0 standards. These message standards are widely used and have a
horizontal market focus. Since several key messages in these standards
are already implemented and tested, they should be employed wherever
possible.
Since AFS is based on BizTalk Server, you can add support for
whatever messaging standard you may need. This could include vertical
industry standards like RosettatNet (http://www.rosettanet.org/) and
HIPAA (http://cms.hhs.gov/hipaa/), or an
older and more established standard such as EDIFACT.
- What standard(s) are future trading partners likely to use?
- What are the characteristics of the standards you are considering,
and how well do they match your needs?
- How broad is the market coverage of the standard? The cXML standard
is widely used, and is the standard used by Ariba and Clarus. The xCBL
standard is used by CommerceOne.
- Does the standard support all the message types that your customer
requires? For example, does it support advance shipping notices or
invoices? The xCBL standard is considerably more complete than the cXML
standard in this regard. The xCBL standard is based on EDI, which is
apparent not only by its relative degree of completeness, but also by
its relative complexity.
- Do the messages in the standard(s) you are considering contain all
the required information, such as detailed buyer, payment, and shipping
information? Again, the xCBL standard is more complete than the cXML
standard.
- For standards not based on XML, can your system and infrastructure
support the standard?
- For standards other than xCBL and cXML, does the standard authoring
organization provide good documentation and support? Will they provide
for validation and testing of your implementation? Do they enforce the
standard? Do they continue to improve it?
Both the xCBL and cXML standards are evolving and are well-supported
by their parent organizations.
- Do you have access to the other application you will be trading
with, such as a procurement application? If not, is a testing and
validation service available? This can be a major problem and it should
not be underestimated. Plan to begin testing early, and get a written
commitment from the other organizations. Allow for plenty of testing
time in your schedule, as you may not have control of the other half of
the testing equation.
Business Process Questions
- Will you use Commerce Server as your catalog system? If yes, the
development effort will be greatly reduced as AFS has already
implemented this for you. Alternative implementations may use an
existing catalog from an ERP or similar system.
- If you are using Commerce Server, is the basic content management
functionality it provides adequate for your needs? Will you need to use
a more sophisticated content management system such as Microsoft Content
Management Server?
- If you will use another system for your catalog, how much effort
will be required to integrate it with AFS? You will need to change all
the catalog-related BizTalk maps and source document specifications.
- If you intend to import catalogs into Commerce Server, they must be
in either XML or CSV format. How will you get your catalog data into the
right format? Many implementations use Microsoft Excel to generate a CSV
file, or a combination of SQL and XSLT to extract a catalog from a
database and transform it into the proper format.
- If your content is maintained somewhere else, should you implement
an automated catalog import system?
- Do you need to support electronic catalog publishing? In most cases,
the answer is yes. But there are some remote shopping scenarios where
only a description of the catalog and the remote shopping URL are sent
to the trading partner.
- Do you need to support remote shopping? It will require more effort
to implement, but it does offer the following potential advantages:
- Supplier branding
- Personalized shopping pages
- Up-sell and cross-sell capabilities
- Tracking detailed buyer information
- Custom and dynamic pricing
- Provides the buyer with more detailed information
- Provides custom configuration of complex products
- Reduces the size of the catalogs uploaded to the trading partner
- If you are going to include remote shopping functionality, how will
the remote shopping functionality in AFS be used? The answer depends on
the nature of the Web site already in use by the supplier, if any.
If the supplier is already using an e-commerce Web site based on
either the Retail or Supplier Solution Site, integrating remote shopping
functionality from the AFS Solution Site should be straightforward.
If the supplier does not yet have an e-commerce Web site, or wants to
start from scratch in creating one, the AFS Solution Site should be used
as the starting point.
If the supplier has an e-commerce Web site that is not based on a
Commerce Server Solution Site, integrating remote shopping functionality
will not be as easy. You will need to study the remote shopping code
that was added to the Solution Site code base, and then make similar
additions to the existing Web site.
- Do you need to support the reception of electronic purchase orders?
In most cases, the answer is yes. AFS supports purchase order reception
via HTTP post operations, and then uses BizTalk Server to convert these
purchase orders to the native Commerce Server XML format for further
processing.
- Do you need to support the reception of purchase orders using a
transport mechanism other than HTTP, such as FTP, SMTP, or Message
Queue?
- If you intend to integrate purchase order reception with existing
business systems, you will need to decide whether to integrate with
BizTalk orchestration or with Commerce Server pipelines, as both offer
reasonable integration points.
- Because AFS does not handle shipping or invoicing of received
orders, you must implement a custom solution for this functionality or
integrate with existing systems that can handle these processes.
- Which type of purchase order acknowledgement is expected by the
relevant trading partners? AFS uses different solutions for the xCBL and
cXML standards, and your needs may vary.
Implementation Cost and Time
Based on the answers to the previous questions, you can now perform a
cost and time analysis. In the course of this task, consider the
following:
- Does the cost or time of implementation make any of these standards
prohibitive to implement?
- Can you postpone one or more implementations to a future version?
- Should you start by implementing one standard first, and then
benefit from the experienced gained when implementing subsequent
standards?
Identifying and Managing Risk
There are a number of different types of risks associated with an MSSE
project, particularly when it involves multiple trading partners using
heterogeneous systems. You need to identify, analyze, plan for, track, and
control such risks. The relevant risks can be categorized as follows, and
characterized by the questions associated with each category:
- Technical risks. Do you have a good understanding of the new
technologies being used? Have you prototyped and tested all the
technical unknowns?
- Integration risks. Do your trading partners have
well-documented interfaces and protocols? Will they provide technical
and validation support? Will they be responsive to your questions and
needs? This is a significant risk, and one that is difficult to manage
because you are dependent on another organization. Allow plenty of time
in your schedule to mitigate this risk factor.
- Security risks. Have you considered all the data and
infrastructure security measures that will be required to adequately
protect the customer? Are there any questionable areas that require
specific proof-of-concept testing or analysis by a third-party security
expert?
- Schedule risks. Is the delivery date inflexible? Do you
adequately understand the development effort required? Can you adjust
the scope or resources if you cannot adjust the schedule? The effort
required for integration with other organizations and applications is
difficult to gauge accurately, so be conservative with these aspects of
the project schedule. Also, be careful to not underestimate the learning
curve required by technologies such as Commerce Server, BizTalk Server,
cXML, xCBL, and so on. In particular, learning and understanding a new
XML standard can be quite challenging.
- Budget risks. Is there sufficient funding to bring this
project to completion? Is the budget so tight that any unexpected
problems or delays will put the project in jeopardy?
- Business risks. Is this project crucial to the survival of
the organization? If so, does it have the appropriate level of support
from all interested parties? Would a failure of this project put the
organization at risk? Would a poor implementation put the organization
and its reputation at risk?
All of these risks can be managed, but the more risks that exist, the
more risk management effort is required. On the other hand, not managing
them will likely end up costing more. To help you identify all of the
above risks, you should leverage the test team during the planning phase.
They should be well versed in risk analysis and management techniques. You
should also make sure that the risks are well understood by all relevant
parties, and try to ensure that those parties will constructively
participate in solving problems associated with risks that have
occurred.
Development
The deliverables of the development phase are as follows:
- Frozen functional specification. At the end of this phase,
the functional specification should be frozen and synchronized with the
implementation and the final test plan.
- Risk management plan. The risk management plan should be
updated with the latest information and data. Some items may justify a
higher priority in testing.
- Source code and executables. The source code and executables
should be in a source code database, such as Microsoft® Visual
SourceSafe®, from which it can be installed by the test team on a clean
server or set of servers.
- Test specification and test cases. The test plan should be
completed and reviewed before the test passes begins.
- Master project plan and master project schedule. These two
documents should be updated with the latest data and they should be
distributed to key project personnel.
The developing phase ends with the scope complete milestone. At
this milestone, all features are complete and the product is ready for
external testing and stabilization. This milestone is the opportunity for
customers, end users, operations and support personnel, and other key
personnel to evaluate the product and identify any remaining issues that
need to be addressed before the product is released.
Development Phase Tasks by Role
The following tasks, organized by role, are performed during the
development phase.
Program Manager
- Continually update the project schedule.
- Manage buffer times in order to meet the fixed-date schedule.
Product Manager
- Create an external release schedule.
- Communicate with the customer.
Development Lead
- Manage the development effort.
- Perform code reviews.
- Help make technical trade-offs and decisions.
Test Lead
- Lead creation of the test plan.
- Lead creation of test tools.
- Train testers on what needs to be tested.
- Manage test creation.
- Organize test case review.
User Education Lead
- Lead creation of product documentation.
Logistics Manager
- Create the deployment plan.
- Do capacity planning.
- Install product infrastructure.
- Implement daily build strategy.
Other Development Considerations
The following considerations are important to the development phase:
- How are you going to use the relevant functionality in Commerce
Server as part of your solution? This functionality includes profiles,
order processing components, database tables, catalog management
functionality, and Commerce Server Business Desk.
- How are you going to use the relevant functionality in BizTalk
Server as part of your solution? This functionality includes document
transformation, transport facilities, and orchestration facilities.
- What is your daily build strategy? How will it incorporate baseline
testing on a daily basis?
- If necessary, how will you develop a way to test your solution
without ongoing access to a test facility maintained by the trading
partner(s)? Can you devise a way to simulate the trading partner(s) so
that you can decouple your ability to make progress from their ability
to support your development efforts?
- In what ways will you need to extend the solution provided by AFS?
AFS includes documentation that explains how to perform such extensions
in the areas of supporting additional messages, extending Commerce
Server analysis and reporting, integrating with back-end systems, and
printing purchase orders.
Stabilization/Release
The deliverables of the stabilization/release phase are as follows:
- Golden release. A code base in which all critical bugs have
been addressed.
- Release notes. An itemized list of known issues and
work-arounds for the current release.
- Test results and testing tools. A summary of test results
and, ideally, the test tools. These test results should include
functionality and performance test results for the major feature areas
while the site is under a load that represents average or peak usage. In
addition to the test results, the test scripts and load generation
scripts should be included in this deliverable. These test results will
serve as a baseline. All future development and configuration updates
should be precluded by running these functionality and performance tests
to ensure that the functionality and performance is maintained or
exceeded. This defines the release criteria that must be met before
releasing the product to production. Performance test results for the
MSSE, which were run while the solution was under stress generated by
the Microsoft Web Application Stress Tool, are included in the MSSE
Architecture Guide. Results of this type of performance testing may
vary depending on the hardware configuration and implementation details
of each MSSE deployment.
- Source code and executables. An installable program that
reflects the debugged source code.
- Project documents. Updated versions of the various project
documents: Vision/Scope, Functional Specification, Project Plan, Risk
Plan, Test Plan, and so on.
- Milestone review. A post-mortem of both the successful and
unsuccessful aspects of the project. This can be a very useful exercise
when done immediately after product release and deployment.
The stabilization/release phase ends with the release milestone.
At this milestone, the team has addressed all outstanding issues and has
either shipped the product or placed it into service.
At the release milestone, responsibility for ongoing management and
support of the product officially transfers from the project team to the
operations and support teams. For information on operational prescriptions
for AFS, see the "MSSE Operations Guide."
Stabilization/Release Phase Tasks by Role
The following tasks, organized by role, are performed during the
stabilization/release phase.
Program Manager
- Drive bug fixing to completion.
- Hand off Release deliverables to Microsoft Product Support Services
to be audited for supportability.
Product Manager
- Manage customer sign-off.
Development Lead
- Lead development team in fixing bugs.
- Resolve technical issues as they occur.
Test Lead
- Drive testing of product.
- Manage bug fix trade-offs, as dictated by the project goals and
trade-off matrix.
- Help determine fixes to be deferred to a future release.
- Determine project completion and sign-off.
User Education Lead
- Lead finalization of all documentation.
Logistics Manager
- Deploy finished product.
- Turn over operations to the operations team.
Live Testing
One of the final aspects of testing an MSSE solution should be "live"
testing with the relevant trading partners. Before opening the solution to
general use, the catalogs should be published to all of the trading
partners, and dummy orders placed through the actual e-procurement
applications that the end users will use.
Microsoft Product Support Services (PSS) Release Audit
Many of the Release deliverables should also be delivered to PSS to be
audited for supportability. Depending on the complexity and customization
of the solution, this may include an on-site visit to review the custom
code and implementation details. The Release Audit deliverables include
the custom code developed, functional specifications, design
specifications and deployment specifications. If significant changes are
made to the solution after release, another PSS Release Audit may be
required. The more informed PSS is about the implementation, the better
equipped they will be at supporting the solution in production.
Release Criteria
Depending on the scope of your MSSE solution, the items in the release
criteria list will vary, but will generally include the live testing of
all implemented functionality and performance criteria. For example,
verifying that a catalog can be published, products can be chosen through
the relevant buyer applications supported by the trading partner(s), and
the corresponding orders can be received and processed. When remote
shopping is implemented, all relevant scenarios must work as expected, and
result in the reception of orders by the supplier.
URL Resources
Microsoft Solutions Framework:
http://www.microsoft.com/business/services/mcsmsf.asp
Microsoft Web Application Stress Tool:
http://homer.rte.microsoft.com/
Microsoft Solution for Supplier Enablement:
http://www.microsoft.com/business/solutions/MSSE/