Establishing Processes for the Team

Although processes are not always the most enjoyable part of your work, without them you would sabotage your chance of success. The trick is to have just the right amount of processnot too little or too much. Take a look at what Microsoft recommends, at a minimum, in the following sections.

Testing Processes

Although testing processes are not part of the published Microsoft objectives, saying a few words about them is necessary.

Here is a partial list of the various test stages a typical process might enforce. Of course, each organization seems to have its own terminology and flow.

• Code coverage test Although a code coverage test is not called for on all projects, it ensures that every line of every method gets called and tested, often with the developer single-stepping through the code. Testing that the code does not generate errors is not the same as testing that all the outputs are functioning properly.

• Unit test This is usually a test of the functionality, at the lowest level, of what you are building or changing. It is a test at the class, module, or even method level, testing the inputs and outputs. It is sometimes referred to as a "white box" test because knowledge of what is inside the class or method helps you build an effective test.

• Build validation test A short test of the application should be made after each build to ensure the general integrity of all components. This test is sometimes referred to as a "smoke test," a term from the hardware world for plugging something into the wall outlet and watching/smelling for smoke.

• Assembly test This test is a larger, more encompassing version of the build test. All areas of the application are tested for base functionality to see whether any new defects have been injected and to ensure that necessary fixes/enhancements are there, without breaking other areas. This might sometimes be referred to as a "regression test," verifying that you did not regress the application's stability.

• QA test This test is one of the last gates a piece of software needs to pass through on the way from the builder to the user. In this test, the software is usually tested in an environment as close to real life as possible.

• Performance test (load test) In this test, applications that support multiple users, usually server-based applications, are subjected to heavy loads to see whether they support the required number of concurrent users with the required response times. This test integrates with two of the key factors of any solution: performance and scalability.

• User acceptance test Some applications are required to pass a user acceptance test. It is used to ensure that the solution's business goals are met as agreed to upfront. This test could be based on the use cases.

• Pilot test Although the pilot test is not a test per se, you subject a small subset of your users to the application before rolling it out to the entire user base. The pilot users become an extension of QA testing and are often given special instructions for reporting errors.

One way to load-test a Web application (ASP.NET or classic ASP) is with Microsoft Application Center Test (ACT). ACT can stress-test Web servers, identifying performance or scalability issues. ACT can also be used to set a benchmark for your Web application to determine whether various caching strategies are working effectively.

Documentation Review Processes

All key documents (deliverables) should be reviewed before being flagged as complete or submitted for sign-off. This is especially true of the technical design documents created from the planning phase of your project.

Code Review Processes

You have learned about code standards and what the minimum standards ought to be for an effective code review. As for the process, code should be reviewed before it gets moved into the "production" area of Visual SourceSafe (or wherever you are keeping your code scheduled for the next build). All open issues discovered in code reviews should be resolved and signed off on before the code is allowed to move forward in the process. Visual SourceSafe access rights can be useful in this area by limiting updates to only lead developers or architects, for example.

Build Processes

Speaking of builds, why do teams spend so much time on inspections and quality and design, only to gamble with their build processes? A good build process can mean the difference between having control and having regular fire drills, where overtime is the rule.

In some situations, daily builds are appropriate. In other situations, builds on an ad doc basis are more effective. After a build is complete is a good time to do a quick assembly test before the compiled code finds its way onto too many machines. In almost all cases, the more frequent the build, the better the chances of producing quality software. Using automated build tools, either bought or built, can also be a good idea for all but the smallest projects.

Although it seems unlikely there will be as many compatibility issues in the .NET Framework as in the COM world, a well-controlled build, done from a "gold" (that is, trusted, clean) machine is crucial to any project. Developers submitting code for the build should usually have a "promotion" process, in which the developer making the change first unit-tests the code. The code is then stored in Visual SourceSafe in a holding area, inspected (reviewed), approved for a specific build by a lead architect, and promoted into Visual SourceSafe's "production" area, where the builder or build tool retrieves it.

Issue Tracking Processes

A good system for tracking both bugs (defects) and enhancements is essential. Defects should be prioritized according to their impact on users. Each defect is effectively a "mini-solution" in itself, going through the various stages of envisioning, planning, building, and testing, albeit much faster.

Source Code Management Processes

It's hard enough to track down and solve some bugs once, let alone have to do the same work all over again. For teams of any size (even one), source code management is important. In the Microsoft world, this task is often done through Visual SourceSafe, but even with third-party products, the principles are the same.

I envision a source code module as being similar to a library book. No two people can check out the same book at the same time, yet this is often what happens when source code management software is used improperly. If two people check out, and change, the same code module, one of three things can happen:

• The second person to check in her code is "not allowed," and her changes do not take place. This is not good.

• The second person's code changes are allowed in, but the changes inadvertently write over the first person's changes. This is much worse.

• The second person performs a "difference" check on the code from the time she retrieved her copy and merges her changes with the first person's changes. This is usually okay, but not always. What if the first person's changes modified the module's context or behavior in such a way as to render the second person's changes unnecessary or even "break" the code?

As you can see, only one of three results is even close to acceptable, and even that result is error prone and carries some risk.

A better strategy is for the solution architect (that's you) to modularize the coding effort so that it is unlikely that two people ever need to update the same module at the same time. Modularization is one of the benefits of component-based design. If you must have simultaneous updates of the same code module, look for ways to mitigate the risk of overwriting someone else's hard work. The other best practice is to use source control as it was intended, for synchronous checkouts and checkins, like a library book.

Change Management Processes

Change management is where good document sign-off practices pay off. When a change to the solution's scope seems required for technical or business reasons, change management kicks in.

All parties meet to discuss the ramifications of changing the scope. In some cases, there is minimal impact, perhaps an extra few hours that can easily be absorbed into the schedule. However, sometimes the change is large or risky.

In that case, a "go, no go" decision needs to be made. The impact, which usually boils down to spending more money, extending the deadline, or taking a risk, is understood and agreed to by all. A good practice is to have stakeholders sign off on all change management requests.

Release Management Processes

Release management is logistical in nature; it deals with what goes where and when. For projects that use iterative, versioned releases, a specific enhancement needs to be planned out. Often, what requires detailed planning is separate events coming together, as in the rollout of a .NET Windows application (thick client) to each employee in the company, for example. If you have a lot of machines and are in the middle of an extensive migration from Windows 95 to Windows XP, your solution must be coordinated to coincide with the 100% migration to Windows XP.

Maintenance Processes

Although I have seen one application that was so stable it required virtually no assigned maintenance personnel, typically an application needs to be maintained as long as users are still using it. Files get corrupted, machines need to be reimaged, and the application needs to be redeployed; new software on a working machine breaks old software, and the list goes on and on. A good process for maintaining an application is important. Otherwise, car dealerships would have only a showroom and no service department, wouldn't they?

What Are Enterprise Templates?

The last topic in establishing processes is clearly related to delivering quality code, but it has no clear "home" within the exam guidelines. This topic is Enterprise Templates, and they are a way to capture best practices and make them readily available to the entire development team, both experienced and novice members. With Enterprise Templates, you can include items such as prewritten code structures and patterns and exclude items such as IDE features or the ability to edit certain code modules that are "locked down." Enterprise Templates give you another way to affect application quality in a positive, preemptive way.

Enterprise Templates define an initial structure for new projects, reduce complexity for developers by removing IDE features that are not required (or desired), and offer useful, "just in time" architectural and technical guidance for senior developers. As you can see, they go way beyond the macros and add-ins you're used to seeing in the IDE. Enterprise Templates can take over the IDE from the time a developer chooses File, New, Project from the menu.

Usually, experienced lead architects or even a centralized architecture group create Enterprise Templates, which act as a sort of blueprint. A good analogy is a menu at a Mexican restaurant. For those who speak only English, Queso Fundido con Chorizo might not be obvious (the first time, at least). But if "Melted Cheese over Sausage" is displayed on the menu right below it, even novices like me can avoid major ordering mistakes.

Most Microsoft documentation divides the functionality of Enterprise Templates into the following three areas:

• Application structure This area encompasses items to include and serves as a starting point. It is similar to the .NET markers you've seen that say "Add code here." It can include, for example, a pre-established file structure (such as layers) or the option to launch custom wizards whenever a new item is created. This area of Enterprise Templates gives you controlled customization of an enterprise framework.

• Policy Policies are items that should be excluded. This area provides fine-grained control of property settings, for example, and enables you to remove items from the Visual Studio .NET IDE, such as menu items. Another example is data access. Policies can prevent the developer from writing data access code when it goes against the defined architecture (for example, in the User Services Layer).

• Guidance Guidance acts like online help, but it is customized locally to apply to the specific template.

The capability to create Enterprise Templates exists only in the Enterprise Architect version of Visual Studio .NET. However, templates are written in Template Definition Language (TDL) and are files in XML format with a .tdl extension. If you can get hold of an existing TDL file, you can modify it for your purposes much more easily than building one from scratch. Do an MSDN Library search on "TDL" for more information.

A few templates are already bundled into Visual Studio .NET (see Figure 11.3) and offer a good way to get better acquainted with the power of templates. Also, one of the Microsoft Webcasts announced that sometime in 2003, more pre-established templates will be available from Microsoft and others in the .NET community.

Figure 11.3. Accessing Enterprise Templates from Visual Studio .NET.

Several articles posted on the Web claim that the next version of Visual Studio will contain upgrades to Enterprise Templates. At the time of this writing, Visual Studio .NET 1.1 was still in beta, so I chose not to install the beta version, as I don't have any details about what those upgrades might be. For the purposes of the exam, a general knowledge of why and how to use Enterprise Templates is enough.