MKS Implementer 2006 Administration Guide

Release-based
Development
Continuous
Development
Multi-Platform Development and Deployment Scenarios
Characteristics Significance of Characteristics
Problems typically represent requirements or
new features and functions as specified by
product management or business analysis.
The initial development process requires the
coordination of the analysis, design, and
development tasks across various team
members. This model supports the iterative
steps of the development process.
There is a clear distinction between the
various components that need to be
developed, and the testing process that
focuses on black box functionality.
Need to track all tasks being done according
to relevant components.
With larger development tasks, multiple
people may need to work on the same
proposal and their work status needs to be
coordinated.
Need to separate the problem process from
the proposal and work instruction processes
to allow for separate levels of monitoring.
Certification and acceptance testing are
typically handled by a Quality Assurance
(QA) team.
Decisions to release the product are based
on the results of the system testing phase.
Initial development phase has passed and
software has been released to the customer.
Maintenance cycle has begun.
All work is generated by issues or problems
raised against the released product.
Changes are typically bugs or small
enhancements.
Several problems are gathered together to
be fixed in a particular release.
Development and product managers work
together to negotiate priorities and decide
what will be fixed in a release.
Requirements analysis and design are
minimal and it is not necessary to track them
with separate states.
Need to ensure all code changes are tracked
along with the original problem.
Functional testing is handled within the
development team.
Proposals and work instructions may be used
but are not tracked with a process.
Work is planned and monitored closely to
distribute work evenly across resources and
synchronize parallel tasks.
When various groups within an organization
are monitoring the progress of problems,
they may not be interested in the detailed
development status. By separating the
process from development tracking, it is
possible for various managers to monitor the
status of the problems they are interested in
at a high level.
Separate process flows for proposals and
work instructions help to focus the process
details as needed rather than having one
long overwhelming process on a problem.
Supports parallel development tasks and
allows for independent tracking of each task.
Process focused on the problem only, since
the goal is to manage a high volume of
issues rapidly.
It is important to record changes with a
proposal change package, but the process
flow for the proposal is not significant.
Simplified process facilitates the rapid handoff
of responsibility among the developer,
build coordinator, and QA team.
Able to handle a high volume of problems
and ensure they do not fall through the
cracks or get lost along the way.
57