Directions for using
template:
Read the Guidance
(Arial blue font in brackets) to understand the
information that should be placed in each section of this template. Then delete
the Guidance and replace the placeholder within <<Begin text here>>
with your response. There may be additional Guidance in the Appendix of some
documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
Date |
|
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft
and Visual Basic are either registered trademarks or trademarks of Microsoft in
the
Change
Record
|
Date |
Author |
Version |
Change
Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version
Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document
Properties
|
Item |
Details |
|
Document
Title |
Development
Plan |
|
Author |
|
|
Creation
Date |
|
|
Last
Updated |
|
Development and Build Environment
Component Acquisition and Development
Configuration and Development Management Tools
[Introduction to the
Template
Description:
The Development Plan describes the solution development process used for the
project. This plan compliments the functional specifications that provide the
technical details of what will be built. This plan provides consistent
guidelines and processes to the teams creating the
solution.
Justification:
Documenting a development process indicates that the team has discussed and
concluded on a consistent structure and direction to be used during the
development process. This documentation allows developers to be productively
focused on creating the solution. Development guidelines and standards promote
meaningful communication among the team(s), as they will reference a common
approach and processes. It also facilitates reuse among different groups and
minimizes the dependency upon one individual or group.
{Team
Role Primary: Development; The Development Role manages the process
of creating the development plan. The focus of the Development Role during this
process is to consider how key aspects of the development process should be
undertaken. This may include incorporating existing standards and protocols
(coding standards, architecture references, etc.) that are required by
participating organizations. It may also include establishing trade-off
priorities and budget restrictions.
Team
Role Secondary: Program Management provides
input to the overall delivery strategy, key design goals, and trade-off
approach. As Program Management is responsible for managing the overall solution
design, it must verify that the development plan can meet the goals and
requirements of the entire solution and that key development goals and processes
are captured and prioritized appropriately. Test needs to understand the
development approach and how they will work with the development team. Test will
need details on the daily build process and the order in which components will
be built in order to develop a viable test plan.}]
[Description:
Provide an overall summary of the contents of this document.
Justification:
Some
readers may need to know only the highlights of the plan, and summarizing
creates that user view. It also enables the full reader to know the essence of
the document before they examine the details.]
<<Begin text
here>>
[Description:
The Development Objectives section defines the primary drivers that were used to
create the development approach and the key objectives of that approach.
Justification:
Identifying
the drivers and development objectives signals to the customer that Microsoft
has carefully considered the situation and created an appropriate development
approach.]
<<Begin text
here>>
[Description:
The Overall Delivery Strategy section describes the overall approach to
delivering the solution. Potential approaches could be a staged delivery,
“depth-first,” “breadth-first,” “features then performance,”
etc.
Justification:
Considering
and concluding on delivery options demonstrates that the team has assessed the
business and technology environments and matched those with an appropriate
delivery strategy.
{Team
Role Primary: Product Management
contributes to the overall delivery strategy since it must align with customer
expectations. Program Management
provides direction for the overall delivery strategy based on the content of
the vision/scope document. Development provides input to the
overall delivery strategy based on the content of the functional specifications
documents.
Team
Role Secondary:
Test uses the overall delivery
strategy to structure their test plan.}]
<<Begin text
here>>
[Description:
The Tradeoff Approach section defines the approach that will be taken for making
design and implementation trade-off decisions (e.g. trade features for schedule,
trade features for performance, etc.).
Justification:
The content of this section sets the guidance for making trade-offs throughout
the project. These trade-offs should be established up front with the customer
and then be reassessed throughout the life of the project.]
<<Begin text
here>>
[Description:
The Key Design Goals section identifies the key design goals and their priority.
Examples of design goals include:
Justification:
Identifying
and prioritising design goals ensures that the team has carefully considered the
business requirements and converted those into a framework that provides context
for the overall development strategy.]
<<Begin text
here>>
[Description:
Te Development and Build Environment section describes the development and build
environment and how it will be managed. Include information on such things as
source code control tools, design tools requirements, OS, or other on-board
software installed. You may put the description of the environment
infrastructure in the Deployment plan instead.
Justification:
A
plan for creating the development and build environment will ensure that it will
be put in place before development begins.
A plan for managing the environment ensures that it is stable and supportive to
the development and build processes.
{Team
Role Primary: Release Management
is responsible for ensuring that the development and build environment
aligns with the existing and planned infrastructure. In situations where release
provides specific input into the development plan, then traceability of this
input must be mapped back to the deployment plan.
Team
Role Secondary:
Development will verify that the
development and build environment meets the needs for their
tools.}]
<<Begin text here>>
[Description:
The Guidelines and Standards section lists and provides references to all
standards and guidelines to be used by the project. Add addition sub-sections as
needed for the project.
Justification:
Establishing guidelines and standards before development work begins ensures
that all development team members are made aware of the expectations placed upon
them.]
[Description:
The Naming section lists and provides references to the naming conventions used
for the project.]
<<Begin text
here>>
[Description:
The Coding section lists and provides references to the coding conventions used
for the project.]
<<Begin text
here>>
[Description:
The Versioning and Source Control section describes how versioning and source
control will occur. This should include identification of the specific tool that
will be used and how developers are expected to use it.
Justification:
Establishing
these processes before development work begins ensures that all development team
members are made aware of the expectations placed upon them.]
<<Begin text
here>>
[Description:
The Daily Build Process section describes the incremental and iterative approach
for developing code as well as for “builds” of hardware and software components.
It also describes how the daily build process will be
implemented.
Justification:
The daily build process ensures the
stability of the total solution, through the use of ample test data, before it
is released into production. Frequent builds provide validation that all of the
code is compatible and allows the various sub-teams to continue their
development and testing iterations.
{Team
Role Primary: Development drives
the daily build process. This should be based on well-defined, documented
processes in conjunction with versioning and source
control.
Team
Role Secondary:
Test needs to understand the daily
build process and specifically how they will receive updated builds. This
information will be incorporated into the Test plan. Release Management provides input to
the daily build process since they are responsible for the infrastructure that
makes the builds possible.}]
<<Begin text
here>>
[Description:
The Roadmap section describes the order in which the solution components will be
delivered.]
<<Begin text
here>>
|
Component |
Description |
Critical Dates |
Team (Owner) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[Description:
The Components section provides a high-level description of the set of solution
components and how they will be developed.
Justification:
This section provides the work breakdown structure for the development process.
It ensures that all development team members are clear on their role and
responsibilities, the methods to be used for their tasks, and how the tasks
results will be assessed for quality.]
[Description:
The Component Descriptions section describes all key components in the solution,
including their purpose, history, and references to their
specifications.]
<<Begin text
here>>
[Description:
The Component Teams section identifies who will be responsible for developing
each component.]
<<Begin text
here>>
[Description:
The Component Design section provides an outline of the design process for each
component.]
<<Begin text here>>
[Description:
The Component Acquisition and Development section identifies any components that
are to be acquired, identifies their sources, and shows how they fit into the
solution. It also describes the processes and the procedures used to integrate
acquired and built solution components together.]
<<Begin text here>>
[Description:
The Component Quality section describes the measures for ensuring that all
components meet quality expectations. It includes a description of the following
processes:
<<Begin text
here>>
[Description: The Configuration and Development Management
Tools section identifies all the development tools the team will employ
over the project’s lifespan. This should include tools for all phases and
dimensions of the project (development, testing, documentation, support,
operations, deployment, etc.)
Justification:
All team members should consistently apply the development tools. Selecting the
tools during the planning phase ensures this consistency.]
<<Begin text
here>>
|
|
Microsoft
Internet Explorer |
Microsoft Internet Information
Server |
Microsoft COM+ |
Microsoft SQL
Server |
|
User
Service Components |
Tools: VisualStudio.Net, Visual Basic
6.0, Technology:
DHTML, VBScript, ActiveX Controls |
Tools:
VisualStudio.Net Technology:
ASP.Net, VBScript |
Not Applicable |
Not Applicable |
|
Business
Service Components |
Tools: Visual Basic
6.0 Technology: ActiveX
Controls |
Not Applicable |
Tools: Visual Basic
6.0 Technology: COM, ActiveX Data Objects ( |
Not Applicable |
|
Data
Service Components |
Not Applicable |
Not Applicable |
Tools: Visual Basic
6.0 Technology: COM, ActiveX Data Objects ( |
Tools: Visual Studio
6.0 Technology: SQL, Stored
Procedures |
|
Deployment
Tools |
Sysprep |
|
|
Erwin |
|
Testing
Tools |
AppCenter Test |
AppCenter Test |
AppCenter Test |
AppCenterTest |
[Description:
The Description section provides a description of Tool 1 and its
application.]
<<Begin text
here>>
[Description:
The Team section identifies who will be utilizing the
tool.]
<<Begin text
here>>
[Description:
The Risk Management section identifies the risks associated with this tool and
any necessary plans to reduce or mitigate the risks.]
<<Begin text
here>>
[Description:
The Description section provides a description of Tool 2 and its
application.]
<<Begin text
here>>
[Description:
The
Team section identifies who will be utilizing the tool.]
<<Begin text
here>>
[Description:
The Risk Management section identifies the risks associated with this tool and
any necessary plans to reduce or mitigate the risks.]
<<Begin text
here>>
[Description:
The Reuse section describes the overall approach for reusing solution
components.]
<<Begin text
here>>
[Description:
The Design Patterns section identifies the design patterns (templates) the team
will use for this project and it identifies their sources. The team may acquire
design patterns from both external and internal sources and they may create new
design patterns.]
<<Begin text here>>
[Description:
The Development Team Training section identifies the training necessary for the
development team to ensure members will be successful developing the
solution.
Justification:
Planning
for any necessary training early in the project will ensure that sufficient time
and resources are budgeted. This planning will also identify project tasks
(training) that must occur before development work
begins.]
<<Begin text
here>>
[Description:
The Development Team Support section identifies the various types of support the
development team will require, the sources of that support, the amount of
support of each type they will require, and the estimated schedule for
support.
Justification:
The
early identification of support requirements will ensure that they are in place
before development work begins.]
<<Begin text
here>>