Analyzing Requirements and Defining Solution Architectures MCSD Training Kit

Author Microsoft Corporation Pages 704 Disk 1 Companion CD(s) Level All Levels Published 09/15/1999 ISBN 9780735608542 ISBN-10 0-7356-0854-7 Price(USD) $69.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series Related Books About the Author Support: Book & CD Rate this book

Chapter 4: Development Process

• Models for Application Development
• Waterfall Model
• Spiral Model
• Unified Process
• Workflows
• Project Phases
• Iterations
• MSF Development Process Model
• Phased Process
• Milestone-Driven Process
• Versioned Process
• The Four MSF Phases and Their Major Milestones
• Envisioning Phase
• Planning Phase
• Developing Phase
• Stabilizing Phase
• Importance of All Phases
• MSF Development Process Model Principles
• Using Versioned Releases
• Creating Living Documents
• Scheduling for an Uncertain Future
• Managing Tradeoffs
• Managing Risk
• Maintaining a Fixed Ship-Date Mindset
• Breaking Large Projects into Manageable Parts
• Performing Daily Builds
• Using Bottom-Up Scheduling
• Using Versioned Processes
• Guidelines for Versioned Releases
• Development Tasks During Other Phases
• Team Roles in the MSF Development Process Model
• Artifacts and Deliverables
• Relationships Between Models
• Summary
• Review
• CASE STUDY 3
• Introducing the RMS Project
• Current State
• Scheduling Resources
• Completing Timesheets
• Recording Time
• Generating Invoices
• Business Implications
• Wrapping Up and Assignments
• CASE STUDY 4
• Determining Goals
• Review of the MSF Development Process Model
• Team Roles and Their Phase Responsibilities
• Iterations Within Versions
• RMS Project Calendar and Initial Goals

About This Chapter

The majority of this chapter is devoted to the MSF Process Model for Application Development, which we call the MSF Development Process Model. Rather than a step-by-step methodology, MSF is a structural framework that an organization can adapt to suit its particular needs. The MSF Development Process Model is the part of this framework that describes the life cycle of a successful software development project. This model allows a project team to respond to customer requests and to change product direction midcourse. It also allows a team to deliver key portions of the product faster than would otherwise be possible. The MSF Development Process Model is a flexible component of MSF that has been successfully proven in the software industry to improve project control, minimize risk, improve product quality, and increase development speed.

The principles and guidelines we provide in this chapter are based on our own experience with the creation of application architectures and the implementation of enterprise applications, as well as information from the following sources:

• Microsoft Solutions Framework
• Walker Royce’s Software Project Management: A Unified Framework
• Grady Booch, James Rumbaugh, and Ivar Jacobson’s The Unified Modeling Language User Guide
• Ivar Jacobson, Grady Booch, and James Rumbaugh’s The Unified Software Development Process

Upon completion, you will be able to:

• Understand the characteristics of the Waterfall and Spiral Models and list their disadvantages.
• List the workflows of the Unified Process.
• Identify the primary models of the Unified Process.
• List the four phases of the MSF Development Process Model.
• Understand the benefits of versioned releases and the impact of an iterative approach on development projects.
• Relate team roles and responsibilities to the MSF Development Process Model.
• Understand the relationships between project variables and constraints, and the concept of managing tradeoffs.
• Analyze projects to determine goal-driven milestones.
• Analyze development projects to determine process iteration goals.

Models for Application Development

Modern processes for application development have evolved over time from best practices derived from very traditional processes, such as those represented by the Waterfall Model and the Spiral Model. As a way of providing background information for the rest of this chapter, we first take a look at the main characteristics of these two models. Then we look at the Unified Process and the MSF Development Process Model.

Waterfall Model

The stages of building a house are similar to the stages of the Waterfall Model of application development. As shown in Figure 4.1, the tightly defined Waterfall Model is an orderly, highly structured process based on the following well-defined development steps:

• Gathering system and software requirements
• Analysis
• Program design
• Coding and unit testing
• System integration
• System testing
• Operation acceptance

Each step is completed and thoroughly documented before the next step can begin.

Click to view graphic

Figure 4.1 Waterfall Model

Strict use of the Waterfall Model is declining. Following this model causes several problems throughout the product life cycle, which are summarized below.

• Extra time Typically more time than was initially scheduled is needed to integrate subsystems into a complete, working application.
• Late design changes Design flaws that require significant changes to the product are discovered late in the software coding process. Rarely is tangible design validation performed in the project’s early stages.
• Inadequate risk resolution The project’s risks are not resolved until late in the product life cycle.
• Lack of requirement revisions The project’s requirements must be stated and frozen at the first stages of the development process. Often, the project’s stakeholders don’t completely understand the business and product requirements at the beginning of project. With most software projects, requirements are clarified and changed throughout the project, which dramatically increases product cost and delays ship times. If the changes are not integrated into the product, the stakeholders don’t think the product they receive is the one they requested.
• Limited opportunities for input The traditional practice allows a single review process to finalize each project stage. This single opportunity to voice concerns and suggest changes produces an over-sensitized focus on details that can lead to adversarial relationships between project stakeholders.
• Lack of review The first four stages of the Waterfall Model are paper-based exercises, and to prove that the project is progressing, reams of paper may be produced as each stage is completed. As volumes of system documentation are presented, the most understood portions are often the ones that are reviewed, while the more complex portions are simply assumed to be correct.

Spiral Model

• Inception Application planning and analysis
• Elaboration Application design
• Construction Application implementation
• Transition Application assessment and stabilization

Walker Royce in Software Project Management: A Unified Framework notes that each stage typically involves five activity phases: requirements, design, implementation, deployment, and management. The Spiral Model’s process is a continual circle through the stages of development, with each stage requiring multiple revolutions through the five phases. For example, the inception stage may require four iterations through the five RSIDM phases. The development life cycle is designed to define the product more tightly over time so that each iteration brings the product closer to the point of delivery.

Click to view graphic

Figure 4.2 Spiral Model

Like the Waterfall Model, the Spiral Model can run into problems, such as the following:

• Feature postponement Complex features—important to the customer and users—are moved to later iterations of the project. Postponing important features delays and decreases the project’s ROI.
• Never-ending projects Individuals and organizations need to reach closure on projects, but a project can take on a life of its own, with work being done solely for the sake of the project, and not directed toward achieving business goals. If the project’s business goals change after multiple project iterations, there is a tendency for team members to continue to work to get the next feature set completed, without addressing the changed goals. But the changing business goals directly affect the viability of the project, and best practices are often lost if those goals are not addressed.
• Unknown costs The continual iteration, which moves and postpones features, makes feature cost/benefit analysis difficult. The historical costs and benefits of the project are difficult to identify and use for future project justification.
• No sense of stability When systems are in a constant state of flux, the customer and users often feel that the product is unstable. Constant updating requires additional resources for product maintenance and significantly increases product deployment costs.
• Lack of automation Most organizations fail to invest adequate capital in the automation of the software development process. Significant up-front costs for automation and productivity tools are viewed as project expenses rather than capital investment. Without an automated development process, however, the number of iterations required to deliver a product can significantly delay its ship dates. Additionally, when the product is ready for deployment, lack of automated software deployment tools makes it difficult to continually update all users’ computers with new product versions.

Unified Process

One commonly used model for the analysis, design, and implementation of enterprise applications is the Unified Software Development Process (Unified Process or UP). The Unified Process, which requires extensive use of the Unified Modeling Language (UML) modeling, is:

• Use-case driven.
• Architecture-centric.
• An iterative development process.
• An incremental development process.
• Risk-confronting.
• An object-oriented and layered design approach.
• A repository for object-oriented system development patterns, objects, and code.

Workflows

• Requirements The Requirements Workflow is done to gather business, application, and technical requirements.
• Analysis The Analysis Workflow provides business and application modeling derived from requirements.
• Design The Design Workflow uses object-oriented design techniques to complete the application architecture.
• Implementation The Implementation Workflow is execution of the designed work including prototypes.
• Testing The Testing Workflow verifies the proper work has been done.

The next iteration begins the cycle again with the Requirements Workflow. We will briefly summarize the main workflows of the Unified Process.

Requirements

The main purpose of the Requirements Workflow is to aim the iteration toward developing the right application for the customer and users. The underlying goal is to describe the application in enough detail that agreement can be reached between the customer, user, and development team on what the application can and cannot do. Information can be gathered from many sources; the project stakeholders, an existing system, or occasionally an existing requirements document created by the customer.

As the team gathers the information, it develops a list of candidate requirements. These requirements can be structured with a brief name, description, status (proposed, approved, incorporated, or validated), estimated cost to implement, priority, and associated level of risk to implement the feature. The context of the application is also part of this workflow. The Unified Process suggests that the context be described using business modeling or domain modeling. Functional requirements detailing who does what to the application are noted in the use case model. It is also important to capture nonfunctional requirements regarding things such as performance, extensibility, and reliability. These nonfunctional requirements can be tagged to specific use cases as well as appended to the use case model as nonfunctional system requirements.

The team can also deliver a set of UI designs or prototypes that represent the interaction of the roles conducted by the users. Ivar Jacobson et al. summarize the high-level deliverables of the Requirements Workflow as:

• A business model or a domain model to set the context of the system.
• A use case model that captures the functional requirements and the nonfunctional requirements that are specific to individual use cases. The use case model is described by a survey description, a set of diagrams, and a detailed description of each use case.
• A set of user interface sketches and prototypes for each actor representing the design of the user interfaces.
• A supplementary requirements specification for the requirements that are
  generic and not specific for a particular use case.

Analysis

During the UP’s Analysis Workflow, the application requirements are examined and described in the terms of the application’s developers. This description is a refinement and structuring of the functional requirement captured by the use case model in the Requirements Workflow. The Analysis Workflow is an interim step that serves as an abstraction of the requirements and leads to the actual design of the application. Ivar Jacobson et al. summarize the Analysis Workflow as:

• A more precise specification of the requirements than we have in the results from requirements capture, including the use case model.
• An analysis model is described using the language of the developers, and can thereby introduce more formalism and be used to reason about the internal workings of the system.
• An analysis model structures the requirements in a way that facilitates understanding them, preparing them, changing them and in general, maintaining them.
• An analysis model can be viewed as the first cut at a design model (although it is a model of its own), and is thus an essential input when the system is shaped in design and implementation. This is because the system as a whole should be maintainable, not just the description of its requirements.

The high-level deliverable of the Analysis Workflow is the architectural view of the analysis model. This view consists of:

• Analysis classes These consist of border, entity, and control classes. Border classes are situated between the user roles (actors) and the internal working of the application and are often candidates for presentation layer or user services. Entity classes describe long-lived and persistent information. Control classes describe the application behaviors that handle the sequencing, transaction, and control of the application, excluding those described by border and entity classes.
• Use case realization analysis Ivar Jacobson et al. define this as:

…a collaboration within the analysis model that describes how a specific use case is realized and performed in terms of the analysis classes and their interacting analysis objects.

This combination, or collaboration, of use case diagrams and analysis class diagrams depicts their interaction. The team can then determine how to group the use cases by the classes, their objects and iterations.

• Analysis packages These seek to organize the analysis classes, use case realizations, and potentially other analysis packages. They represent the grouping of functional requirements described by use cases. Thus, analysis packages can be based on use cases that support a specific business process, a specific user role (actor), or related use cases noted by generalization or extended relationships.

Design

Following the analysis of the application, the lower-level Design Workflow can begin. The design classes and their behaviors are developed and assigned to one of four layers: standard user interface (presentation view), business, access, and data.

The Design Workflow consists of the following activities:

• Define the structure into subsystems (design model).
• Distribute the subsystems to layers (design model).
• Define the class and object interfaces (design model).
• Mapping active classes into deployment nodes (deployment models).

At the conclusion of the Design Workflow, the application’s architecture is complete. The design model, which is the representation of the application’s physical model, is also complete. Unlike the analysis model, the design model should be maintained throughout the application’s life cycle. The design classes are fully described including their state, properties, and methods, as well as their relationship to other classes.

Implementation

The Unified Process is strongly based on the Spiral Model and features incremental prototyping and development until the development team is satisfied with the product and all required features are implemented. The Implementation Workflow is the actualization of the Design Workflow. There should be a one-to-one correspondence between the design classes and the code that is developed during this workflow. Each class can be compiled into an executable or many classes can be combined into a single executable, depending on the implementation language and analysis package design. The steps for this workflow, which are fed by the Design Workflow, are:

• Implement architectural prototype.
• Implement the components (classes and objects).
• Unit test the components.
• Integrate the components.
• Build the application.
• Derive tests from use cases.
• Evaluate architecture.
• Plan the next build.
• Iterate development.

Testing

The Testing Workflow verifies the expected results against the actual results of the Implementation Workflow. Testing is conducted upon conclusion of the Implementation Workflow regardless of whether the iteration’s release is internal, intermediate, or external. Through each iteration, the testing model is refined to remove obsolete test cases, generate regression test cases, and create new test cases for future builds. Test cases specify a particular way of validating the application including the conditions of the test, the required input, and expected output. Test cases should be derived from use cases. In addition to testing the application as a whole, further test cases should be executed to verify the installation on the given application platform and verify the application is correctly configured. Finally, test components can be developed to automate the execution of the test cases.

Project Phases

• Inception Phase iterations focus on producing the business case.
• Elaboration Phase iterations are responsible for developing the baseline architecture.
• Construction Phase iterations focus on creating the product with incremental releases of product builds and features.
• Transition Phase iterations ensure the product is ready for release to the user community.

Requirements and the analysis, design, and implementation architecture represent the majority of the work within the Inception and Elaboration Phases. The completion of each phase describes the application in a level of detail using the Unified Process models. In addition, movement from one phase to the next is the result of accomplishing the goal for the phase and reaching the milestone for the phase. At each phase’s major milestone, a critical go/no-go business decision is made about whether the project should continue, thus approving the next phase’s requirements for budget and schedule. These major milestones are the synchronization points between the technical portions and business portions of the project.

Inception

Although no specific number of iterations can be associated with the Inception Phase, typically this phase does not exceed two workflow iterations and relies primarily on the Requirements Workflow. The Inception Phase is defined strictly by its goals, which are to set the scope of what the product should do, reduce the probability that the worst project risks will materialize, and prepare the project justification via the initial business case. The four steps used to make the business case are as follows:

• Delimit the scope of the proposed system This is the identification of the applications boundaries and its relationship to other systems.
• Describe the candidate architecture These contain more detail on the new, difficult, or risky portions of the application with the goal of creating confidence that the team can create a stable architecture.
• Identify the critical risks In addition to simply identifying the risks, a management plan is created to mitigate the risks at the appropriate time.
• Demonstrate that the proposed system is capable of supporting the business case An application prototype along with the initial use case can generate this agreement from the application’s customer and user.

The Inception Phase’s milestone is the Life-Cycle Objective Milestone.

Elaboration

Like the Inception Phase, the Elaboration Phase is typically limited to at most two or three workflow iterations. The Elaboration Phase maintains a focus on "do-ability." The primary goals of this phase are to deliver the application architecture baseline, to estimate in some detail the cost and the schedule, and to plan for the Construction Phase. The main steps of this phase are as follows:

• Create an architectural baseline This covers significant functionality and features important to the project stakeholders.
• Identify significant risks These should take into account the plan, its cost, and the schedule of later phases.
• Specify quality attributes These include reliability, defect rates, and performance (response times).
• Capture use cases These should include 80 percent of the functional requirements.
• Prepare a project bid This encompasses the schedule, staff requirements, and cost within the limits set by business practices.

The Elaboration Phase’s milestone is the Life-Cycle Architecture Milestone.

Construction

In relation to the other phases, the Construction Phase consumes the longest time period and requires the highest resource requirements. It also requires the greatest number of workflow iterations. The Construction Phase is focused on creating the application. Its primary goal is to complete development of the application and ensure that it can begin transition to customers. This transition means the application has achieved initial operational capability and is ready to begin beta testing. Incremental development provides ongoing feature releases with each additional application build. The Construction Phase activities include the following:

• Extend use cases This includes identification of details, descriptions, and realization for all use cases.
• Finish the first three workflows The Analysis, Design, and Implementation Workflows should be completed.
• Start testing About 15 percent of the Testing Workflow should be completed.
• Maintain the integrity of the architecture Changes and updates should be carried out as needed, but within the context of the application’s architecture.
• Manage risks Continue managing the risks identified in the earlier phases.

The Construction Phase’s milestone is the Initial Operation Capability Milestone.

Transition

The Transition Phase is denoted by the initial beta release of the application to the customer and limited release to the user community. The two primary goals of this phase are to ensure that the product is ready to be released and to train users how to use the product. The additional burden placed upon the application by the user community and the application’s true environment provides the necessary testing to determine whether the development process has reached its final milestone: the Product Release Milestone. The Transition Phase activities can include the following:

• Prepare for deployment This includes environment and site preparation and advising the customer on necessary environment updates.
• Prepare documentation This includes operation, user, and other manuals that will accompany the product when it is released.
• Tune the application The product must be prepared for the production environment.
• Correct defects All bugs found during the beta tests must be addressed.
• Modify the application The software might need modification to accommodate problems that were unforeseen earlier in the process.

Iterations

Click to view graphic

Figure 4.3 Workflow emphasis over the project life cycle

Additionally, heavy emphasis is placed on managing the project and creating a development environment during the Inception and Elaboration Phases.

Over the course of time, the amount of detail displayed within each Unified Process model grows, and the models are gradually completed. Figure 4.4, which is also based on a diagram in The Unified Software Development Process by Ivar Jacobson et al., shows that the six primary Unified Process models are almost complete by the end of the Construction Phase, though some fine tuning is usually required to finish the models during the Transition Phase.

Click to view graphic

Figure 4.4 Detailed model completion over the project life cycle

Ivar Jacobson et al. also note that the important consequences of a Unified Process iterative and incremental approach are as follows:

• To make the business case in the Inception Phase, the organization has emphasized reducing critical risks and demonstrating proof-of-concept.
• To make a business-worthy bid at the end of the Elaboration Phase, the organization has to know what it is contracting to build (represented by the architecture baseline plus requirements) and be confident that it contains no hidden risks (i.e., insufficiently explored cost and schedule expanders).
• To minimize costs, defects, and time-to-market, the organization has to employ reusable components (an outgrowth of early architectural development based on study of the domain in which the proposed system falls).
• To avoid delivery delay, cost overrun, and poor-quality product, the organization has to "do the hard stuff first."
• To avoid building a product that is out-of-date at delivery, the organization can no longer stubbornly say no to all changes. The phased, iterative approach enables it to work changes into development much further along the development trail.

MSF Development Process Model

With the Waterfall Model, a project progresses through sequential steps, from the initial concept through system testing. This model identifies milestones along the course of the project and uses them as transition and assessment points. This approach works well for a project in which requirements can easily be specified at the beginning, but may not work well for a complex project where requirements can change during the project’s life cycle. Additionally, practitioners of this model rely heavily on volumes of documentation and a single review process for each stage. These two Waterfall practices usually lead to overextended "analysis paralysis" and adversarial relationships between developers, customers, and users.

Using the Spiral Model, the application evolves over a number of iterations. Early passes through the Spiral life cycle provide increasingly tight definitions of the product, with middle and later iterations adding features and functionality to the application. The Spiral Model seeks to confront project risks early in a software project and address them in early product releases. Due to its iterative nature, the Spiral Model supports creative adjustments along the way, thus evolving and hopefully improving the quality of product. The highly iterative Spiral process requires significant amounts of process and documentation automation to become efficient. In practice, customers and users may develop a general sense of instability because the product can change too rapidly for them to grasp. Finally, many Spiral projects lack a known ending point, so they continue to iterate indefinitely with no financial or business end within site.

As shown in Figure 4.5, the MSF Development Process Model combines the strengths of these two models, providing the benefits of milestone-based planning from the Waterfall Model and the benefits of the iterative creative process from the Spiral Model.

Click to view graphic

Figure 4.5 MSF Development Process Model

The MSF Development Process Model has three primary traits:

• A phased process (the four wedges of the diagram in Figure 4.5).
• A milestone-driven process (the diamonds separating the phases).
• An iterative process (the process arrow aiming back into the first phase).

Although Figure 4.5 shows the four phases as quarters, the phases do not necessarily require equal amounts of time to complete. Different business and technological environments will require different time and resource ratios for the various phases.

Phased Process

• Envisioning, which must produce a shared vision.
• Planning, which must produce a detailed project plan and application architecture.
• Developing, which must produce a well-built, complete product.
• Stabilizing, which must produce a stable, deployed product.

Milestone-Driven Process

The MSF Development Process Model uses two types of milestones: major milestones and interim milestones. Each milestone, whether major or interim, is marked by one or more deliverables. Deliverables are physical evidence that the team has reached a milestone.

Major Milestones

Each phase of the development process culminates in an externally visible major milestone. Externally visible means that the milestone and its deliverables are visible to entities outside the project team, such as the customer or operations personnel.

A major milestone is a point in time when all team members synchronize their deliverables. Additionally, those external to the project team such as the customer and users; operations, support, and help desk personnel; the distribution channel (commercial software); and other key project stakeholders, should be updated on the project status.

A significant role of major milestones is to allow for a stage-by-stage assessment of the project’s viability. The project team and the customer, having reviewed the deliverables for the current phase, jointly make the decision whether or not to move into the next phase. Thus, major milestones serve to move the project from one phase to another.

Interim Milestones

Within each phase of the MSF Development Process Model are various interim milestones, which, like major milestones, are review and synchronization points, rather than freeze points. Unlike major milestones, however, interim milestones are internally visible—that is, visible only to members of the project team.

Interim milestones indicate early progress and break large work assignments into smaller pieces that are easier to address.

Versioned Process

The Four MSF Phases and Their Major Milestones

Envisioning Phase

• A mutual understanding of the business needs being addressed Many times, developers build an application for a customer (either internal or external), only to discover upon completion that the application solves the wrong problem. This situation arises for a variety of reasons, including poor communication by the customer or poor understanding by the developers. It’s critical that the project team members understand the business needs thoroughly before attempting a solution.
• Clearly identified solutions that meet the customer’s expectations Devel- opers often deliver a solution and then learn too late that it is not the solution the customer expected. In today’s rapidly evolving computing world, customers are more technologically sophisticated than in times past and may have certain solutions in mind before the project begins. Part of the purpose of the Envisioning Phase is to make certain the customer communicates any specific expectations early in the project. As discussed in Chapter 3, this setting and resetting of the customer’s expectations is the primary responsibility of Product Management.
• A solid estimation of the project constraints During the Envisioning Phase, the critical project variables—schedule, resources, and features—begin to take shape. In this phase, team members may have only a general idea about these project variables. For example, they may create schedules in terms of quarters or fiscal years instead of weeks or months.

Defining the variables more exactly and establishing their triangulated balance is an iterative process. As analyzing, prototyping, and planning activities proceed, the team may revise the scope because of:

• A better understanding of user requirements.
• A change in business requirements.
• Discovery of technical issues or risks.
• Tradeoffs among the project variables (schedule, resources, and features).

By creating a broad but intuitive view of the project’s goals and constraints, the Envisioning Phase begins to define the scope of the project, and sets the stage for the more formal and detailed planning effort that will come later, in the Planning Phase.

Vision Approved Milestone

The Envisioning Phase culminates in the Vision Approved Milestone. This first milestone represents the point at which the project team and the customer agree on the overall direction for the project, including what features and functionality the product will and will not include.

Reaching this milestone meets one of the most fundamental requirements for project success—unifying the project team. The team must have a clear vision of what it wants to accomplish for the customer, and must be able to state that vision in terms that will motivate both the team members and the customer.

The deliverables of the Vision Approved Milestone are:

• A Vision Document.
• A Master Risk Assessment Document.
• A Project Structure Document.

We also recommend that a prototype system be included with the deliverables for this milestone.

As explained earlier, the completion of major milestones results in a synchronization between the customer and the project team, and provides an opportunity for determining whether or not to proceed. Smaller function teams, as described in Chapter 3, must also synchronize with the main project team at major milestones. The Vision Approved Milestone is the first point in the process where the individuals involved may decide that the project does not make sense and should not continue. It is imperative that everyone agrees to move forward at this point in order to prevent misunderstandings later in the project. The creation of application prototypes during the Envisioning Phase can help the team reach a clear understanding of the product vision.

Vision approval signals that members of the project team, the customer, and key stakeholders agree on:

• A broad understanding of the business needs that will be met by the product.
• The vision of the product.
• The design goals for the product.
• The risks that may be incurred by undertaking the project.
• Program Management’s initial concept of the business solution.
• How the project should be run and who should be part of the team.

In summary, the true goal of the Envisioning Phase is to create a clear consensus on the product vision between all team members and project stakeholders. Once the product vision is understood, the team and stakeholders can agree and commit to it. Understanding, agreement, and commitment to the vision will place the team in an excellent position to move into the Planning Phase.