Back Up Next

Chapter 2: Using the Team, Process, and Application Models for Development Projects

Certification Objectives. 1

Creating Small Interdisciplinary Teams. 2

Fundamental Roles in a Project Team.. 2

Key Goals for a Project Team.. 4

The Relationship between Project Team Roles and Key Goals. 5

Scaling the Team Model 6

Interteam Dependencies. 6

The Four Externally Visible Development Milestones. 8

Making Project Tradeoffs: Setting Priorities with a Customer 9

Multiple Versioned Releases for Large Projects. 11

From the Classroom.. 12

Defining the Application Model 12

Services-Based Architecture. 13

Sharing Assets, Resources, and Skills. 15

Achieving Parallelism during the Development Process. 16

Certification Summary. 17

Two-Minute Drill 17

 

Certification Objectives

·       Understanding Microsoft's Team Model

·       Understanding Microsoft's Development Process

·       Identifying Common Service Needs Across Development Projects

·       Completing Different Phases of a Project in Parallel

Organizing a project, and the people to complete it, can be a grueling task. The Microsoft Solution Framework (MSF) aids in this endeavor with models that outline the organization of a team, their goals, and the process of development. In using these models, a project team is able to see what they’re responsible for, what progress they’re making, and what they’re working toward.

In this chapter, we will cover the team, process, and application models. The team model breaks a project team into different roles, with each responsible for meeting a particular goal. The process model breaks the project itself into different phases, allowing team members to see where a project is going, and what progress has been made. Finally, we’ll discuss the application model, which breaks the actual application into different parts. By separating these large tasks into smaller parts, we will see that projects become more manageable and understandable.

Understanding Microsoft's Team Model

When you think of a team, you might think of a group of people who work toward a common goal. In Microsoft’s team model, this isn’t the case. Instead, it is made up of six different roles, each with its own goal. As we’ll see, by achieving these individual goals, the success of the project is ensured.

It is important to remember that the team model isn’t an organizational chart. It doesn’t define a hierarchical reporting structure. What it does do is identify the different roles, responsibilities, and goals that go into making a project work.

Creating Small Interdisciplinary Teams

You’ll remember the old saying that “too many cooks spoil the soup.” The same can be said for teams. When you have a large team, all sorts of problems arise. Confusion can result on the status of a project, the lines of responsibility, and elements of a project can be overlooked. It’s also not uncommon for a couple of people to duplicate work, because one person doesn’t know what the other is doing. This can easily be remedied by breaking a large team into small, interdisciplinary teams.

When a team exceeds ten or more members, it is recommended to break them into specialty teams. Each smaller team focuses on a specific goal, and is responsible for different tasks. Members are assigned to each team based on their expertise in specific areas, and are accountable for the quality of results in that area. Since these teams work parallel to one another, productivity increases because efforts are synchronized. It also results in a better product because teams are held accountable for results, and can clearly see the project goals.

Fundamental Roles in a Project Team

A project team is made up of six different roles. By placing people in roles that best match their skills, the quality and chances of success for a project dramatically increases. The fundamental roles in a project team are as follows:

·       Product management

·       Program management

·       Development

·       Testing

·       User education

·       Logistics management

Each role has different responsibilities, requires different expertise, and works toward a different goal. When team members succeed in these roles, the project itself succeeds. Team leaders can focus on managing, coordinating, and guiding the team, while team members can focus on achievement in their individual missions. In this section, we’ll discuss each role, and see how they work on different areas to ensure the success of a project.

Product management has a position of advocacy between customers who buy a product, and the team that creates it. To the customer, a product manager represents the team. To the team, a product manager acts as a customer representative. By representing one group to the other, product management clarifies what the customer wants and what the team can do. Thus, a shared vision of the project is created.

When product management represents the team, it has the primary responsibility of managing customer expectations. If the team feels that certain features won’t be available until future versions, it falls on product management to let people know. This includes not only briefing customers, but also keeping senior management apprised of the team’s assessment of product requirements in order to complete a project successfully. If the product falls short of what’s expected, the project is considered a failure.

When product management represents the customer, this role has several responsibilities. First, it is responsible for obtaining the requirements of customers, and maintaining these requirements. This determines the needs of the customer, so that the product solves whatever business problems a customer is having. Once the customer requirements for a solution are understood, a business case is developed and managed.

A business case is a plan of action that’s presented to senior management. Once a proposal has been made for a product or service, a business case is developed to back up that proposal with facts and evidence. It consists of the following:

·       analysis of the customer’s business need

·       a proposed solution to the business need

·       alternative solutions that were considered but rejected, and why

·       quantitative and qualitative benefits of the proposed solution

The business case is maintained and modified as the project develops. Any changes are added to it, so the business case remains up-to-date and consistent with the project’s progress.

Program management takes the requirements outlined by product management, and turns this information into a functional specification and master project plan. The functional specification determines what is to be created, and the master project plan specifies how it will be done. In making the functional specification and master project plan, program management receives input from each of the other team roles. Though it promotes input from the other team roles, program management makes the final decision in cases where everyone can’t come to an agreement.

Program management holds responsibility for owning and driving the schedule and budget of a project. It also determines when to release the right product or service. By having ownership of the schedule and budget, program management makes sure that money is well spent and schedules are on track. Schedules are developed from estimates provided by each of the other roles. Since program management is responsible for the budget and schedules, it controls what features will appear in a particular version of a program. This keeps a function or group of functions from making a project going over budget or past its delivery date.

Development is in charge of building the product or implementing a particular service. This is done with adherence to the customer requirements and the specifications determined by program management. This role takes the functional specifications, and delivers a product or service that complies with them. Development offers input on designs, develops prototypes, and evaluates available technologies to be used. When and while this is done, development codes the different parts of a product, until it is finally built. Since it has first-hand knowledge of all this information, this role provides estimates of what’s needed to deliver the product on a particular design.

Testing determines what problems exist in a product or service, so that these issues are addressed before it is delivered to a customer. This is by no means a random process. Schedules are created to specify when an area of the product will be tested. One day might consist of finding problems with documentation, while another is spent seeking out erroneous code. Strategies and plans are created to find defects, bugs, and errors in the product. This means that issues dealing with a particular product are known and addressed before it is released. In doing so, the problems can be fixed or workarounds can be developed.

User education has the responsibility of representing the end user. This is different from product management’s role of representing the customer—while the customer buys the product, it is the end user who actually uses it. It is user education’s role to ensure that an end user has a good experience with a product. In the grand scheme of things, user performance must be enhanced in some way by the product. To meet this goal, this role helps ensure that the product is easy to use and understand. For example, if a user interface is difficult to use, user education steps in to help make it more manageable for the end user. This role is responsible for designing, creating, and testing materials that assist the user. Online assistance, manuals, wizards, and training materials fall into the realm of user education.

Logistics management is responsible for deployment and product support. This role ensures a smooth rollout, and makes sure that deployment is possible. Installation programs must work correctly, and installation sites are checked so they fit the necessary requirements for deployment. Logistics management has to understand the infrastructure of a product, so they can provide training to operations and the help desk. By providing this information, support groups are able to assist the customer and end user.

Key Goals for a Project Team

Key goals help to focus and drive the team. They define what everyone is working toward, and as we’ll see in the next section, help to define the team model itself. No matter what your team role, there is that key goals outline what everyone is working toward, and ensure the quality of a product. These goals consist of the following:

·       Deliver within the constraints of the project.

·       Deliver to specifications that are based on user requirements.

·       Satisfy customers.

·       Enhance user performance.

·       Release only after knowing and addressing all issues.

·       Ensure smooth deployment and ongoing management.

As we explore each of these goals, it quickly becomes apparent that if each of one isn’t met, the project will not be successful.

Delivering within constraints is a broad area that varies with each project. There are certain constraints that are constant in any project: time and money. Every project has a budget and schedule that must be kept. Imagine a software project for creating income tax returns. If it went past schedule, and was released at the end of May (a month after returns are due), the project automatically fails. A real-life example is Allstate, who in 1982 began a five-year, eight-million-dollar project to automate their office operations. A year after this deadline, the project’s cost was $15 million, and it still wasn’t finished. It was given a new time constraint, and the budget was readjusted to $100 million! Even though other goals may have been achieved, by not delivering within the constraints, the project itself failed.

“Always give the people what they want” is what delivering to specifications is all about. Product specifications provide detailed descriptions for project requirements. Let’s say a company hired you to create a business application that accesses dBase files. As an extreme example, suppose you decide that Access databases are better, and create the program to access those instead of dBase files. The product specifications wouldn’t be met, and you’d lose a customer and your reputation in one fell swoop. Product specifications are based on user requirements, and it important for a team to meet those specifications as closely as possible. If a product isn’t delivered to specifications based on user requirements, the success of the project is sacrificed.

Meeting the specifications falls hand in hand with another goal: customer satisfaction. Customer satisfaction means that the user gets what they expect from a product, and that it solves a targeted problem. If the customer is expecting a number of features in a product, and all features don’t appear in the current version, it is important to inform the customer so they won’t be unpleasantly surprised. This can be done through public relations, marketing, demonstrations, and promotions for launching the product. Always put the user first, and keep customer satisfaction a priority.

Enhancing user performance is the reason computers exist in business. Excluding entertainment, it’s also the reason why people pay thousands of dollars for computers and software in their homes. If a project doesn’t enhance the work or productivity of a user in some way, there was really no reason to start it in the first place. A project can be full of features and content, but if it doesn’t do the job intended, it’s a failure.

Nobody’s perfect, so it follows suit that projects won’t be either. All software contains defects, but it is important to release only after knowing or addressing all outstanding issues. This allows you to do one of two things: fix the problem, or have a workaround solution that can be added to documentation. Fixing the problem is preferred, but may not always be possible while keeping to the schedule. In such cases, you should offer a workaround, and add it to documentation. This keeps teams and customers from being blindsided by a defect. The worse thing to do is not to provide a fix or workaround, and leave the defect unidentified. By offering at least a workaround solution, the customer can use the software until a bug fix, patch, or new version is released.

Smooth deployment and ongoing management is an important part of the success of a project. All too often, applications are dumped on the end user with little or no support. Installation programs can fail, giving the user the impression that the application itself is defective. If they require assistance, they are faced with the dilemma that the only support available is in the form of ineffective help files, if even that. It is important that the deployment process is smooth, enabling the user to access and install the application with few if any problems. If they do experience difficulties, ongoing management is there to assist them. It is important that training, infrastructure, and support are already in place before the deployment of a project, so they can deal with project and user problems.

The Relationship between Project Team Roles and Key Goals

There is a correlation between the various team roles and the key goals outlined in the previous section. Each goal maps to a different role, allowing team members to focus on the particular goal that relates to them. The six goals shape the team roles, and focus team members on what they are working toward.

Each team becomes responsible for the goal that relates to them, as outlined in Table 2-1. This allows every member of a team to have ownership of product quality, so that quality-related issues are addressed before projects reach the customer. Team members thereby become accountable for the success or failure of a goal that relates to them.

Team Role

Key Goal

Product Management

Satisfied customers

Program Management

Delivery within project constraints

Development

Delivery to product specifications

Testing

Release after addressing all issues

User Education

Enhanced user performance

Logistics Management

Smooth deployment and ongoing management

Table 1: How Team Roles Map to Team Goals

Exam Watch: The team roles and their related key goals have a symbiotic relationship. It is important to understand how one maps to the other, if you are to understand the purpose of each team role.

Scaling the Team Model

Now that we’ve established the roles and goals of a project team, the following question usually arises: what if you don’t have enough people to fill each role?  This is often an issue with smaller companies or smaller projects. Just because you don’t have six people doesn’t mean you can’t use the model. It is important that each goal is represented, not that each role is filled by a different person.

Assigning more than one role to a person can scale the team model. By having members share roles, each goal is pursued, and the project can achieve the same success. There are, however, two important things to remember while doing this:

·       Development members should never be assigned extra roles.

·       Never assign members conflicting roles.

It is wise to never give an extra role to development for one reason: they are in charge of building the product, and you don’t want to sidetrack them on other duties. It is also vital that you never give a member two roles that have a conflict of interest, or where the skills of one role are completely different from the other. For example, you wouldn’t want to combine logistics and product management because the expertise for each is so different. Similarly, program management and product management would make a poor match due to conflict of interest. Product management represents the customer, while program management is responsible for the schedule and budget. If a customer made a request for a feature, it probably wouldn’t be properly considered if it interfered with the budget or schedule. Similarly, the budget or schedule would be put over the top to fulfill a customer request.

By reviewing the goals of each role, you can determine how a member can share roles. By determining the expertise of a member, and assigning two similar roles, the team model is effectively scaled down.

Interteam Dependencies

As mentioned earlier, for a project to be successful, it is important that each goal be achieved. In this approach, there are teams of peers, who are dependent upon one another to complete the assigned project. This requires communication and cooperation between the different roles.

If one team role—or more specifically, a single goal—were not assigned to someone, the project itself would fail. Program management relies on product management to supply the customer requirements and set the vision for a project. Development needs the functional specifications to build the project, and testing needs the built product to check for defects. Development relies on testing to enhance user performance, and logistics is required so that the product has a smooth rollout. In short, you need to achieve point A to move to point B before you can achieve point C. Each team role relies on another, making the team model symbiotic in nature.

In addition to the interdependency of the team roles and goals, there are dependencies to external groups. For example, product management relies on the customer to provide requirements for a project, while user education has a dependent relationship with the end user. Remember that customers and end users aren’t necessarily the same group. Customers buy a product, while end users are the people who actually work with the product. As seen in Table 2-2, most roles are interdependent with external groups.

Role

External Group Dependency

Reason

Product management

Customer

Senior management

Relies on customer to provide requirements, and manage customer expectations. Also works with senior management, technology, and business architects, and steering committees to meet customer requirements.

Program management

Customer

Creates functional specifications that meet the customer requirements.

Development

None

To avoid disruptions in work, which could compromise product quality.

Testing

None

To avoid disruptions in work, which could compromise product quality.

User education

End user

Ensures user’s experience is enhanced by the product.

Logistics management

Operations and support groups

Trains support groups (such as help desk) and operations. Ensures smooth rollout and installation.

Table 2: Interdependency of Team Model with External Teams

Development and testing are internally focused, so they have no external interdependency with other teams. This keeps the two roles from being distracted from their roles of building and testing a product for defects. By keeping the two roles insulated, they are able to focus on their work without having to worry about outside interference.

Understanding Microsoft's Development Process

While the team model shows who does what, process deals with how things will get done. Process deals with the methodologies of technology and management. It shows the activities in an application’s life cycle, from the time of conception to its initial release. By going step by step through the development cycle, process allows the project team to see their progress as tasks are completed.

If you’re a developer who’s experienced a process model in the real world, you may be wincing as you read this section. While the purpose of process is to focus a team on relevant issues in the development cycle, bureaucracy often gets involved to the point where a team is bogged down by red tape. Rather than addressing priorities in a project, everything seems to have a policy attached to it, and developers are faced with having to address mundane issues. To keep this from happening, Microsoft’s process model balances creativity with distinct milestones to mark the completion of different phases of a project.

A milestone not only marks the point where one phase of a project ends and another begins, it also indicates the point in time that members of a team should synchronize their efforts. Each milestone is customer oriented, and is a point where team members can see if they are still meeting customer expectations. If the customer requirements change during a step in the development process, the team members can discuss and deal with the change. If a new risk to the project has arisen, that too can be dealt with when a milestone is reached. This keeps projects from getting too far into development before problems are addressed.

The MSF process model is based on two proven models: the waterfall model and the spiral model. The spiral model is also called the rapid application development (or RAD) model. It breaks a project into sub-projects, each of which deals with different risks in a project. Since each risk is addressed in the sub-projects, all risks in a project can be identified individually. The waterfall model views the life cycle as a flow of steps. When one step ends, a milestone is reached. The milestone indicates that the step is assessed, and the next step begins in the development process. By combining these two models, Microsoft’s process model allows a team to manage risks while focusing on results.

The MSF process model breaks a project into four phases with each phase resulting in a definitive milestone:

1.     envisioning, which results in the vision/scope approved milestone

2.     planning, which results in the project plan approved milestone

3.     developing, which results in the scope complete/first use milestone

4.     stabilization, which results in the release milestone

Each of these phases, and their related milestones, are described in detail in the next section. They represent the state between milestones, which is also where the work is done to achieve a milestone.

The Four Externally Visible Development Milestones

There is a direct relationship between each of the four phases in the process model and the four development milestones: you must complete a phase of the model before reaching a milestone. If you think of developing software like waging a war, each phase is a battle. When you win the battle, you have achieved a milestone—when you win all the battles, you’ve won the war. Rather than focusing on an overwhelming big picture, the four phases and their respective milestones allow you to keep your sites on the immediate battle for success.

The envisioning phase comes first in the process model, and results in the vision/scope approved milestone. This phase answers the question: “What do you see us doing?” It involves understanding a customer’s needs and the issues surrounding those needs. What issues are driving the need for the product or service, and what features should be incorporated to address future needs? By gathering information, and understanding the needs of a customer, the vision/scope approved milestone can be achieved.

The vision/scope approved milestone results when an agreement is made on the direction a project will take. To understand what this milestone represents, it is important to understand the meaning of vision and scope. Vision is an unbridled view of a project’s goals, with no consideration given to the constraints of a project. Scope reigns this in, by defining the limitations of a product or service, and determining what can be done within the project’s constraints. By balancing these optimistic and realistic viewpoints, a shared vision of what the project entails is achieved. This shared vision is outlined in a vision statement or vision/scope document, which specifies the direction and goals for a project.

The second phase of the process model is planning. There is usually some confusion between the planning phase and the envisioning phase, because it seems there is considerable amount of planning involved in envisioning a project. As far as Microsoft is concerned, planning is when the project team and customers come to an agreement on what will be delivered and how it will be built. It is here that the priorities and expectations for a project are set.

 The functional specification is created during this phase. Each team submits its plans to create the functional specification and schedule for the project. It is during the planning phase that risks are reassessed, priorities are set, and estimates for schedules and resources are made. The functional specification, its associated project plan, and the schedules are used in the next phase of the process model.

The result of the planning phase is the project plan approved milestone. This is basically a contract between the team and customer to go ahead with the project. Once all the details have been ironed out, the interested parties agree to continue with the project.

Exam Watch: Remember that the envisioning phase is where a common vision is set for a product, while the planning phase is where an agreement is made on what will be built and how to build it. If you think of a marriage, a common vision is created before both parties say, “I do.” While the envisioning phase envisions what will happen, the planning phase is where the vows are made, and a go-ahead to continue is given.

Third in this lineup is the developing phase. In the life cycle of an application, it is here that a product begins to reach maturity. The functional specification and project plan are used by the development team as a baseline to focus on developing the actual product. Rather than building the product in one shot, the development team uses the developing phase to go through a number of cycles involving testing, debugging, and fixing the product. When it is determined that the product is ready for stabilization (the fourth and final phase), the scope complete/first use milestone is reached.

The team and customers get together at this milestone, and reviews a number of key issues for the product:

1.     First, the product functionality is evaluated to make sure it does what it is intended to do. If certain features weren’t included in the current version, they are documented so they can be implemented in future versions.

2.     Rollout and support plans are reviewed to make sure operations and support personnel will be ready for product release.

3.     Finally, the team and customers address any additional issues before preparing to ship the product.

After the scope complete/first use milestone, the development life cycle enters the stabilization phase. It is here that product testing is done, allowing bugs to be found and fixed before the release. When testing is complete, the project team hands over the product or service to operations and support. It is this handing over of the torch that marks the release milestone. The product is shipped, put into service, and operations and support will now have the responsibility for managing and supporting the current version.

Making Project Tradeoffs: Setting Priorities with a Customer

Every project has to work within the constraints of time, resources, and the features requested by a customer. Early in a project, this is usually manageable. The customer outlines the features, schedules are created, and resources are organized. Unfortunately, there are always moments when a customer wants something added to a project, a critical feature was overlooked in the initial design, or some other problem crops up. When this occurs, tradeoffs need to be made if a project is to come in on time and within budget.

Tradeoffs are a matter of realizing that a project plan isn’t concrete, and deciding what needs to give. There is no way you can keep the vision of a project so rigid that nothing can be traded off to meet new requirements or constraints. When tradeoffs are made, it is a matter of adjusting one element of a project to allow change in another element.

A project has three elements that are interrelated: schedule, features, and resources. The schedule is a timetable with dates that define when parts of a project are due, and when the finished product or service is due to be completed. Features are the requirements to be implemented into a product or service, and the quality and functionality of these items. Resources include such things as the people who work on the project, the technologies they work with, and the money available to use on a project. When working with these three elements of a project, changes in one element have a direct impact on at least one of the other two.

As shown in Figure 2-1, the three elements of a project have a triangulated relationship. Like three separate lines that make up a triangle, the three elements make up a project. Altering the size of any element will effect one, and usually two, of the other elements. For example, if a customer requires features to be added to a project, then the schedule must be adjusted so there is enough time to incorporate these features. Since time is money—and people like to get paid for their work—resources will need to be adjusted as well. If the due date cannot be altered, then more people and money will need to be infused into the project. As you can see, one element cannot be changed without directly affecting one or both of the other elements.

Figure 1: Triangulated relationship of project elements

To establish priorities in a project when dealing with tradeoffs, a tradeoff matrix can be created to determine a strategy. This allows the team and customer to specify whether it is more important to stay on schedule, on budget, or to pass certain features off to future versions. A tradeoff matrix is simply a table that is used as a reference tool. By sitting down with the customer, the team management is able to agree on which elements take priority over others.

An example of a tradeoff matrix is illustrated in Table 2-3. A checkmark is placed in one of the blank cells to indicate that a particular element should be optimized, constrained, or accepted as a tradeoff. It is important that at least one of the three elements is accepted as a tradeoff, so the team has the power to control risks and changes in a product. As we’ll see in the following paragraphs, where a checkmark appears in the matrix determines what strategies will be used to complete the project.

 

Optimize

Constrain

Accept

Resources

 

 

 

Schedule

 

 

 

Features (Scope)

 

 

 

Table 3: Tradeoff Matrix

The Resources row determines how money will be used in a project, which affects people and technologies. Remember that people on a project need to be paid, and computers and software will need to be purchased or allocated to these people. Whether resources are optimized, constrained, or accepted determines whether one of the following strategies will be used:

·       minimum cost strategy

·       not-to-exceed strategy

·       time and materials strategy

A minimum cost strategy is used when the Optimize column of resources is checked. This means that the allocation of resources should be kept to a minimum, so that costs don’t go too high. A not-to-exceed strategy occurs when the Constrain column is checked, meaning there is pressure to keep within the budget. A time and materials strategy occurs when the Accept column is checked, giving the team power to control risks and changes in a project by adjusting resources.

The Schedule row is used to control the ship date of a product or service. When the Optimize column of the matrix is checked for this element, an early-to-market strategy is used. This strategy sets declares that the ship date for the product or service is to be as soon as possible. When the Constrain column is checked, the schedule is kept to a specific time frame so that the ship date isn’t altered. When the Accept column is checked, a tradeoff is made with the ship date, and it is accepted that the product will not meet its previous due date for release.

The Features (Scope) row is used to establish which features will be released for a current version. When the Optimize column is checked, a maximum benefit strategy is used, and it is accepted that as many features as possible will be shipped with the current version of the product. When Constrain is checked, the scope is to ship the features that are essential for the product to function. When Accept is checked, it’s acknowledged that a tradeoff needs to be made here, and features are dropped from the current version.

Multiple Versioned Releases for Large Projects

Multiple versioned releases boils down to this rule of thumb: you can’t do everything at once so don’t even try. Is it a defeatist attitude? Not at all—it’s just common sense. It’s not uncommon for projects to be held up for a great new idea that just has to be included. The problem is that there’s always something more that could be added.

When the first versions of Microsoft Windows appeared on the market, it was just a graphic interface that ran on top of DOS. If you didn’t like typing commands, you could run Windows and just point and click to run a program. There were a number of other programs that did the same thing, but have since faded into obscurity. Bill Gates could have held back on releasing the first Windows—making an actual operating system, adding utilities and features to infinity—but chances are Microsoft would then have become a footnote in computer history. There is high competition in software development, and it is important to get your product to the customer before someone else beats you to it. Versioned releases allow you to get a product to market, and have new features added in future releases.

The current version of a product should meet the current needs of the user. Users are then able to enjoy the functionality of a program, while new releases are being developed. In addition, users are able to grow as the application grows. Rather than being hit by a monolithic program, they are able to adapt as new features are added and old ones are retired. By incrementing a program in versions, you can address the most important requirements of the user, with additional features being added later, and still be first to market.

Identifying Common Service Needs Across Development Projects

With the amount of downsizing occurring in the business world, employees are expected to take on a wider range of responsibilities in their jobs. No longer are people limited to specialized job descriptions that deal with a limited number of duties. As such, there is an equally growing need for business applications to perform more tasks, and provide consistency in the way users view, locate, and modify information in applications.

To meet these needs, the application model has been created. This model aids developers with the structure and standard design of applications. It aids developers in creating a service-based architecture for programs. This model breaks an application into a network of services. By communicating with one another, each service in an application exposes its attributes to other services. As we’ll see, this promotes the use of components in applications and these components can be reused across development projects.

From the Classroom

By Design

One of the most difficult tasks in making the transition to the use of proper design methodology involves the correct and proper separation of resources prior to implementing the designing or coding phases. One could safely venture to say that the area of design methodology that receives, unfortunately, the short end of the resource stick is that of design itself. Many developers have a tendency to try to rush into the implementation phase, expecting their vision of the final product to hold up; hence any additional headstart that can be achieved is bound to be beneficial. Oh, such wisdom!

Following this error in ways, the typical developer seeks to skip past, or handicap, the second process, planning, within the Microsoft Solutions Framework process model. After gaining what is necessary from the envisioning process, the planning process is often shorted, or concluded prematurely, so that the developing process can proceed. Take special care to avoid this, to the ultimate benefit of the project as a whole.

Besides the process model pitfalls, the application model is also a common source of misunderstanding. The distinction between the layers is often fuzzy, leading to misguided design initiatives. Lacking a full understanding of the rationale behind the separating of the services can lead to coding tasks that yield inefficient functionality.

The application model is the core design methodology behind a three-tier enterprise application. Proper separation of business logic, including COM component design and use, can yield vast increases in reusability, scalability, and application performance.

by Michael Lane Thomas, MCSE+I, MCSD, MCT, A+

Defining the Application Model

The application model provides rules and a representation for designing the architecture of an application. As we’ll see in the next section, it breaks an application up into different layers of services. These services are used to enforce business rules, manipulate data, and expose features for using data. By using this model, you are able to form the structure of your application with flexibility in mind.

The model consists of three layers, which make up the application. These layers are explained in greater detail in the next section. In the order of top layer (where the user interacts with a program) to the bottom layer (where data resides), they are as follows:

·       User services

·       Business services

·       Data services

Each layer provides services to higher layers and/or is a consumer of the services below it. Communications across these layers are called service requests. To communicate across these layers, the developer needs to know how to request a service and how to handle results. Requesting a service includes such things as making a function call, and knowing what arguments to pass. Handling the result of a service request means having code that properly deals with returned values. By allowing other programmers to know how to request services that you’ve developed, features of an application become reusable. In other words, other developers can now use something you’ve coded.

The application model promotes the use of reusable components, which are commonly referred to as COM components. Services are meant for general use, and can be reused and shared by different applications. Rather than rewriting the same code over and over in a project, it is advisable to make use of existing components whenever possible. This means accessing features in the current application or accessing components in other applications.

Services-Based Architecture

As mentioned in the previous section, the application model is comprised of three layers of services: user services, business services, and data services. Each of these layers has different characteristics, which address different aspects of a business application. These services are networked together, with one layer providing services to the layer above and/or consuming the services of the layer below.

The top layer of the application model is user services. This is what provides an application with an interface, which can be GUI (Graphical User Interface) or programmatic. A programmatic interface is used by other applications to obtain information, while a GUI is a visual display that’s presented to a human user. The GUI provides navigation, consistent representations of data, and provides a way for the human user to interact with the application. Whether the user is another program or a human being, it is user services that integrates a user with an application. It allows him, her, or it to perform various tasks and manipulates data.

Business services reside on the middle tier of this three-layer model. Business services respond to requests for information from user services. It has the responsibility of communicating with the lower layer, where it does the following: takes the data, protects its integrity, transforms it into business information, and presents this information to the user interface. To illustrate this, let’s say you had a sales program. If you used this application to retrieve the price of items including sales tax, you would start by entering the name of a product at the user services layer. Business services would request the data on this product from a database. Since you need the price including sales tax, it would add a percentage to the amount, and return this information to the user services layer. To do such a business task, business rules are implemented at this level.

Business rules are policies used to determine how a business task is performed. A business task is determined by the requirements of an application. For example, if a customer required an application to print a list of orders from a database, this would be a business task. Business rules control the way business tasks are performed. For example, there is a common policy of adding sales tax to purchases, so business rules are added to applications that add a percentage to the value of items. Another example of a business rule would be adding a percentage to mark-up a wholesale value to a retail value. In using such information, the correct information is presented to the user, rather than the raw data contained in a database.

As you can see by these examples, business rules would change more frequently than business tasks would in an application. While a business task to retrieve the marked-up value of an item would be a consistent business task, the business rule of what that markup was would change. If you were creating an application for a computer chain, one week the markup on RAM might be 50%, while the next week a sale might require a markup of 25%. Since business rules change faster than business tasks, it is advisable to encapsulate business tasks in components that are separate from the business rules and the actual application. This allows the components to be reused, and keep the business tasks and rules separate from one another.

Another name for the business services layer is middle-tier services. The reason for this is because there are some activities that take place at this layer that can’t really be called a business service. There are a number of support services for an application that takes place at this layer. Such things as number crunching for math intensive programs, security services (such as logon screens), and offloading graphics-intensive processing to a server’s CPU are examples of such support. These activities are considered middle-tier services, as they don’t apply to either of the other layers in the application model.

Exam Watch: The middle layer of the application model is a grey area that has a number of attributes. An easy way to remember the layers is to keep in mind that user services integrate the user with the application, data services integrate data into an application, and everything else (i.e., business services and middle-tier services for application support) falls in the middle.

The bottom tier of the application model is data services. It is here that data is stored, defined, and retrieved. This layer provides Create, Read, Update, and Delete capabilities, and also protects the integrity of data. It services requests from business services for data, so the middle tier doesn’t need to know where data is located, or how to implement or access it. For example, data services could consist of a database on a user’s computer, a SQL server database on a network server, or a group of databases located on different platforms. When data is requested, this layer locates, stores, or modifies the data as per the request. The upper layers need not be concerned with this, since data services handles the entire request.

Completing Different Phases of a Project in Parallel

By using modular design, you are able to complete different phases of a project in parallel and cut the overall development time. Modular design involves breaking a large project into smaller modules, or subprojects. This allows the developing phase to go through a number of cycles involving testing, debugging, and fixing the product. It also allows different areas of a project to be worked on in tandem.

By breaking these projects into smaller subprojects, a number of things occur. First, parts of a project are being developed parallel to one another. If a problem occurs in a module, the entire project isn’t held up, because other modules are continuing to progress in development. For example, suppose ActiveX components are being developed for a project and the ActiveX server portion is experiencing problems. At the same time, developers of the ActiveX client portion (which is what users will primarily interact with in a client/server application) continue in their endeavors uninterrupted. Separating a project into smaller subprojects also separates problems in development.

The second benefit of breaking projects into subprojects is morale. While morale is often discussed in the military, the private sector often underrates it. Morale is having people feel good about what they’re working on. The goals associated with the team model address this issue. However, on big projects it often takes a considerable amount of time for one goal to be achieved. In the interim, people working on the project feel like they’re trudging toward something that’s way down the distant road. Subprojects allow developers to work toward smaller, more regular achievements.

To improve the morale of team members, subprojects can be implemented so that developers can see that something has been done, which helps drive them forward. When you’re working on a subproject, you’re able to stay fresh. Developers are excited that they’ve succeeded in completing one thing, and look forward to the next area of development. This speeds development time, since people on a team aren’t dragging their heels feeling that nothing is getting accomplished.

Sharing Assets, Resources, and Skills

The team model stresses that the people in different roles work as a team of peers. It should not be mistaken that these are people competing with one another on a project. While this sounds like a commonsense approach, all too often in the real world there is a hoarding of assets, resources, and skills between teams. For example, developers may need an extra computer to work on a project, and it is known that Testing has a spare. Rather than share this resource, it is kept from development with the excuse “we might need it!” While at face value this sounds childish, anyone who’s had to go head-to-head with Accounting can testify that it may be difficult to have adequate resources assigned to a project. When one party is trying to keep the bottom line in the black, and another is trying to get the resources to complete a project, you have two parties with different goals that conflict with one another. As such, the importance of sharing becomes paramount.

On the Job: The foolishness of not sharing assets and resources can be seen in the experience of a colleague of mine. He was working for the government on a project. There was a rather archaic and overworked network server set up for developers, and no money was allotted for a new one. No one would part with spare computers, and this was slowing down the project as people were waiting incredible amounts of time to access information. Because my colleague managed the project, the powers that be felt he needed a good desk that would command some respect. He put in a request for a few thousand dollars, was given the money, and went out and purchased the parts to build a new server. The developers were happy, the project was completed, and he used this loophole every few years to request a new desk and keep projects running effectively. This illustrates two things: stupid things like this would never happen if sharing was the norm, and there is a reason that hammers and toilet seats cost thousands of dollars in military budgets!

In using the process model, members of the project team get together and synchronize their efforts. This allows members of the team to determine if customer requirements are being met, and also gives them the opportunity to address internal issues. If members of development feel that they are falling behind in their schedule, they are able to share this information with the other roles. The schedule can then be modified, or additional resources can be shared with members of the role who are facing problems. For example, if a member in another role was a speedy programmer, and ahead in his or her work, this valuable resource could be shared with the other team to push development up to speed.

Achieving Parallelism during the Development Process

The application model can also be used as a model for separating members in the development role of the team model into smaller sub-groups. Rather than having a group work first on data services, then business and middle-tier services, and finally on the user services, you can split development into smaller groups that work parallel to one another. While one of these sub-groups is working on one area of development, other groups are working on other areas at the same time. This creates faster development time, as the sub-groups of the development team are working in tandem to one another. Since they keep in close contact with one another through the developing phase, they are able to address issues that arise as they are working on the different services of a project.

It is also important to remember that the roles of the team model work parallel to one another. The model doesn’t have five team roles sitting around, waiting for members in one role to finish. The model isn’t linear, but has all of the roles working together in a parallel fashion. If a customer goes to the product manager and says, “Hey, I need this feature added,” members in other roles don’t stop working. As one feature is incorporated into the functional design, other services are being worked on. This is because when a modular design is used, the program isn’t one monolithic program, but a group of modules that can be worked on in parallel. Each role can do their work on modules of the product, as new modules are incorporated into the design.

What is a milestone?

A milestone is the point at which one phase of a project ends and another begins. It is here that team members synchronize their efforts in a project, determine if they are meeting the customer’s requirements, and discuss implementation problems.

What is a tradeoff?

Program managers work with resources, features, and schedules. At times, one of these areas may need to be modified to meet another area that has a higher priority. For example, a new feature required in a current version will either need the schedule changed, more resources to complete the project, or both.

Which change more frequently: business rules or business tasks?

Business rules generally will change more frequently than business tasks. While a task may be consistent, the rules associated with it may change a number of times.

I work for a small company and have only five people for my project team. How can I meet all my goals for the project if I don’t have enough people to fill each project role?

Assign two roles, and thereby two goals, to one person. In doing this, make sure that the two roles assigned are similar in nature, and don’t have conflicting goals.

It is taking awhile to complete a project, and it’s affecting morale. How can I improve development time?

Break the large project into smaller projects. Different developers can work on the different parts in parallel and improve development time. It will also make them feel they’re achieving something, allow them to look forward to the next sub-project, and improve morale.

Certification Summary

The team model breaks a project team into six distinctive roles. Each role has an associated goal. When all of the goals in a project are achieved, the project is considered a success. If even one goal isn’t met, the project is considered a failure.

The process model is a milestone-based model that breaks a project up into four phases. At the completion of each phase, a milestone is reached. This model provides guidelines for planning and controlling a results-orientated project. This control is based on resources, schedule, and the scope of a project.

The application model breaks an application down into different services, which are networked together. There are three layers to this model, with each layer consuming the services of the layer below and/or providing services to layers above. This model’s structure allows for flexibility in designing solutions and promotes the use of components.

By completing different phases of a project parallel to one another, you are able to increase the speed that a project reaches completion. Sharing resources, skills, and assets, and working on different parts of a project simultaneously can help meet the schedule and keep within budget.

Two-Minute Drill

·       Organizing a project, and the people to complete it, can be a grueling task. The Microsoft Solution Framework (MSF) aids in organizing a project with models that outline the organization of a team, their goals, and the process of development.

·       The team model breaks a project team into different roles, with each responsible for meeting a particular goal.

·       The process model breaks the project itself into different phases, allowing team members to see where a project is going, and what progress has been made.

·       The application model breaks the actual application into different parts.

·       A business case is a plan of action that’s presented to senior management.

·       Product management has a position of advocacy between customers who buy a product, and the team that creates it.

·       The team roles and their related key goals have a symbiotic relationship. It is important to understand how one maps to the other, if you are to understand the purpose of each team role.

·       A milestone not only marks the point where one phase of a project ends and another begins, it also indicates the point in time that members of a team should synchronize their efforts.

·       The MSF process model is based on two proven models: the waterfall model and the spiral model.

·       The spiral model is also called the rapid application development (or RAD) model. It breaks a project into sub-projects, each of which deals with different risks in a project. Since each risk is addressed in the sub-projects, all risks in a project can be identified individually.

·       The waterfall model views the life cycle as a flow of steps.

·       Remember that the envisioning phase is where a common vision is set for a product, while the planning phase is where an agreement is made on what will be built and how to build it.

·       The application model consists of three layers, which make up the application. These layers are user services, business services, and data services.

·       Modular design involves breaking a large project into smaller modules, or subprojects.

·       A programmatic interface is used by other applications to obtain information, while a GUI is a visual display that’s presented to a human user.