Appendix -- Review Questions and Answers

Chapter 1 -- Enterprise Architecture

1. What common IT challenges can an enterprise architecture address?

• Deliver business value Tightly align IT to business objectives.
• Control costs Squeeze every ounce of leverage from existing IT investments and make careful and informed future investments.
• Sense and respond Improve the cross-functional capabilities within the organization and extend those capabilities outside the organization to reach customers, suppliers, and stakeholders more effectively.

2. What are the primary goals of an enterprise architecture?

• Be logically consistent.
• Include both activities and coordinated projects.
• Progress from the current state to the desired future state.
• Address both current and projected business objectives and processes.

3. List the phases of enterprise architecture adoption.

• Envisioning
• Planning
• Developing
• Stabilizing

4. Describe the four perspectives of the MSF Enterprise Architecture Model.

• Business Perspective Includes broad business strategies and plans for moving the organization from its current state to its desired future state. The Business Perspective describes how the business works.
• Application Perspective Represents the services, information, and functionality that cross organizational boundaries, linking a variety of users to achieve common business objectives. The Application Perspective defines the enterprise application portfolio.
• Information Perspective Describes what the organization needs to know to run its business processes and operations.
• Technology Perspective Lays out the hardware and software supporting the organization. The Technology Perspective provides a logical, vendor-independent description of infrastructure and system components that is necessary to support the Application and Information Perspectives, and defines the set of technology standards and services needed to execute the business mission.

5. How can applications be delivered while an enterprise architecture is under development?

The enterprise architecture should not be defined in a vacuum, but should reflect information discovered by actually building solutions. Using versioned releases that incorporate feedback from teams and users should result in progressive refinement of the architecture. Otherwise, a rapidly changing business environment could quickly overtake an organization's ability to both complete models at the enterprise level and deploy projects before business changes make the models invalid.

Chapter 2 -- Enterprise Applications

1. What is software architecture, and what are the characteristics of a good architecture?

Software architecture is a set of significant decisions about the organization of a software system. These decisions include:

• The selection of the structural elements and interfaces comprising the system.
• The system's behavior as determined by collaborations among those elements.
• The combining of structural and behavioral elements into larger subsystems.
• The architectural style that guides the system's organization.

A good software architecture has the following characteristics:

• Resilient
• Simple
• Approachable
• Clear separation of concerns
• Balanced distribution of responsibilities
• Balanced economic and technical constraints

2. What are three ways of documenting software architecture?

• Unified Modeling Language
• Design patterns
• Design antipatterns

3. What are the features of an enterprise application?

• Complex It is a multi-user, multi-developer, multi-component application that can utilize substantial data, employ extensive parallel processing, affect network-distributed resources, and require complex logic. It can be deployed across multiple platforms and inter-operate with many other applications, and it is long-lived.
• Business-oriented Its purpose is to meet specific business requirements. It encodes business policies, processes, rules, and entities; is developed in a business organization; and is deployed in a manner responsive to business needs.
• Mission-critical It is robust enough to sustain continuous operation. It must be extremely flexible for scalability and deployment, and allow for efficient maintenance, monitoring, and administration.

4. What are design patterns and antipatterns?

A design pattern is instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces. It identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. Design patterns can be either generative or non-generative. Generative patterns can be used to solve engineering problems, whereas non-generative patterns are merely observed. Generative design patterns provide complete solutions to business and technical problems. They are primarily geared toward "green field" designs, meaning they are applied to new designs.

Design antipatterns are geared toward solving problems for which an inadequate solution is already in place. The best way to differentiate patterns and antipatterns is to say that patterns lead to an original solution for a set of criteria and forces, while antipatterns lead to a new solution when the current design is not working. Thus patterns are used when starting from scratch, and antipatterns are used to fix things that are broken.

5. Identify five guiding software management principles.

• Alignment with business goals
• Product mindset
• Architecture-first
• Design within context
• Different languages for different project phases

6. List the six submodels of the Enterprise Application Model.

• Business Model
• User Model
• Logical Model
• Technology Model
• Physical Model
• Development Model

7. What is the MSF Application Model for Development?

The MSF Application Model for Development (MSF Application Model) provides a three-tier services-based approach to designing and developing software applications. It views an application at a logical level as a network of cooperative, distributed, and reusable services that support a business solution. Application services are units of application logic that include methods for implementing an operation, function, or transformation. These services should be:

• Accessed through a published interface.
• Driven by the interface specification.
• Focusing value toward the customer, not the provider.
• Mapped directly to actions.

The MSF Application Model describes applications as using three services: user, business, and data. These services allow for parallel development, better use of technology, easier maintenance and support, and flexibility in distributing the application's services. These user, business, and data services can reside anywhere in the environment, from a single desktop to servers and clients around the world.

Chapter 3 -- Project Teams

1. What are the six roles of the MSF Team Model for Application Development?

• Product Management
• Program Management
• Development
• Testing
• User Education
• Logistics Management

2. What are the focal points and responsibilities of each role?

• Product Management The job of this role is to respond to the customer's need or problem. The key contribution of this role is to drive the team to a shared vision of how to meet the need or solve the problem. Product Management answers the business-driven question, "Why are we doing this?" and ensures that all members of the team know and understand the answer. The key external goal of this role is customer satisfaction.
• Program Management The job of this role is to own and drive the development process. The leader of this role must understand the difference between being a leader and being a boss. The primary responsibility of the leader of the Program Management role is to move the project through the development process to ensure that the right product is delivered at the right time. The key external goal of this role is delivery within project constraints.
• Development The job of this role is to be technology consultants and product builders. Development determines exactly how to implement each feature, the actual architectural implementation, and how long the coding portion of the project will take to implement. Development does not determine which features to implement, but how to write the code for the product. The key external goal of this role is delivery to product specifications.
• Testing The job of this role is reality induction. Testing must be able to clearly articulate both what is currently wrong with the product, and what is currently right with it, so that the status of the product's development is accurately portrayed. Testing develops test strategies, plans, schedules, and scripts. The key external goal of this role is to make sure that the team knows and addresses all issues before releasing the product.
• User Education The job of this role is to enhance user performance so that users are as productive as possible with the product. To accomplish this goal, User Education acts as the advocate for the users of the product, much like Product Management acts as the customer advocate. However, this is a two-way street, because User Education also acts as the team's advocate to the users of the product. The key external goal of this role is enhanced user performance.
• Logistics Management The job of this role is to serve as the advocate for the operations, product support, help desk, and other delivery channel organizations. The key external goal for this role is smooth deployment and ongoing management of the product.

3. How can the MSF Development Team Model be scaled for large and small projects?

Large projects call for organizational practices that formalize and streamline communication. All the ways to streamline communication rely on creating some kind of hierarchy; that is, creating small groups, which function as teams, and then appointing representatives from those groups to interact with each other and with management. To scale large projects, the project team can be divided into two kinds of subteams:

• Feature teams These are small subteams that organize one or more members from each role into a matrix organization. These teams are then assigned a particular feature set and are responsible for all aspects of that feature set, including its design and schedule.
• Function teams These exist within a role. They arise when a team or project is so large that it requires the people within a role to be grouped into teams based upon their functionality.

Although the MSF Development Team Model consists of six roles, a team doesn't require a minimum of six people. In other words, it doesn't require one person per role. The key point is that the six goals have to be represented by the six roles on every team. Having at least one person per role helps to ensure that someone looks after the interests of each role, but not all projects can be approached in that fashion.

On smaller teams, one team member might have more than one role. Two principles guide this type of role sharing:

• Single role for Development Development team members should never be assigned to another role. The developers are the builders, and they should not be distracted from their main task. To give additional roles to the Development team only makes it more likely that schedules will slip due to these other responsibilities.
• Conflict of interest Roles that have intrinsic conflicts of interest should not be combined. For example, Product Management and Program Management have conflicting interests. Product Management wants to satisfy the customer whereas Program Management wants to deliver on time and on budget. If these roles are combined and the customer requests a change, the risk is that either the change will not get the consideration it deserves to maintain customer satisfaction, or that it will be accepted without understanding the impact on the project. Having different team members represent these roles helps to ensure that each perspective receives equal weight.

4. What are the stages of development through which a team can progress?

We view teams as progressing through the following stages:

• Awareness/concern
• Hope/optimism, willingness
• Identification of needs and solutions
• Supportive/caring behaviors
• Trusting/respectful relationships
• Team cohesiveness

The goal is to have all teams move to the last stage, team cohesiveness, where productivity is the highest.

5. What two types of education improve a team member's effectiveness?

• Process education Training in the process of developing software.
• Technical education Training in the actual languages and tools being used.

Chapter 4 -- Development Process

1. Briefly describe the Waterfall Model and the Spiral Model.

• Waterfall Model A project life cycle model that is primarily linear. It is an orderly, highly structured process based on the following well-defined development steps: system requirements, software requirements, analysis, program design, coding, system test, and operations.
• Spiral Model A project life cycle model that is primarily iterative. The stages of application development that make up this model are typically characterized as inception, elaboration, construction, and transition. Within each stage are five activity phases: requirements, design, implementation, deployment, and management. The Spiral Model's process is a continuous circle through the stages of development, with each stage requiring multiple revolutions through the five phases.

2. What are the workflows of the Unified Process?

The workflows of the Unified Process are five core processes that are continually executed during the four phases of the development process until the application is completed. Each circuit of the five workflow steps is called an iteration, and each iteration culminates in an internal product release. The workflows are:

• Requirements
• Analysis
• Design
• Implementation
• Testing

3. What are the phases and milestones of the Unified Process?

Because the Unified Process is based primarily on the Spiral Model, like that model, its four phases of development are Inception, Elaboration, Construction, and Transition. Each phase strives to achieve specific goals:

• Inception Phase Iterations focus on producing the business case. The Inception Phase's milestone is the Lifecycle Objective Milestone.
• Elaboration Phase Iterations are responsible for developing the baseline architecture. The Elaboration Phase's milestone is the Lifecycle Architecture Milestone.
• Construction Phase Iterations focus on creating the product with incremental releases of product builds and features. The Construction Phase's milestone is the Initial Operation Capability Milestone.
• Transition Phase Iterations ensure the product is ready for release to the user community. The Transition Phase's milestone is the Product Release Milestone.

4. Discuss the objectives and purpose of each MSF phase.

• Envisioning Phase A shared vision of the project is built among all the key stakeholders. This vision should include a mutual understanding of the business needs being addressed, clearly identified solutions that meet the customer's expectations, and a solid estimation of the project constraints.
• Planning Phase The application's architecture is defined. This application architecture is based on the Conceptual, Logical, and Physical Design Models. In addition, the three variables with which the team must work—schedule, resources, and features—are more clearly defined during the Planning Phase. By the end of this phase, the team has determined the schedule it will meet, the resources it will use, and the features it will build.
• Developing Phase The most important task is to build the application. Iterations, which have been used during the earlier phases, become even more important during the Developing Phase. The team can expect to do multiple iterations of the application during this phase, typically named alpha, beta, and golden release candidate. Additionally, all known bugs should be addressed by the end of this phase. Addressing known bugs does not necessarily imply that all the bugs have been fixed; merely that they have been investigated. The goal of the Developing Phase is to deliver an application that meets all stated expectations and is ready for external testing.
• Stabilizing Phase Significant performance and environmental testing occurs. All known issues are resolved before delivery, and any tasks needed for support and ongoing maintenance of the product are completed. This phase seeks to tie up the loose ends. Documentation, release notes, final "bug stomping," product hand-off, and product deployment are all part of this phase. The Stabilizing Phase starts when the team shifts its focus from code development to stabilizing the product and ends when the customer accepts the product as complete. A significant aspect of this phase is that the customer and users begin to pilot-test the product. This phase is also the training ground for the organization's operations and support teams. During this time, Logistics Management works to ensure a smooth transfer of product support to the organization's internal support groups, with the product release completing the transfer.

5. List the deliverables for each phase of the MSF Development Process model.

• Envisioning Phase The Vision Document, the Master Risk Assessment Document, and the Project Structure Document. We also recommend that a prototype system be included with the deliverables for this milestone.
• Planning Phase The Functional Specification, the Master Project Plan, the Master Project Schedule, and an updated Master Risk Assessment Document. For most projects, another deliverable of this phase might be a proof-of-concept system that helps the team and stakeholders understand the application's architecture. Additionally, any significant design concerns can be tested with the proof-of-concept system before the Project Plan Approved Milestone is reached.
• Developing Phase The revised and completed Functional Specification, the updated Master Project Plan, Master Project Schedule, and Master Risk Assessment Document, source code and executables, initial performance support elements, and the Test Specification and test cases.
• Stabilizing Phase Golden release, release notes, performance support elements, test results and testing tools, source code and executables, project documents, milestone review.

6. Discuss the benefits of versioned releases.

• Communication Promotes frequent and honest communication between the team and the customer. Each release reflects the best ideas of everyone involved.
• Earlier delivery Enables the project team to deliver critical functionality earlier and to obtain feedback from the customer for future releases. When the customer knows (or senses) that future product releases will be delivered in a timely manner, the customer is much more receptive to deferring features to later releases.
• Closure Forces closure on project issues. Using a versioned release allows the team to deal with a manageable number of issues during the Stabilizing Phase and to address all the issues before release.
• Goals Sets clear, motivating goals for all team members. The team can easily manage each version's scope and quickly achieve results, so team members see rapid progress. Their role in determining the schedule helps ensure that their tasks are manageable, specific, and associated with a tangible result.
• Freedom and flexibility Allows freedom and flexibility in the design process, enabling the team to be responsive to changes in the business environment. This freedom and flexibility reduces uncertainty and helps to manage the changes in project scope by allowing the team to vary features and schedules in relation to the overall plan. Features that become critical as a result of business changes can be designated as high priority for the next release. The early release becomes stable as the team starts work on the next one.
• Continuous and incremental feature delivery Dictates a new set of features immediately following the release of the completed set. As a result, the team continues to add value for the project's customer and users.

7. Explain the concept of tradeoffs and the tradeoff triangle of project variables.

Every project presents three variables with which the team must work. These three variables—schedule, resources, and features—are illustrated in the tradeoff triangle.

The relationship between these three variables tends to be hazy at the beginning of the development process. At that point, the team has a rough idea of what to build, an estimate of available resources, and an approximate target delivery date. During the Planning Phase, the project elements represented in the triangle become more distinct. By the time the Planning Phase is complete, the team knows the nature of available resources, the product features, and the fixed ship date.

It's important to keep in mind that the three variables are interrelated. Changes on one side of the tradeoff triangle affect the other two sides. If the team understands and utilizes this concept, it has both the rationale and the motivation to take corrective action as changes occur during development.

Chapter 5 -- Project Vision

1. What are the primary goals of the Envisioning Phase?

• Serve as an early form of planning.
• Establish clear communication and consensus from the beginning of the project.
• Help the team pull different perspectives into a common understanding.
• Provide the basis for future planning.
• Identify what the customer and key stakeholders deem essential for success.

2. What team roles are responsible for accomplishing envisioning goals?

• Product Management The primary driver for the Envisioning Phase. This role is responsible for delivering the Vision Document, managing customer expectations, and involving the customer in prototype development.
• Program Management Responsible for developing design goals, describing the solution concept, and outlining the project structure.
• Development Responsible for designing prototypes, outlining development options, and identifying implications of the vision.
• Testing Responsible for developing testing strategies, specifying acceptance criteria, designing a bug-tracking system, and designing a risk management system.
• User Education Responsible for identifying user performance needs and implications, managing user expectations, and involving users in prototype development.
• Logistics Management Responsible for identifying deployment implications and support implications of the product vision.

All roles are responsible for managing project risks.

3. What are the primary components of a Vision Document?

• A vision statement
• User research
• Competitive information
• Features and feature buckets
• A rough schedule

4. What are the benefits of using prototypes?

Clearly communicating the information learned from the customer and users is difficult. Information about business requirements must be communicated to team members with varying degrees of technical and business background, and information about how the product will solve the business problem must be communicated to the customer and users. To more easily accomplish this communication, a prototype application that demonstrates portions of the product's vision should be developed during the envisioning process and included in the Vision Approved Milestone deliverables. This prototype helps clarify existing ideas and helps draw out additional ideas from the team, the customer, and the product's users.

5. What are project risks?

Risk is the possibility of suffering loss. For a given project, this loss could be in the form of:

• Diminished product quality
• Increased costs
• Missed deadlines
• Complete failure to achieve the project's goals

6. What is risk management?

The identification and proactive mitigation of the risks a project might encounter, and the development of a system for managing those risks should they materialize during the project's life cycle.

Chapter 6 -- Project Plan

1. Why do we need a Planning Phase?

The Envisioning Phase asks the question "Can we use technology to solve this business need, and if so, how?" The result is a common understanding of the problem and a common vision of the solution. The Planning Phase asks the question "Realistically, what will it take to reach the vision developed in the Envisioning Phase?" The result is a detailed plan to which both the customer and the project team can agree.

The Planning Phase is where the dreams of the Envisioning Phase are tested against reality. It's here that the hard questions are asked. The Planning Phase involves difficult, detailed work, and as a result a project team may be tempted to avoid it or rush it. The truth is that the work done in this phase will determine the success or failure of the project. It is better to face the truth now, on paper, than to face it later in a failed implementation. The common vision established in the Envisioning Phase has to go through the refining fire of the Planning Phase for the team to be sure that the vision is strong enough to bear up during the Developing and Stabilizing Phases.

2. Describe the three designs of the MSF Design Process.

The MSF Design Process consists of three distinct types of design work: conceptual, logical, and physical. Each of these generates a model of the same name: the Conceptual Design Model, the Logical Design Model, and the Physical Design Model. Each part of the process approaches the design task from a different perspective and defines the solution differently.

• Conceptual Design Model Views the problem from the perspective of the user and the business, and defines the problem in terms of scenarios.
• Logical Design Model Views the solution from the perspective of the project team, and defines the solution as a set of cooperating services.
• Physical Design Model Views the solution from the perspective of the developers, and defines the solution's services and technologies.

The goals of the three parts are:

• Conceptual Design Identify business needs and understand what users do and what they require. Conceptual Design generates scenarios that reflect complete and accurate requirements, by involving the customer, users, and other stakeholders.
• Logical Design Organize the solution and the communication among its elements. Logical Design takes the business problem identified in Conceptual Design scenarios and formulates an abstract model of the solution. In other words, Logical Design takes the scenarios from Conceptual Design and produces objects and services, user interface prototypes, and logical database design.
• Physical Design Apply real-world technology constraints, including implementation and performance considerations, to the outputs of Logical Design by specifying the details of the solution. The outputs of Logical Design are used to produce components, user interface specifications, and physical database design.

3. What information is presented in a Functional Specification?

• Vision summary What the team wants the product to be, justification for the product, and key high-level constraints. Based on the Vision Document from the Envisioning Phase.
• Design goals What the team wants to achieve with the product. Development will use these goals to make decisions on such issues as performance, reliability, timeliness, and possibly usability and accessibility. These goals were originally developed during the Envisioning Phase.
• Requirements What the customer, users, and stakeholders think the product must do. The requirements should be prioritized. Conflicting requirements should either be resolved or balanced in some way.
• Usage summary When the product will be used and who will use it. This is a high-level aggregation of the usage scenarios that were defined during the design process.
• Features What exactly the product does. A prioritized list of product features, including such things as potential user interface, application navigation, and detailed functionality.
• Dependencies What the product depends on. A description of external entities upon which the product might depend, including both high-level issues (such as interfacing to corporate systems) and low-level issues (such as a shared component).
• Schedule summary What the schedule is. A summary of the Master Project Schedule, identifying key interim milestones, deliverables, and the product ship date.
• Risks What the risks are. A list of risks that require external visibility or escalation.
• Appendixes What remains. A collection of the design process output that the team used to develop the Functional Specification.

4. What is a Master Project Plan?

The Master Project Plan gathers detailed plans from members of the project team to tell how the product will be built. The team then uses this collection of more-detailed deliverables to synchronize its work throughout the remainder of the project.

The purpose of a Master Project Plan is to:

• Consolidate feature team and role work plans.
• Describe how feature teams and roles will execute their tasks.
• Synchronize the plans across the team.

The overall owner of the Master Project Plan is Program Management, because this role is the primary coordinator of planning and process for the project. However, each role on the team is responsible for developing and maintaining its own realistic project plan within the overall plan.

Chapter 7 -- User Service Layer Technologies

1. What is UI composition?

The layout of each UI element. It not only influences its aesthetic appeal, but also has a tremendous impact on the usability of the application. Composition includes such factors as:

• Positioning of controls
• Consistency of elements
• Affordances
• Use of white space
• Simplicity of design

2. What is usability?

How easily or effortlessly a particular application can be utilized by its intended users. Usability includes such issues as menu design, discoverability of features, navigation, and user assistance.

3. List some common issues encountered when designing the user service layer.

• Do any application requirements specify the type of UI?
• Do security issues, such as firewalls, impact communication between user workstations and server-side computers?
• What operating systems must be supported on user workstations?
• What Web browsers must be supported?
• Can COM components install and run on user workstations?
• Are remote COM components accessible from user workstations?

4. How can COM objects be used in the user service layer?

If the UI is a native application, installing and running COM components on user workstations probably isn't an issue. A Win32 application needs to be installed, but the COM components are simply treated as part of the application's installation routine. Things are somewhat more complicated for Web-based applications. Providing that a particular browser supports client-side COM components, the components usually download and automatically install on users' computers the first time the component is accessed.

ActiveX controls are COM objects that are sent from a Web server to execute on users' desktops with their browser. Some users, or the organizations for which they work, might worry about the security of automatically downloading and installing executable code on client computers. Some users might not allow any components to be downloaded to their computers. If Web-based applications must support such users or organizations, it is best not to use any client-side COM components (including ActiveX controls) unless the components are installed locally on the users' computers. Some users want to decide on a case-by-case basis whether to download and install particular components on their computers. In this case, developers might choose to use client-side COM components.

5. How does ASP fit in the user, business, and data access layers?

In an Internet application, a Web browser displays an HTML-page-based user service layer. Requests from this layer transmit via HTTP to a Web server. In response to these requests from the client Web browser, ASP pages activate on the Web server. The ASP pages can dynamically generate HTML pages to be returned to the requesting browser. These ASP pages can be used to generate user interface code to format and control the look and feel of the Web pages, thus ASP would be considered part of the user service layer. Also, the ASP pages can contain server-side script that implements business logic, thus ASP pages could be part of the business service layer. However, the ASP pages should contain server-side script that uses middle-tier business objects to do much of the work. The business objects might in turn call data access objects to access data sources in the data access service layer. Alternatively, the HTML and client-side script used to generate the user service layer might be located within the ASP pages. Either way, ASP straddles the line between the user service layer and the business service layer.

Chapter 8 -- Business Service Layer Technologies

1. What is the COM specification?

The specification document explaining COM and how it is implemented. Even though other technologies have been added to COM over the years (notably OLE and ActiveX), the fundamental component object model specification, introduced in 1992, remains the basis for COM. The COM specification is available on the Microsoft Web site (www.microsoft.com/com/resources/specs.ASP), and only those items defined in the specification are part of COM proper.

2. How can COM work across computers?

By utilizing the services provided by DCOM (Distributed COM). Technically, DCOM refers specifically to the wire protocol for making COM calls between two computers. However, the term DCOM is often used to refer to the entire concept of COM communication across computers.

3. How does MTS handle security?

MTS server packages are units of trust for MTS. Calls into a package can be secured. Calls within the package are trusted. Thus, application security requirements have a big impact on package design. If calls into a component must be authorized, clients and components must be allocated into different packages. Only components that can safely call each other without requiring an authorization check should be allocated into one package.

4. What is COM+?

Basically speaking, COM+ is the evolution of COM, which has been around for a long time, and also of MTS, which shipped with Windows NT 4 in the Option Pack. Microsoft combines COM and MTS into a single programming model, COM+, which ships with Windows 2000.

5. What are the primary services in COM+ 1.0?

• Servers
• Transactions
• Security
• Administration
• Load balancing
• Queued components
• Events
• In-memory database

Chapter 9 -- Data Service Layer Technologies

1. What is the UDA?

The Microsoft Universal Data Architecture (UDA) is designed to provide high-performance access to any type of data—structured or unstructured, relational or non-relational—stored anywhere in an enterprise. UDA defines a set of COM interfaces that actualize the concept of accessing data. UDA is based on OLE DB, a set of COM interfaces for building database components. OLE DB allows data stores to expose their native functionality without making nonrelational data appear relational. OLE DB also provides a way for generic service components, such as specialized query processors, to augment features of simpler data providers. Because OLE DB is optimized for efficient data access rather than ease of use, UDA also defines an application-level programming interface, or Microsoft ActiveX Data Objects (ADO). ADO exposes dual interfaces to easily be used with scripting languages as well as with C++, Microsoft Visual Basic, and other development tools.

UDA is a platform, application, and tools initiative that defines and delivers both standards and technologies tailored to providing enterprise data access. It is a key element in the Microsoft foundation for application development. In addition, UDA provides high-performance access to a variety of information resources, including relational and non-relational data, and an easy-to-use programming interface that is tool-independent and language-independent.

2. Which data access components are available from Microsoft?

Microsoft Data Access Components (MDAC) provides a UDA implementation that includes ADO as well as an OLE DB provider for ODBC. This capability enables ADO to access any database that has an ODBC driver—in effect, all major database platforms. OLE DB providers are also available for other types of stores, such as the Microsoft Exchange mail store, Windows NT Directory Services, and Microsoft Windows file system using Microsoft Index Server.

3. What is the recommended Data Access Component?

ADO is Microsoft's premier data access technology. The ADO data access technology and its partner OLE DB comprise the recommended solution for all data access. A development team working on a new application should definitely use ADO.

4. How can applications access host-based data with COM?

By using the Microsoft OLE DB Provider for AS/400 and VSAM.

5. What is COM+ IMDB?

A new feature in COM+, the In-Memory Database, a database that maintains its tables in memory.

Chapter 10 -- Testing and the Production Channel

1. What are the stages of the production channel?

• Development
• Testing
• Certification
• Production

2. What are some advantages of the production channel?

• Any problems will be discovered in the testing or certification stage, rather than in the production stage.
• Formal testing is always done.
• An organized process is used to introduce change.

3. What are key areas to consider when defining performance requirements?

• Project constraints must be identified.
• Services to be performed by the application must be determined.
• The load on the application must be specified.

4. What is a performance baseline?

The results of the initial performance tests.

5. What are the two categories of testing?

During the Developing Phase, coverage testing attempts to thoroughly test each feature of the product as well as the actual code base of the product in a relatively closed environment. During the Stabilizing Phase, testing shifts from coverage testing to usage testing, which validates the application's fulfillment of the use cases and usage scenarios developed during the Envisioning Phase. This stage of testing usually includes involving actual users of the product in beta tests, and preferably occurs in the application's production environment. Tolerance for bugs decreases as testing progresses through the Stabilizing Phase, and because the focus is on shipping during this phase, being able to successfully manage bugs is paramount.

6. What are the stages of bug management?

• Reporting
• Prioritization
• Assignment
• Resolution
• Closure

Chapter 11 -- Application Security

1. What is authentication?

Identifying and validating users, and potentially revalidating users as an ongoing process.

2. What are several methods for Web-based authentication?

• Windows NT Challenge/Response
• Cookies
• Digital certificates

3. What is encryption?

A means of protecting sensitive information transmitted over a network from all forms of interception and tampering by converting the data to random nonsense data, usually involving agreed-upon algorithms for transmission and reception.

4. What is access security?

In simple terms, access security is about who can use the application and how they can use it. With a secure application, both the user and the application are confident they are exchanging information within authentic circumstances. Applications must ensure the privacy of sensitive user information, and also protect the architectural components and services that run the application from unauthorized tampering or eavesdropping by the user. For an application to be secure, each application service must be available only to qualified users. At the same time, every component, service, and supporting file must be protected from unauthorized viewing, tampering, or modification.

5. Why should applications provide auditing services?

Auditing provides a tracking mechanism to identify security breaches. In addition to security auditing, simple auditing can operate as application monitoring to help determine what an application is doing and who did what with the application.

6. Which Windows NT services provide mechanisms for auditing?

• Windows NT system auditing System auditing includes user logon and logoff, object access, file and object access, use of user rights, user and group management, security policy changes, system restart and shutdown, and Process Tracking.
• File and directory auditing This type of auditing can be set to determine the success and/or failure of read, write, execute, delete, change-permission, and take-ownership actions.
• Registry auditing Auditing within the registry can be set to determine the success and/or failure of query values, set values, create subkeys, enumerate subkeys, notify, create links, delete, write DAC, and read control.

Chapter 12 -- Development Deliverables

1. What are the seven deliverables of the Developing Phase?

• Revised Functional Specification
• Revised Master Project Plan
• Revised Master Project Schedule
• Revised Master Risk Assessment Document
• Source code and executables
• User performance materials
• Testing elements

2. What are interim product releases?

Releases of the product prior to the Scope Complete Milestone, typically called Internal, Alpha, and Beta.

3. What are the benefits of interim product releases?

• Break the Developing Phase into manageable portions.
• Encourage a product-shipping mindset.
• Provide a way for the team to measure progress as a whole.
• Force the product team to synchronize the code at a product level.
• Force the team to achieve user interface and database freeze points, thus resulting in fewer changes to the dependant documentation and code.
• Address high-risk architectural areas to determine feasibility or identify development changes required, thus minimizing the cost and effect of design changes.
• Help the team focus on more actionable subsets that can direct daily progress.
• Increase quality by providing a more stable base for new development.
• Allow the team to fix bugs closer to the time at which they occur rather than toward the end of the project.

4. What are three ways a bug can be resolved?

Any three of the following:

• Fixed The developer has fixed the bug, tested the fix, checked in the code, assigned the fix to a release number, and assigned the bug back to the tester who reported it.
• Duplicate The bug reported is a duplicate of another bug already recorded in the bug database. The duplicate bug should be closed and linked to the original bug.
• Postponed The bug will not be fixed in the current release, but might be fixed in a subsequent one. This designation should be used when the team sees value in fixing the bug, but does not have the time or resources to correct it during the current release being tested.
• By design The behavior reported in a particular bug is intentional and acknowledged in the Functional Specification.
• Can't reproduce The developer can't verify the existence of the bug with any level of consistency.
• Won't fix The bug will not be fixed in the current release, because the team does not think fixing the bug is worth any effort.

5. When is a team ready to move to the Stabilizing Phase?

• All product features are implemented, even if not fully optimized.
• The product has passed basic testing and the current list of bugs has been addressed, although not necessarily fixed.
• Team members and key stakeholders agree that the included features meet the product vision and design, and have been successfully implemented.
• User performance materials are baselined and ready for testing and stabilization.

Chapter 13 -- Product Stabilization

1. What is the primary goal of the Stabilizing Phase?

To prepare the product for release to the customer.

2. How does the team incrementally reach the Release Milestone?

During the Stabilizing Phase, the team may ship multiple external product releases while driving toward the final product release. During these interim releases, the team will primarily focus on testing to identify bugs, and fixing the bugs that are identified. A significant interim milestone that signifies the team is getting close to releasing a product is generally referred to as the zero-bug release (ZBR). ZBR is the first interim product release in which all active bugs have been resolved in some manner, whether fixed, postponed, or deemed unimportant. Once an interim release is shipped, extensive testing must occur to determine whether the product is ready, at which point the team can declare victory and classify the release as the Final Product Release.

3. What are the primary steps of the Stabilizing Phase?

Unlike the other phases of the development process, this phase is not characterized by action steps; rather, it is characterized by interim releases. The same steps are repeated within each interim release:

• Fix the bugs
• Synchronize all product deliverables
• Ship the release
• Extensively test the release

Eventually, the team will determine that a release is ready for prime time, and that will be the Final Product Release.

4. What are the primary interim releases of the Stabilizing Phase?

• One or more interim releases with a decreasing number of bugs
• Zero-bug release (ZBR)
• One or more release candidates
• Final Product Release

5. What are the deliverables of the Stabilizing Phase?

• Final product release Source code and executables.
• Product release notes Documents containing release information and late changes.
• User and support performance artifacts The final release of supporting information.
• Testing results The bug status and database for future projects.
• Project archives All relevant product information created during the development process, whether or not it shipped with the product.
• Project documents All stages of the product documentation including the major milestone releases.

6. What are some of the deployment methods that can be used within an organization?

• Microsoft Systems Management Server (SMS)
• Logon scripts
• E-mail distributions
• Web-based advertisements

Chapter 14 -- Project Review

1. List the benefits of a project review.

• Provide project closure Closure is important if team members have spent time and energy on the completed project, and will begin another project immediately. Project closure is particularly important if the project team will soon dissolve. Official project closure will also help the team members move on to something new.
• Provide a final outlet for team communication A project review can be cathartic for team members who have strong feelings about particular aspects of a project. If not expressed in a controlled manner and setting, team members may express such feelings later in less desirable circumstances, places, or means.
• Address the team's morale Project reviews may actually enhance team morale by allowing teammates to share positive as well as negative feelings, and also to offer praise throughout the team.
• Set best-practice baselines Future teams may also benefit from project reviews by accessing the current team's perception of the project's strengths and weaknesses. Such perceptions can provide the basis for creating best-practice baselines for software development within an organization.
• Establish feedback loops Ultimately, all the project review output can be combined into a best practice baseline and should be used as input for subsequent projects. Organizations should be able to apply project review insights for the purpose of improving future projects.

2. Discuss the relationship between project reviews and the CMM for Software.

Project reviews are important tools in evolving an organization to a more efficient CMM maturity level. One characteristic of a CMM Level 1 organization is reinventing processes for each project. By conducting project reviews and implementing the reviews' results as standard practices, an organization can avoid this inefficient, but common, problem.

Two key challenges for CMM Level 2 organizations are accurate project planning and effective project tracking. Using project reviews to compare plans with actual events and timelines enables an organization to hone its estimating and tracking skills. Over time, an organization at this level can create an increasingly realistic sense of time and resources that project tasks require.

Project reviews are critical to reaching CMM Level 3. Although most Level 2 organizational discipline is seen at a project level, members of an individual project can usually find good practices that could be useful in another project. Leveraging those best practices across the organization and defining processes that can be tailored to each project is the heart of Level 3. Project teams generally accumulate a rich process history as they complete their project. They should keep this data in a repository for use by other project teams on future projects. The organization will develop an appreciation for common processes and advisors who can help tailor those processes.

At CMM Levels 4 and 5, the fundamental purpose of the project review is to facilitate the feedback loop. As the team identifies problems, it can change its processes to eliminate or mitigate such problems in future projects.

3. List some practical considerations involved in project reviews.

• Timing
• Formality
• Length
• Setting
• Attendees

4. Explain methods to conduct project reviews for large projects.

Program Management may choose to organize a project review team when planning a review for larger projects. The team approach works especially well when several project teams are involved in a large project.

Program Management may use a variety of tactics in organizing a project review team. For instance, functional discipline groups can be created: one for development, one for testing, one for user education, and one for program management. Another example of a project review team is a multifunctional group comprised of members from each functional discipline, based on the particular development process phases.