Certification Objective 9.02: Establishing Processes | MCSD Analyzing Requirements and Defining .NET Solutions Architectures Study Guide (Exam 70-300 (Certification Press)

The section of the chapter examines the development of processes for performing code reviews; builds; testing; bug tracking; source code, change, and release management; and maintenance tasks. These processes can be used throughout the development lifecycle. The goal is to simplify the development phases as much as possible.

Reviewing Development Documentation

The viewing of development documentation and code is called a design review. This is an industry best practice for detecting design flaws and determining the validity of the solution. The other purpose for a design review is to create an awareness of how other developers solve specific problems. The peer review is performed after the design review and coding is completed. The elements of a peer review, whether it is formal or informal, consist of a structured review process, a standards checklist, and defined roles for participants and reporting of the results. Peer reviews happen during three phases: specification and design, development, and testing. These are integral during the project lifecycle.

Exam Watch

Design reviews are performed with your peers and then possibly with your customer.

There are two types of reviews used in the design review process. The first is the architecture review, sometimes called the software walkthrough, and the second is peer review. The architecture review is generally necessary in order to generate artifacts to solve a problem or to get feedback on a particular strategy. The purpose is to get group consensus between the code reviewers and coders of the reviewing code. The author initiates the session. The goal is to determine open issues and action items that need to be taken to get consensus.

The software inspection, or code review, is structured to serve the needs of quality management. It ensures that the application or component follows the appropriate rules for completeness, correctness, style, standards, and user needs. The code review is led by a moderator, a recorder, and one or more reviewers. The moderator determines if the code is ready for the review and keeps the flow of the code review going during the review. The recorder creates a written archive of the meeting that identifies the changes and action items left to complete. The reviewer performs the review. The structured review process is organized around the following activities: planning, preparation, entry criteria, conduct, exit criteria, reporting, and follow-up.

Planning the Code Review

Planning of the architecture review starts early in the project planning process, while requirements are being gathered and refined to create a functional specifications document. The architecture review is performed and recorded into project documents. The information gathered from the architecture review is then used in creating the testing and software assurance plans.

The moderator determines the product’s volatility status to determine when the code review is appropriate. He or she then briefs the reviewers, the recorder, and the reader on their roles, along with artifacts for the review.

Before the start of the code review, the moderator checks exit criteria. The moderator determines if the scheduled code review is to proceed by answering the following questions:

Has the development activity been concluded for the reviewed item?
Are there any changes to the baseline?
Are review participants in place and briefed?
Have all participants received all the review materials and the checklist?
How many minutes of preparation did each participant perform?

The moderator, not the author(s), reviewers, recorder, or reader, directs the code review session. This allows the review to be done in an objective and unbiased way. Each component is inspected using the predefined checklist. As each issue is raised, the producer may wish to obtain clarification on why the issue is raised. The producer may choose not to defend or clarify but will have an opportunity to resolve issues during the follow-up. To complete the review, the following questions should be answered:

Are there any completeness issues?
Are there correctness issues?
Are there any style issues?
Are there any rules of construction issues or standards issues?
Are there any customer needs issues?

The moderator checks exit criteria at the close of the code review and verifies that all of the components have been inspected. The recorder verifies that all of the metrics have been reviewed. The recorder should also have a list of defects containing the following information: the defect type, category, and severity, and why the issue was raised. The examination of why each issue was raised should identify resolutions from the reviewing group or detail the standard that was broken.

The Reporting Phase

During the reporting phase, the moderator, with the help of the recorder, reports the findings of the code review in the appropriate format. This report provides a review summary, the preparation time, the type of defects, and recommended solutions.

The author performs the follow-up rework on the application. The associated tasks that need to be completed are entered into the project action plan. As each additional action is completed, it is marked off, and the application reflects the change in status. Tracking issues can be used as an indicator of the readiness of the software for production.

System of Checklists

Checklists are the heart of code reviews. They are the result of your defined standards and can be used as guides to make the review process smoother. A design and code checklist might contain the following sections: Completeness, Correctness, Style, Rules of Construction, and Multiple Views. Following are explanations of each of these sections, along with questions they might contain:

Completeness

The Completeness section indicates whether or not there is traceability among product artifacts such as requirements, specifications, designs, and code:

Has traceability been assessed?
Have all predecessor requirements been accounted for?
Were any product fragments revealed not to have traceability to the predecessor requirements?

Correctness

The Correctness section indicates whether or not the correct assumptions were made about the solution:

Is the function commentary satisfied?
Are programs limited to single entry and single exit?
Is the loop initialized and terminated properly?
Have legal values for inputs been used?
Is there systematic exception handling for illegal values?

Style

The Style section indicates whether or not project-specified style guidelines were followed:

Were naming conventions followed?
Were style conventions for commentary followed?
Are the semantics of the application component traceable to the requirements?
Have templates been used for repeating patterns?

Rules of Construction

The Rules of Construction section indicates whether or not code writing rules, templates, and conventions defined by the organization were followed:

Were guidelines for unit construction followed?
Were data representation conventions followed?
Was the interprocess communication protocol followed?
Was the system standard time defined and followed?
Have encapsulation, localization, and component layering been used to achieve object orientation?
Has scalability been achieved through nonparameterization and portability?

Multiple Views

The Multiple Views section indicates whether or not the various perspectives and viewpoints required of the software product by the different users were assessed:

Has the logical view of user interface and object orientation consideration been assessed?
Has the static view of packaging consideration, including program generation and deployment processes, been assessed?
Has the dynamic view of operational considerations, including communication concurrency, synchronization, and failure recovery, been assessed?

All together, this process allows for team cooperation and pooling of ideas to make sure that the code follows the prescribed standards of the team and the organization. Whether you use a formal or informal process, each piece of code should have this type of review to ensure completeness and accuracy.

Creating Builds

There are two types of builds: debug builds and release builds. While you are testing, the debug build is the preferred method because it allows debugging in the development environment. The process of creating a build accomplishes two goals: the first is to check the syntax of code, misspelling of words, and type mismatches. The second is to correct logic and runtime errors detected by using the debugger. After debugging and testing the solution, a release build is deployed into production. The difference between the two builds are shown in the following table:

Debug Build	Release Build
The result is a DLL or EXE file and a DBG debug file that stores the debugging symbols for each project.	The result is a DLL or EXE file for each project.
The DBG file is typically two to three times the size of the compiled project DLL or EXE file.	No debug file is created.
There is no execution optimization. The debug version carries so much extra information that the execution is slower than the release version.	The build is optimized to be small and execute faster.
	Various optimization options are available, such as checking for numeric bounds. If checking for numeric bounds is turned off, it is possible to have collisions in memory usage because the numeric values could spill in into unwanted memory locations.

Exam Watch

There is a large difference in execution times between debug and release versions of assemblies.

Builds are the periodic assembly of all solution elements that are sufficiently complete to be included in the build. Builds are created to confirm the viability of solutions in a simulated environment and are the basis for iterative development. Builds include code components, directory structures, and documentation and deployment scripts. This could be few or many components depending on the stage of the development process. Builds are should have a build number for tracking purposes and be placed under version control. A typical development process consists of internal release cycles developed over the course of several “daily” builds. After stabilizing the solution, external builds can be created for testing purposes, such as release candidate builds and deployment builds. After approval, the solution can be released to the users, and subsequent external builds are generated to include enhancements or to create completely new versions.

The “daily” build process has three steps: development, testing, and validation. The goal of daily builds is to avoid long periods where the actual state of development cannot be verified. This does not mean that you have to perform these builds on a daily basis; the frequency is based on the needs of the project, but these builds should be performed frequently enough to establish the progress of the project. The development phase allows you to work on the feature schedules for the upcoming release milestone. The testing phase uses the project test plan, which could include manual or automated scripts, or both. The validation is the recording of the results according to quality criteria.

Build Configurations

Build configurations provide a way to select the components you will build, exclude those you will not build, and determine the order of how the projects will build within the solution. There are two levels of build configurations: project configurations and solution build configurations.

A solution build configuration determines how the projects contained within the build are built and deployed. A solution can contain many projects. Each project contains a configuration that determines what will be built for that specific project and other settings. The default build configurations are Build, Release, and All Configurations. Each entry in the build configuration includes a project name, the configuration, the platform, a Build check box, and, if enabled, Deploy check boxes for selecting those projects that will be built. Each project can select the debug/release or custom configuration that it will use when building, and you can determine which project(s) of the solution you want to build.

With Visual Studio.NET, there are multiple options for handling and managing builds. Following are some common procedures.

To build or rebuild an entire solution:

From the Build menu, choose Build or Rebuild All.

To build or rebuild a project:

Select or edit the project you wish to build.
From the Build menu, choose Build [Project Name] or Rebuild [Project Name].

To batch-build multiple project configurations:

From the Build menu, choose Batch Build.
Select the check boxes for the project configurations you wish to build.
Click Build or Rebuild.

To make one project dependent on another:

Add at least two projects to your solution.
In Solution Explorer, select a project.
From the Project menu, choose Project Dependencies. The Project Dependencies dialog box opens.
Change the project in the Project list if you want to establish the dependencies of a different project.
In the Depends On field, select the check box of another project that must be built before this project.
To see the resulting order in which projects will build, click the Build Order tab.

To set the order in which projects build:

Open the Project Dependencies dialog box and choose Dependencies.
From the Project menu, select the project you want to build last.
In the Depends On field, select the project you want to build next to last.
Select the check boxes beside the other projects you want to build before the one you selected in step 3.
Return to the Project menu and select a project you want to build next to last.
In the Depends On field, select the project you want to build before the one you want to build next to last.
Select the check boxes beside all projects you want to build before the project you selected in step 5.
Continue this process until the only projects remaining are those without project dependencies.
Select Build Order in the Project Dependencies dialog box to view the order in which your project will build.

Tracking Issues

Tracking of issues is a common way to follow bug changes. You can use a commercial software package or something as basic as a spreadsheet to track information. Some of the more common information to capture includes issues names, the module where the bug was found, the date entered, the resolution date, comments, the developer the bug was assigned to, and so on. The goal is to gather enough information so that the assigned developer or team can decipher the problem and determine the solution. Tracking the issues keeps you from losing track of bugs that need to be fixed. Tracking can also be used to single out issues to be enhanced in the future, because tracking frequently highlights issues that have room for improvement.

Managing Source Code, Changes, and Releases

Microsoft Visual SourceSafe is an excellent way to manage source control for code, documents, changes, and deployments. Visual SourceSafe manages the work of multiple developers working on the same code and projects.

When developing a process for a web project, you must choose one working method from each of the following categories: local host vs. remote host, web access methods, and shared checkouts, and collaborative development models.

Local Host vs. Remote Host

When determining whether to use the local host or the remote host for the location at which to save web project files, it is important to consider the differences between the two methods. Web projects whose working location starts with http://localhost are referred to as local host projects. Projects that have a nonlocal host location are referred to as remote host projects.

Exam Watch

When using remote host projects, the debug process locks the shared web server and prevents other users from working on the server until the debugging session is over.

Local host projects are executed and debugged locally. The address http://localhost is the default and recommended host for web projects. On the other hand, remotely located projects are debugged on the remote machine.

There are two main reasons for using remotely located solutions: when your computer cannot be used as an IIS web server and when you want to perform predeployment testing and debugging on a production server.

Web Access Methods

Web access methods specify how Visual Studio obtains write access to web project files on a network. Visual Studio uses two web access methods: File Share and FrontPage. File Share is the default and recommended method for Visual Studio. A File Share web application maintains itself at a shared network location. The address that is used is the HTTP address, but it resolves the address to a universal naming convention (UNC) share. All access to the project will use the resolved UNC share. Visual Studio creates a working copy of the project’s source-controlled master copy in your working folder. A working folder is located on a web server. The File Share method allows multiple developers to work in isolation, so developers can work in parallel. File Share web access is the preferable method for the following reasons:

It supports shared checkouts.
It supports source control commands, such as branch, merge, pin, and label.
It allows for isolation, meaning that team members can edit shared files and then merge them.

FrontPage server extensions are the second method of accessing the files. The FrontPage extension is integrated with Visual SourceSafe. With this method, there is only one working copy, it is contained on the web server, and it is considered the master Web. This environment is suitable for only one developer at a time.

Exam Watch

You cannot use Visual Studio to add a project to source control through the FrontPage server extensions. Projects have to be added on the web server manually.

Shared Checkouts

SourceSafe has two forms of checkout: exclusive checkout mode and shared checkout mode. Exclusive checkout mode allows only one user at a time to check out a file. Shared checkout mode allows multiple users to check out and modify files. This allows developers to make changes to different parts of the file that are checked out at the same time. It is important to note that the shared checkout mode sometimes results in merged conflicts—overlapping changes that cannot be automatically resolved. This is not something that happens often, but Visual SourceSafe provides an interface that allows for the side-by-side comparison of the changes.

Exam Watch

Merged conflicts manage multiple checkouts when there are conflicts.

Collaborative Development Models

Web applications have three development models: the isolated model, which is the recommended model, the semi-isolated model, and the nonisolated model. Each model determines how the environment is configured and how web access methods are used.

Isolated Model

In the isolated model, editing, debugging, and execution are completely separate on your workstation using the http://localhost. Source control is maintained in Visual SourceSafe using the File Access method. The isolated model has the following advantages and disadvantages.

Advantages:

Two or more developers can work on the project and debug at the same time.
It supports shared (multiple) checkouts, and the merge, branch, pin, and label commands.
Web references are easier to create and maintain than in other environments. The creation of web references creates a directory that moves with the solution to point to the web references.

Disadvantages:

Testing is not realistic as it is in the production environment; for example, you can’t test the effects of web farms.
Each developer must maintain his or her IIS settings to a common standard. This is a disadvantage because you might have to spend time maintaining your machine to keep it in the same configuration when things change, as opposed to the changes being maintained in a single location.
All developers must have access to the same network LAN.

Semi-Isolated

Using the semi-isolated model, a developer creates a web project on a remote server and then adds it to source control. The first time project contributors open the project from source control, they save their working copy to the same remote web server using a different project name and a different save location. In this model, the master copy is maintained on the shared web server, and working copies are maintained in developer-created shared folders.

Advantages:

Teams can have a network administrator who specializes in the management of shared developmental resources.
It does not require access to http://localhost. IIS need not be installed on every developer’s computer.
It supports source control functionality, such as shared (multiple) checkouts, and the merge, branch, pin, and label commands.

Disadvantages:

When any one user is debugging, the debug process locks the shared web server, preventing other users from working on projects on the same server.
Web references are not automatically shareable.
All developers must have access to the same local area network (LAN) or virtual private network (VPN).

Nonisolated

This model uses the FrontPage extensions as its primary access method. All work is done against the master Web. Work cannot be done in parallel and is not isolated from other developers. A FrontPage web project cannot be added to source control in the IDE. Rather, its version control status must be changed in IIS. Both IIS version-control options, Built In and Use External, enforce exclusive checkouts, limiting write access to a file to only one developer at a time. The difference between these version-control options is that Built In does not send the latest version to source control on check in, but Use External does. For FrontPage web projects, the Use External option is recommended.

Exam Watch

Projects must be saved on an NTFS partition.

Maintenance Tasks

Maintenance tasks are actions performed to maintain the application. This could range from configuration changes to data updates. These tasks are designed to support the existing solution. They could be as simple as executing simple SQL statements for updating values for a new user interface option or as complex as creating external applications to handle the complex update and maintenance of transactional data. Another common example is reporting, because reporting can require time-consuming processes and resources. Maintenance tasks are normally scheduled as an evening batch process, thus allowing the application to be maintained with updated information on a regular basis.

Enterprise Templates

Enterprise templates allow software architects to provide guidance to development teams about how to work within the architecture by eliminating many decisions such as what files to add to the project, how to format controls, and what Visual Studio options to make available. These decisions can affect the integrated development environment (IDE) features in Visual Studio. The enterprise templates can provide starting blocks for applications or for different parts of solutions. Enterprise templates are composed of three primary items: a prototype file, a policy file, and custom help topics. The prototype file is the structure of the project and source to be in the template. The policy file defines rules about how the environment interacts with the template. Custom help topics can be created so that they activate and provide additional help for users of the templates. The use of enterprise templates has three primary goals:

They define the initial structure of a distributed application. This allows a solution to create a directory structure and the appropriate starting files.
They reduce complexity to a more manageable state. This allows for control of the development environment and provides defaults for the developer.
They provide architectural and technological guidance. This allows the IDE to display guidance through the Task List items and provide reusable templates. Items and hints about different sections of the templates can have preset tasks associated with them in the Task List to help the user find information.

The enterprise application consists of many separate projects contributing components, interfaces and services. The enterprise template is comprised of three items: the initial project structure, custom help topics, and the policy file. Creating a new project from an enterprise template allows the creation of predefined templates for the needed solution. Table 9-1 details Visual Studio IDE features managed by the enterprise template’s policy file and their effects.

Exercise 9-2: Apply Constraints in an Enterprise Template Policy File

In this exercise, you are going to apply an enterprise template policy file to a project and apply constraints that effect the development environment.

Start Microsoft Visual Studio .NET. Create a new Windows application project. In this example, the project name is WindowsApplication1.
In the exercise folder, a file named MyPolicy.TDL is the template policy file that you will be modifying. Please save this file in the directory as WindowApplication1.

Author's Note
Make sure that the file is not marked as Read Only.
To add the policy to the project, in the Project Properties list, select the ellipsis button at the end of the Policy File property, as shown in the following illustration. A dialog box will appear in which you can select the MyPolicy.TDL file in the WindowsApplication1 project location.
After selecting the policy, a warning is shown that will state that the project will be reloaded. When the project is reloaded, the policy file is then validated and any constraints are applied to the environment.
To see an example of a menu constraint, click on the WindowApplication1 project in the Solution Explorer. In the following illustration, you will notice on the Project menu that the New Folder option is enabled.
Close the solution.

Open the MyPolicy.TDL file and add the following CONSTRAINTS nodes indicated in bold below the DEFAULTSETTINGS section of the policy file.

    <DEFAULTSETTINGS>         <DEFAULTACTION>INCLUDE</DEFAULTACTION>       <ORDER>EXCLUDEINCLUDE</ORDER>         <POLICYMODE>RESTRICTIVE</POLICYMODE>        <CONSTRAINTS>                <MENUCONSTRAINTS>           <MENUCONSTRAINT>                      <ID>menuProject.NewFolder</ID>                     <ENABLED>0</ENABLED>               </MENUCONSTRAINT>       </MENUCONSTRAINTS>         </CONSTRAINTS>   </DEFAULTSETTINGS>

Save the changes and close the policy file.
Reopen the WindowsApplication1 project. Select the Project menu, and you will notice that New Folder option is disabled.
To disable a Toolbox item, open Form1 in design mode. View the Data tab and note that SQLConnection is enabled.
Close the solution.

Edit the DEFAULTSETTINGS node in MyPolicy.TDL to include a TOOLBOXCONSTRAINT to disable the tboxDataSQLConnection.
An example is shown in bold in the following listing:

     <DEFAULTSETTINGS>       <DEFAULTACTION>INCLUDE</DEFAULTACTION>           <ORDER>EXCLUDEINCLUDE</ORDER>         <POLICYMODE>RESTRICTIVE</POLICYMODE>       <CONSTRAINTS>                             <TOOLBOXCONSTRAINTS>               <TOOLBOXCONSTRAINT>                   <ID>tboxDataSQLConnection</ID>                  <ENABLED>0</ENABLED>               </TOOLBOXCONSTRAINT>           </TOOLBOXCONSTRAINTS>       </CONSTRAINTS>     </DEFAULTSETTINGS>

Save the changes to the policy file.
Reopen the WindowsApplication1 project, view the Toolbox again, and notice that SQLConnection is disabled.
To set up property constraints, you are going to set up default settings for the SQLConnection object. Close the solution.

Open MyPolicy.TDL and add the following code in the policy file. Search for codeDataSQLConnection to find the correct location. Add the content in bold.

<ELEMENT> <ID>codeDataSQLConnection</ID>           <IDENTIFIERS>               <IDENTIFIER>                   <TYPE>CODEVARIABLE</TYPE>                  <IDENTIFIERDATA>               <NAME>TYPENAME</NAME>                   <VALUE>System.Data.SqlClient.SqlConnection</VALUE>                    </IDENTIFIERDATA>                 </IDENTIFIER>         </IDENTIFIERS>           <FEATURELINKS>                <TOOLBOXLINKS> <TOOLBOXLINK> tboxDataSQLConnection </TOOLBOXLINK>               </TOOLBOXLINKS>             </FEATURELINKS>      <CONSTRAINTS>          <PROPERTYCONSTRAINTS>          <PROPERTYCONSTRAINT>          <NAME>ConnectionString</NAME>                        <DEFAULT>data source=localhost;              initial catalog=pubs;persist security info=false;   Integrated Security=SSPI;   </DEFAULT>                         <READONLY>0</READONLY>                    </PROPERTYCONSTRAINT>                   </PROPERTYCONSTRAINTS>               </CONSTRAINTS>         </ELEMENT>

Save your changes to the policy file.
Reopen the WindowsApplication1 project. Open Form1 in design mode and drag a SQLConnection object to the form. You will notice in the properties window for the newly created control that the ConnectionString property is filled in and is Read Only.
Save your solution, and you are finished.

In this exercise, you have seen how to add a policy file to a project and modify constraints for your environment.

These processes are guidelines to help with your development processes. If each developer understands these processes, it will help create a quality product and streamline your development. Processes are not just for the coding process. They involve the reviewing of code, design, and bug tracking. You probably do many of these processes already, but maybe you don’t realize it.