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 ProcessesAlthough 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.
Documentation Review ProcessesAll 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 ProcessesYou 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 ProcessesSpeaking 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 ProcessesA 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 ProcessesIt'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:
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 ProcessesChange 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 ProcessesRelease 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 ProcessesAlthough 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:
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.
|