Chapter 2: Developing Phase: Process Milestones and Technology Considerations

Article
12/05/2007

This chapter provides information on starting the Developing Phase and provides an insight into the development environment for the migration exercise. It also discusses the major tasks and deliverables that should be identified and planned at the start of the Developing Phase.

Goals for the Developing Phase

This section describes the primary goals to be achieved in the Developing Phase. It acquaints you with the major tasks to be performed and the deliverables to be expected from the Developing Phase so that you can plan activities for your team accordingly.

The primary goal during the Developing Phase is to build the solution components—code as well as documentation. Apart from code development, the infrastructure is also developed during this phase, and all roles are active in building and testing the deliverables. The team continues to identify all risks throughout the phase and address new risks as they emerge.

Major Tasks and Deliverables

Table 2.1 describes the major tasks that you need to complete during the Developing Phase and lists the roles (owners) responsible for accomplishing them.

Table 2.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 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 extends 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 the specification.	Development, User Experience, Test
Developing the testing tools and tests The team prepares the test cases to ensure the entire solution performs according to the specifications.	Test
Building the solution A series of frequent builds culminate with major internal builds and signify points where the development team delivers key features of the solution. These builds are tested against the test cases to track the overall progress of the solution	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

Starting the Development Cycle

During the Developing Phase, every component of the solution is analyzed in terms of how to apply code changes to adapt to the Microsoft® Windows® environment. This section focuses on providing you with the knowledge to identify and monitor the risks involved in the migration exercise.

The Developing Phase can be the most challenging part of any UNIX migration project. Major issues that are likely to affect the project will become evident in this phase. How these issues are resolved will determine whether the project schedules will change, whether funding will be sufficient, and whether the project will be successful.

The envisioning and planning techniques and tools introduced in Chapters 2 and 3 of Volume 1: Plan of this guide are designed to prepare for and insulate the project from many of the setbacks and delays that might occur during the Developing Phase. The capability to identify and mitigate risks is particularly helpful. A system that identifies, prioritizes, tracks, and mitigates risks is more useful during the Developing Phase of a project than any other phase.

Any unfinished tasks on the task lists from the Envisioning and Planning Phases could be a risk during the Developing Phase. Any assumptions made during the Planning and Envisioning Phases could also be potential risks in the Developing Phase because they could also bring up unforeseen challenges during the Developing Phase.

The prescriptive checklist to mitigate the risks in this phase is as follows:

Contact the vendor to expedite delivery of the equipments as per the hardware requirement list.
For the GUI aspect of the code migration, procure the necessary software licenses for the necessary X Server used in the UNIX application from the vendor before starting the project.
Prepare a requirements specification document, providing a detailed design scope of the migration project, design and architecture to be followed, and a sign-off from the customer.
If there are many change requests from the customer, perform an impact analysis of the changes and get a sign-off from the customer on the project execution approach for the requested changes.
Provide necessary training to the project team that will aid in the proper and timely execution of the project.

Implementing these suggestions is likely to be much easier if the risks have been identified and the 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 Microsoft Solutions Framework (MSF) Risk Management Discipline is key to ensuring that the project risks do not bring the project to a halt.

Building a Proof of Concept

Typically, the proof of concept is a continuation of the initial development work (the preliminary proof of concept) completed in the Planning Phase. The proof of concept tests key elements of the solution in a nonproduction simulation environment that mirrors the proposed operational environment. The team guides operations staff and users through the solution to validate that their requirements are met by the new solution.

The proof of concept is not meant to be production-ready although there may be some solution code or documentation that carries through the different phases to the eventual solution development deliverables. The proof of concept is considered a throw-away development that gives the team a final chance to verify the functional specification content and to address issues and mitigate risks before making the transition into development.

Interim Milestone: Proof of Concept Complete

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

Developing the Solution Components

After successfully completing the proof of concept, the actual development of the solution components is started as per the specified solution architecture and design. Important prerequisites for the development activity, such as the migration approach, the technology to be used, the language to be used for editing and compilation, are decided before starting the Developing Phase in order to improve the efficiency of the development activity and reduce the time required to complete it.

The several technologies used in the UNIX application are identified and analyzed and the corresponding mechanisms in Windows are chosen to implement the migration process. The following chapters of this volume address these potential coding differences:

Process management
Thread management
Memory management
File management
Infrastructure services
- Signals and events
- Exception handling
- Sockets and networking
- Interprocess communication
- Daemons versus services
Migrating the Graphical User Interface

You can then choose the solution that is most appropriate to your application and use these instructions as the basis for constructing your .NET code. This guide gives you sufficient information to choose the best method of converting the code to .NET. After you have made your choice, you can refer to the MSDN or .NET Framework documentation to ensure that you understand the technical details and implement them correctly. Throughout this volume, references are given for obtaining further information on the recommended coding changes—including code samples and URLs.

Using the Development Environment

The development environment is the environment in which the user develops and builds the solution. The development environment provides the necessary compiler, linker, libraries, and reference objects. In some cases, the integrated development environment (IDE) is also provided.

This section discusses the important components of the development environment for .NET applications. The two main components of the .NET development environment are the .NET Framework SDK and Visual Studio® .NET 2003.

.NET Framework SDK

The .NET Framework Software Development Kit (SDK) contains samples, compilers, and command-line tools designed to help you build applications and services based on .NET Framework technology. The SDK also provides documentation that includes an extensive class library reference, conceptual overviews, step-by-step procedures, tools information, and tutorials that demonstrate how to create specific types of applications. The .NET Framework SDK should be the essential reference for developers migrating UNIX applications to .NET. It contains the following major sections that provide critical information related to .NET:

Getting Started. For those new to the .NET Framework technologies, the Getting Started section of the .NET Framework SDK documentation are designed to point you in the right direction.
QuickStarts , Tutorials , and Samples. The .NET Framework SDK QuickStarts, tutorials, and samples are designed to quickly acquaint you with the programming model, architecture, and components that make up the .NET Framework.
Documentation. The .NET Framework SDK documentation provides a wide range of overviews, programming tasks, and class library reference information to help you in migrating the applications to .NET.
Tools and Debuggers. The .NET Framework SDK tools and debuggers enable you to create, deploy, and manage applications and components that target the .NET Framework.

The .NET Framework SDK is freely available for downloading from the MSDN Web site at

https://msdn.microsoft.com/netframework/downloads/updates/default.aspx.

Visual Studio .NET 2003

Visual Studio .NET 2003 is a complete suite of development tools that gives you an ideal platform for migrating or building various enterprise applications such as Web applications, desktop applications, or Web services. In addition, you can use its powerful component-based tools and other technologies to simplify the design, development, and deployment of enterprise solutions. Visual Studio .NET 2003 supports such languages as Visual C++® .NET, Visual Basic® .NET, Visual C#® .NET, and Visual J#® .NET, all of which use the same integrated development environment (IDE).This allows them to share tools and facilitates in the creation of mixed-language solutions. These languages also take advantage of the functionality of the .NET Framework, which provides access to key technologies to simplify the migration process.

Visual Studio .NET contains a number of tools and technologies to facilitate the porting and upgrading of existing applications. It provides various methods for interoperating with existing application code, which results in a more efficient migration path requiring minimal code changes.

Some of these technologies are:

COM+ Services
.NET Enterprise Services
P/Invoke methodology

Details of these technologies are described in Chapter 3, “.NET Interoperability“ of this volume.

Developing the Testing Tools and Tests

After developing the solution components, you need to test the code changes made as a part of the development process. The testing process helps in identifying and addressing potential issues prior to deployment. Testing spans the Developing and the Stabilizing Phases. It starts when you begin developing the solution and ends in the Stabilizing Phase when the test team certifies that the solution components address the schedule and quality goals established in the project plan. This also involves using the automated test tools and test scripts.

Figure 2.1 depicts project testing processes in the Developing and Stabilizing Phases as per the Microsoft Solutions Framework (MSF) Process Model.

Figure 2.1. MSF Process Model - Testing processes across the Developing and Stabilizing Phases

Testing is performed, parallel to development, throughout the Developing Phase. This section discusses the unit testing activity that needs to be performed during the Developing Phase. The other necessary testing activities are discussed in Chapter 9, “Deployment Considerations and Testing Activities” and Chapter 10, “Stabilizing Phase” of this volume.

Testing in the Developing Phase is part of the build cycle, not a stand-alone activity. The development team designs, documents, and writes code and the test team performs unit testing and daily builds testing. The test team designs and documents test specifications and test cases, writes automated scripts, and runs acceptance tests on components submitted for a formal testing. The test team assesses the solution, makes a report on its overall quality and feature completeness, and certifies that the solution features, functions, and components meet the project requirements. This process may be iterated several times based on the test results achieved from each testing activity.

In migration projects, testing is focused on finding the discrepancies between the behavior of the original application and that of the migrated application. In the migration of the infrastructure services, testing is focused on finding the discrepancies between the behavior of the original service, as seen by the clients, and the service that is exhibited by the newly migrated service.

All discrepancies must be investigated and fixed. It is recommended that you add new functionality to a migrated application or new capabilities to a migrated service in a separate project initiated after the migration project is complete.

Unit testing of the solution components is an integral part of the testing activity in the Developing Phase. Before starting with unit testing, a detailed code review is performed on the developed components and the review feedback is incorporated into the solution. Then the components are unit tested for their functionality.

Unit Testing

A unit may be a class, a program, or a specific functionality. Unit testing is part of the development process. Unit testing is the process of verifying that a specific unit of code functions according to its functional specifications and that it will be capable of interacting with other units as detailed in the specifications.

Unit testing in a migration project is the process of finding the discrepancies between the functionality and the output of individual units in the Windows application and the original UNIX application. However, this might not always be the case; in some cases, the application design in Windows may differ from the UNIX design. Therefore, it is important to identify units that are different in design from the UNIX units. Basic smoke testing, boundary conditions, and error tests are performed based on the functional specification of the unit.

The test cases for unit testing include constraints on unit inputs and outputs (pre-conditions and post-conditions), the state of the object (in case of a class), and the interactions between methods, attributes of the object, and other units.

Building the Solution

By this stage, the individual components of the solution are developed and tested in the Windows environment using .NET to satisfy the project requirements. This stage helps you build the solution with the developed and tested components and then make the migrated application ready for internal release.

As a good practice, MSF recommends that teams working on development projects perform daily builds of their solution. In migration projects, on the other hand, you typically have to examine large bodies of existing code to understand what they are intended for and to make changes to the code. However, code changes can happen only after addressing porting issues, hence daily builds may not be required. 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. 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 release to a subset of the production environment. Rigorous configuration management is essential to keeping builds in synch.

Interim Milestone: Internal Release

The project needs interim milestones to 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 solution’s core feature set that is potentially ready to move on to the Stabilizing Phase. As each new release of the application is built, fewer bugs must be reported and triaged. Each release marks a significant progress in the approach of the team toward deployment. With each new candidate, the team must focus on maintaining tight control on quality.