04/03/2018 Chapter 4 - Developing Phase

Chapter 4 - Developing Phase

On This Page
Goals for the Developing Phase
Team Focus during the Developing Phase
Starting the Development Cycle
Developing the Solution Components
Building the Solution
Testing the Solution
Closing the Developing Phase
Key Milestone: Scope Complete

Goals for the Developing Phase

Figure 4.1: The Developing Phase in the MSF Process Model

The primary goal during the Developing Phase is to build the solution components code as well as documentation. Some
development work may, however, continue into the Stabilizing Phase in response to testing.

The Developing Phase involves more than code development and software developers. The infrastructure is also developed
during this phase and all roles are active in building and testing deliverables. The team continues to identify all risks
throughout the phase and address new risks as they emerge.

The tasks summarized in Table 4.1 need to be completed during the Developing Phase. This project guide describes the
processes and roles required to accomplish them. Detailed information specific to each migration project about each task,
especially technical information, is provided in the migration guide for that project.

Table 4.1 Major Developing Phase Tasks and Owners

Major Tasks Owners

Starting the development cycle Development

The team begins the development cycle by verifying that all tasks identified during the Envisioning and
Planning Phases have been completed.

Building a proof of concept Development

Before development, the team does a final verification of the concepts from the designs within an
environment that mirrors production as closely as possible.

Developing the solution components Development,

The team develops the solution using the core components and extending them to the specific needs of User

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 1/7
04/03/2018 Chapter 4 - Developing Phase

the solution. The team also develops and conducts unit functional tests to ensure that individual features Experience,
perform according to specification. Test

Developing the testing tools and tests Test

The team develops a testing infrastructure and populates it with test cases that help ensure the entire
solution performs according to specification. This solution test suite typically incorporates, as a subset,
the individual feature tests used by developers in building the solution components.

Building the solution Development,

A series of daily, or frequent, builds culminate with major internal builds and signify points where the Test
development team is delivering on key features of the solution. These builds are subjected to some or all
of the project test suite as a way of tracking overall progress of the solution and of the solution test suite
itself.

Closing the Developing Phase Project team

The team completes all features, delivers the code and documentation, and considers the solution
complete, thus entering the approval process for the Scope Complete Milestone.

Top of page
Team Focus during the Developing Phase
Table 4.2 addresses the tasks described previously, but considers them from the perspective of the team roles. It describes
the focus and responsibility areas of each team role during the Developing Phase.

The primary team roles driving this phase are Development and User Experience.

Table 4.2 Role Cluster Focuses and Responsibilities in Developing Phase

Role Cluster Focus and Responsibility

Product Customer expectations

Management

Program Functional specification management; project tracking; updating plans

Management

Development Code acquisition and development (including unit testing); integration, infrastructure development;
configuration documentation, issues identification

User Training; updated training plan; usability testing; graphic and information design
Experience

Test Functional testing; performance evaluation, issues identification; documentation testing; updated test
plan, evaluation reporting; test and test infrastructure development

Release Rollout checklists, updated rollout and pilot plans; site preparation checklists
Management

Top of page
Starting the Development Cycle
Guidance for this phase introduces and discusses each code component, discusses how to apply the code, and looks at
adapting and extending the components to meet the needs of the project requirements.

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 2/7
04/03/2018 Chapter 4 - Developing Phase

Addressing Risk in the Developing Phase

The Developing Phase of any UNIX migration project can be the most volatile, frustrating, stimulating, challenging, and
enjoyable part of the journey. Major issues likely will become evident soon after this phase begins. Resolution of these issues
will be the distinguishing factor that determines if schedules will change, funding is sufficient, and whether or not the project
will be successful.

The Envisioning and Planning techniques and tools introduced in the preceding phases of this guide are designed to prepare
for and insulate the project team from many of the setbacks and delays that might occur during development. The ability to
recognize and mitigate a projects risks is particularly helpful. A system that identifies, prioritizes, and tracks risks is more
useful during the Developing Phase of a project than at any other point. Think of the Developing Phase as the pinnacle of
potential chaos in the projects life cycle. Containing the chaos benefits the project and usually results in a superior solution.

Look at the task lists from the Envisioning and Planning phases to discover the points of high risk in the Developing Phase. If
any item on these lists is not completely satisfied, it could present itself as a risk during the Developing Phase.

For example, if you are entering the Developing Phase and the required hardware for development has not arrived, how will
the developers proceed? How will testers begin their testing cycles? The following actions might mitigate the risks:

Contact the vendor to expedite the equipments delivery, incurring additional fees if necessary.

Use available desktop computers to fill in the roles of the development servers until they arrive. Purchase additional
low-cost computers if needed, and use them later for other purposes.

Lease or borrow servers from a vendor or another department in your company until your equipment arrives.

None of these suggestions is difficult to figure out each appears to be an obvious answer. Implementing any one of them is
likely to go much more smoothly, however, if the risk was identified and mitigation plans formulated and evaluated ahead of
time. Risk mitigation as part of the risk management process can be used to keep a project on track through adverse
situations. Respecting the tenets and adhering to the procedures in the MSF Risk Management Discipline is the key to
ensuring that project risks do not bring progress to a halt.

Building a Proof of Concept

Typically, the proof of concept is a continuation of some initial development work (the preliminary proof of concept) that
occurred during the Planning Phase. The proof of concept tests key elements of the solution on a non-production simulation
of the proposed operational environment. The team walks operations staff and users through the solution to validate their
requirements.

There may be some solution code or documentation that carries through to the eventual solution development deliverables;
however, the proof of concept is not meant to be production-ready. The proof of concept is considered throw away
development that gives the team a final chance to verify functional specification content and to address any more issues
prior to transitioning into development.

Interim Milestone: Proof of Concept Complete

Reaching this interim milestone marks the point where the team is fully transitioning from conceptual validation to building
the solution architecture and components.

Top of page
Developing the Solution Components
MSF recommends that project teams follow a best practice of performing daily builds with their solution. Building a solution
in a form that is executable on a daily basis provides a number of valuable benefits simply by putting different pieces of the
code together. A daily build exposes unanticipated design defects and makes diagnosing defects easier.

The daily build should be subjected to as much of the full suite of tests as can be run during the available time. This build
validation test pass helps expose integration defects as early as possible. It also allows the team to validate their testing
approach and testing infrastructure.

Top of page

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 3/7
04/03/2018 Chapter 4 - Developing Phase

Building the Solution

Developing the solution components, building the infrastructure, and doing initial code test and integration work is usually
done in parallel and in segments, so the team needs a way to measure progress as a whole. Daily or interim builds
accomplish this by forcing the team to synchronize these pieces in their entirety. How many builds and how often they occur
will depend on the size of the solution and duration of the project.

MSF advocates preparing frequent builds of all the components of the solution for testing and review. This approach is
recommended for developing code as well as for builds of hardware and software components. The process of creating
interim builds allows a team to find issues early in the development process, which shortens the development cycle and
lowers the cost of the project. Daily builds are the practice of assembling all the components working toward the final goal of
a solution. This enables the team to determine earlier rather than later that all components will work together. This method
also allows the team to add functionality onto a stable build. The idea is to have a shippable product ready at any point in
time. In this way, the stability of the total solution is well understood and has ample test data prior to being released into
production.

Larger, complex projects are often split into multiple segments, each of which is developed and tested by separate sub-
teams or feature teams, and then consolidated into the whole. Microsoft product development projects are typical examples.
In projects of this type, the daily build approach is a fundamental part of the process. Core functionality of the solution or
product is completed first, and then additional features are added. Development and testing occur continuously and
simultaneously in parallel tracks. The daily build provides validation that all of the code is compatible, and it allows the
various sub-teams to continue their development and testing iterations.

Figure 4.2 illustrates the relationship between daily or interim builds and internal releases.

Figure 4.2: Each internal release is developed through daily builds

Note that these interim builds are not deployed in the live production environment. Only when the builds are thoroughly
tested and stable are they ready for a limited pilot (or beta) release to a subset of the production environment. Rigorous
configuration management is essential to keeping builds in synch.

It often makes sense to set interim milestones to achieve design freezes of the user interface and data tier elements because
of the many dependencies on these components. For example, screen shots are needed to create documentation, and the
database schema forms a deep part of the overall architecture.

Top of page
Testing the Solution
The testing process is designed to identify and address potential solution issues prior to deployment. Testing starts when
solution development begins, and it ends when the testing team certifies that the solution components meet the project
plans goals for schedule and quality. Figure 4.3 illustrates that testing spans phases.

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 4/7
04/03/2018 Chapter 4 - Developing Phase

Figure 4.3: Testing in the Developing Phase is part of the build cycle, not a standalone activity
When building software, the development team designs, documents, and writes code that it then tests through unit testing
and daily builds. When building hardware or network infrastructure, the team may be developing scripts, conversion tools,
hardware configuration settings, network topologies, and other similar tasks. The team tracks development progress against
a project schedule, resolves reported bugs, and documents testing results.

The testing team designs and documents test specifications and test cases, writes automated scripts, and runs acceptance
tests on components submitted for formal testing. This team assesses and reports on overall solution quality and feature
completeness, and it certifies when the solution features, functions, and components meet the project goals.

Test plans created during the Planning Phase are implemented during the Developing and Stabilizing Phases. The test plan
breaks down the testing process into different elements, including:

Code component testing

Database testing

Infrastructure testing

Security testing

Integration testing

User acceptance and usability testing

Stress, capacity, and performance testing

Regression testing

Code Component Testing

Component functional testing is the process of finding the discrepancies between the functional specification and the actual
output of the component itself. Basic smoke testing, boundary conditions, and error test cases all come out of the functional
specification.

In the migration of applications, testing is focused on finding discrepancies between the behavior of the original application
and that of the migrated application. In the migration of infrastructure services, testing is focused on finding discrepancies
between the behavior of the original service as seen by its clients and that exhibited by the new, migrated service. All
discrepancies must be investigated and their cause determined. For this reason, its best to add functionality to a migrated
application, or capabilities to a migrated service, in a separate project initiated after migration is complete.

The testing process should use all tests and tools developed during the project that constructed the original component. The
test teams first task is, in fact,migrating those original tests to the new environment. The team must also develop new tests
that focus on the application or service components that will change during the migration.

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 5/7
04/03/2018 Chapter 4 - Developing Phase

Stress testing is the process of loading the component to the defined and undefined limits. The defined limits should be
outlined in user documentation, the functional specification, and the marketing plan. The undefined limits have to be
calculated guesses. Because each environment is very dynamic, each component needs to be stressed under load to ensure
that it performs within a reasonable performance limit. Tests should be conducted to measure and monitor system CPU, and
memory per component.

Code Review
Code reviews are a time-tested technique for finding certain classes of defects that might otherwise take a long time to
surface in testing or that might be very expensive to repair. Just as a spell-check program cannot readily discern whether a
writer meant to use the word to, too, or two, the human eye and mind are sometimes the best tool to identify designs or
source code that appear to be correct on the surface but are, in fact, defective in subtle ways.

Ideally, every prospective change is fully reviewed by a developer (other than the one proposing it) and by a tester before the
change is checked into the revision control system. When the number of changes, or the size of each change, is too great to
permit universal review, changes to critical components should be reviewed. The test plan should define specific criteria
identifying those changes that must be reviewed by other members of the team before check-in.

Security Testing
It is imperative that the application be significantly hardened against application errors that can either give an attacker the
capability to better map the application architecture, obtain confidential system information (including credentials, database
connection strings, and so on), or enable arbitrary code to be run on the server (as in the case of a buffer overflow). Knowing
the user context in which system processes run, keeping the privileges that these accounts have to a minimum, and logging
their access to these accounts will help to minimize risks associated with unchecked errors on the system.

Some error conditions can appear that you cannot control, such as bugs in system software and operating system software.
Diligent review of the latest security patches and software updates from the software vendors is an important maintenance
task that must be assigned to a support team member.

It is possible for errors in judgment to lead to a catastrophic situation (both from a systems and a business point of view);
fortunately, they can be easily avoided. Judgment errors include omitting to validate input from the client, inclusions of back
doors to applications, and using weak or blank passwords on systems and in databases. A best practice is to always use the
strongest passwords possible, preferably randomly generated passwords.

Interim Milestone: Internal Release n

As noted previously, the project needs interim milestones that can help the team measure their progress in the actual
building of the solution during the Developing Phase. Each internal release signifies a major step toward the completion of
the solution feature sets and achievement of the associated quality level. Depending on the complexity of the solution, any
number of internal releases may be required. Each internal release represents a fully functional addition to the solutions core
feature set that is potentially ready to move on to the Stabilizing Phase. It is only when the final feature set for this version of
the solution is completed and built that the internal release process is complete.

Top of page
Closing the Developing Phase
Closing the Developing Phase requires completing a milestone approval process. The team needs to document the results of
the different tasks it has performed in this phase to give stakeholders (including the customer) the information they need to
sign-off on the completion of development.

Key Deliverables from the Developing Phase

A deliverables checklist for the Developing Phase includes:

Source code and executables

Installation scripts and configuration settings

Frozen functional specification

End-user Help and training materials

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 6/7
04/03/2018 Chapter 4 - Developing Phase

Test specifications and test cases (coverage tests)

Testing and bug reports

Updated Risk Management documentation

Milestone review report

Team member project progress report

Team lead project progress report

Top of page
Key Milestone: Scope Complete
The Developing Phase culminates in the Scope Complete Milestone. At this milestone, all features are complete and the
solution is ready for external testing and stabilization. This milestone is the opportunity for customers and users, operations
and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues they need to
address before beginning the transition to stabilization and ultimately to release.

Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives
of each team role and any important customer representatives who are not on the project team, signal their approval of the
milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a
project deliverable and is archived for future reference.

Top of page
Download

Get the UNIX Migration Project Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Top of page

© 2018 Microsoft

https://technet.microsoft.com/en-us/library/bb497041(d=printer).aspx 7/7