Chapter 4 - Developing Phase

Article
12/05/2007

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 The team begins the development cycle by verifying that all tasks identified during the Envisioning and Planning Phases have been completed.	Development
Building a proof of concept Before development, the team does a final verification of the concepts from the designs within an environment that mirrors production as closely as possible.	Development
Developing the solution components The team develops the solution using the core components and extending them to the specific needs of the solution. The team also develops and conducts unit functional tests to ensure that individual features perform according to specification.	Development, User Experience, Test
Developing the testing tools and tests 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.	Test
Building the solution A series of daily, or frequent, builds culminate with major internal builds and signify points where the 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.	Development, Test
Closing the Developing Phase 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.	Project team

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 Management	Customer expectations
Program Management	Functional specification management; project tracking; updating plans
Development	Code acquisition and development (including unit testing); integration, infrastructure development; configuration documentation, issues identification
User Experience	Training; updated training plan; usability testing; graphic and information design
Test	Functional testing; performance evaluation, issues identification; documentation testing; updated test plan, evaluation reporting; test and test infrastructure development
Release Management	Rollout checklists, updated rollout and pilot plans; site preparation checklists

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.

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.

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.

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.

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.

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.

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.

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
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

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.