Cover Page

Copyright © 2003 by Microsoft Corporation


LOC Page

PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399

Copyright © 2003 by Microsoft Corporation

All rights reserved. No part of the contents of this book may be reproduced
or transmitted in any form orby any means without the written permission
of the publisher.

Library of Congress Cataloging-in-Publication Data pending.

Printed and bound in the United States of America.

1 2 3 4 5 6 7 8 9   QWT   8 7 6 5 4 3

Distributed in Canada by H.B. Fenn and Company Ltd.

A CIP catalogue record for this book is available from the British Library.

Microsoft Press books are available through booksellers and distributors
worldwide. For further information about international editions, contact
your local Microsoft Corporation office or contact Microsoft Press
International directly at fax (425) 936-7329. Visit our Web site at
www.microsoft.com/mspress. Send comments to tkinput@microsoft.com.

Active Directory, ActiveX, Authenticode, BizTalk, Microsoft, Microsoft
Press, MS-DOS, MSDN, Outlook, PowerPoint, SharePoint, Visio, Visual Basic,
Visual C++, Visual C#, Visual Studio, Windows, Windows Media, and Windows
NT are either registered trademarks or trademarks of Microsoft Corporation
in the United States and/or other countries. Other product and company names
mentioned herein may be the trademarks of their respective owners.

The example companies, organizations, products, domain names, e-mail addresses,
logos, people, places, and events depicted herein are fictitious. No association
with any real company, organization, product, domain name, e-mail address, logo,
person, place, or event is intended or should be inferred.

Acquisitions Editor: Kathy Harding
Project Editor: Karen Szall

Body Part No. X09-35331


About This Book

Welcome to MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300. By completing the chapters and the associated activities in this course, you will acquire the knowledge and skills necessary to prepare for the Microsoft Certified Solution Developer (MCSD) Exam 70-300. This self-paced course provides content that supports the skills measured by this exam. Answer the questions at the end of each chapter to review what you have learned and help you prepare more thoroughly. The course also includes solution documents that provide you with examples of the outputs of each phase in the Microsoft Solutions Framework (MSF) development process.

NOTE
For more information about becoming a Microsoft Certified Professional, see the section titled “The Microsoft Certified Professional Program” later in this introduction.

Each chapter in this book is divided into lessons. Most lessons include hands-on procedures that allow you to practice or demonstrate a particular concept or skill. Each chapter ends with a short summary of all chapter lessons and a set of review questions to test your knowledge of the chapter material.

The “Getting Started” section of this introduction provides important setup instructions that describe the hardware and software requirements to complete the procedures in this course. It also provides information about the networking configuration necessary to complete some of the hands-on procedures. Read through this section thoroughly before you start the lessons.


Intended Audience

This book was developed for information technology (IT) professionals who plan to take the related Microsoft Certified Professional exam 70-300, Analyzing Requirements and Defining Microsoft .NET Solution Architectures, as well as IT professionals who design, develop, and implement software solutions for Microsoft Windows–based environments using Microsoft tools and technologies.


Prerequisites

This training kit requires that students meet the following prerequisites:

  • A general understanding of the software development life cycle.

  • Practical working knowledge of Microsoft .NET development technologies.

  • Familiarity with the MSF Process Model.

  • Basic familiarity with object modeling and data modeling methodologies.

  • Experience working with Microsoft Visio Professional 2000.

  • One year experience as part of a software development team.


Reference Materials

You might find the following reference materials useful:

  • MSF Process Model white paper on the Microsoft Solutions Framework Web site at http://www.microsoft.com/msf/.

  • Unified Modeling Language (UML) modeling techniques from the following resources:

    • Booch, Grady, Ivar Jacobson, and James Rumbaugh. The Unified Modeling Language User Guide (Addison-Wesley, 1999)

    • Rosenberg, Doug, with Kendall Scott. Use Case Driven Object Modeling with UML: A Practical Approach (Addison-Wesley, 1999)


About the CD-ROM

For your use, this book includes a Supplemental Course Materials CD-ROM. This CD-ROM contains a variety of informational aids to complement the book content:

  • An electronic version of this book (eBook). For information about using the eBook, see the section “About the eBook” later in this introduction.

  • Files you will need to perform the hands-on procedures. Also included are sample solution documents.

  • A practice test that contains 100 questions. Use the questions to practice taking a certification exam and to help you assess your understanding of the concepts presented in this book.

For additional support information regarding this book and the CD-ROM (including answers to commonly asked questions about installation and use), visit the Microsoft Press Technical Support Web site at http://www.microsoft.com/mspress/support/. You can also e-mail tkinput@microsoft.com or send a letter to Microsoft Press, Attention: Microsoft Press Technical Support, One Microsoft Way, Redmond, WA 98052-6399.


Features of This Book

Each chapter opens with a “Before You Begin” section, which prepares you for completing the chapter. The chapters are then broken into lessons. At the end of each chapter is an activity made up of one or more exercises. These activities give you an opportunity to use the skills being presented or explore the concepts being described.

The “Review” section at the end of the chapter allows you to test what you have learned in the chapter’s lessons. Appendix A, “Questions and Answers,” contains all of the book’s questions and corresponding answers.


Notes

Several types of notes appear throughout the lessons.

TIP
These boxes contain explanations of possible results or alternative methods.
IMPORTANT
These boxes contain information that is essential to completing a task.
NOTE
Notes generally contain supplemental information.
CAUTION
These warnings contain critical information about the possible loss of data.
More Info
References to other sources of information are offered throughout the book.
Planning
Hints and useful information will help you plan implementation in your environment.


Conventions

The following conventions are used throughout this book.

Notational Conventions

  • Characters or commands that you type appear in bold type.

  • Italic in syntax statements indicates placeholders for variable information. Italic is also used for book titles.

  • Names of files and folders appear in Title caps, except when you are to type them directly. Unless otherwise indicated, you can use all lowercase letters when you type a file name in a dialog box or at a command prompt.

  • File name extensions appear in all lowercase.

  • Acronyms and abbreviations appear in all uppercase.

  • Monospace type represents code samples, examples of screen text, or entries that you might type at a command prompt or in initialization files.

  • Square brackets [ ] are used in syntax statements to enclose optional items. For example, [filename] in command syntax indicates that you can choose to type a file name with the command. Type only the information within the brackets, not the brackets themselves.

  • Braces { } are used in syntax statements to enclose required items. Type only the information within the braces, not the braces themselves.

Keyboard Conventions

  • A plus sign (+) between two key names means that you must press those keys at the same time. For example, “Press Alt+Tab” means that you hold down Alt while you press Tab.

  • A comma ( , ) between two or more key names means that you must press each of the keys consecutively, not together. For example, “Press Alt, F, X” means that you press and release each key in sequence. “Press Alt+W, L” means that you first press Alt and W at the same time, and then release them and press L.

  • You can choose menu commands with the keyboard. Press the Alt key to activate the menu bar, and then sequentially press the keys that correspond to the highlighted or underlined letter of the menu name and the command name. For some commands, you can also press a key combination listed in the menu.

  • You can select or clear check boxes or option buttons in dialog boxes with the keyboard. Press the Alt key, and then press the key that corresponds to the underlined letter of the option name. Or you can press Tab until the option is highlighted, and then press the spacebar to select or clear the check box or option button.

  • You can cancel the display of a dialog box by pressing the Esc key.


Chapter and Appendix Overview

This self-paced training kit combines notes, hands-on procedures, and review questions to teach you about designing solutions architecture in a Microsoft .NET environment. It is designed to be completed from beginning to end, but you can choose a customized track and complete only the sections that interest you.

The book is divided into the following sections:

  • “About This Book” contains a self-paced training overview and introduces the components of this training. Read this section thoroughly to get the greatest educational value from this self-paced training and to plan which lessons you will complete.

  • Chapter 1, “Introduction to Designing Business Solutions,” describes the Microsoft Solutions Framework (MSF). It begins with an overview of the MSF Process Model and its various phases. The chapter also describes the key activities performed in designing an application and the deliverables associated with those activities. In addition, the chapter describes the case study that is used in the course. All the practices and solution documents are created for the case study.

  • Chapter 2, “Gathering and Analyzing Information,” describes the process of gathering and analyzing information for designing a business solution. The chapter begins by describing the types of information that you need to gather, sources of information, and some techniques, such as interviews, shadowing, and prototyping that can be used for gathering information. The chapter then describes how to analyze all the information that is gathered from interviews and other gathering techniques. The chapter discusses use cases, usage scenarios, and other techniques that can be used for analyzing information.

  • Chapter 3, “Envisioning the Solution,” discusses the envisioning phase of the MSF development process. The chapter begins by describing the purpose of the envisioning phase in application design. It then describes the roles and responsibilities of team members during this phase. It also discusses the major tasks of the envisioning phases. Finally, the chapter describes how to define the vision of the project and analyze risks associated with the project.

  • Chapter 4, “Creating the Conceptual Design,” describes the conceptual design process of the planning phase in the MSF development process. The chapter first discusses the purpose of the planning phase and provides an overview of the three design processes that occur during the planning phase: conceptual, logical, and physical design. The chapter also explains the purpose and benefits of functional specification. The chapter then describes the conceptual design process in detail, and discusses the three steps of conceptual design: research, analysis, and optimization.

  • Chapter 5, “Creating the Logical Design,” explains the logical design process of the planning phase. The chapter begins with an overview of the purpose and benefits of logical design, and then describes the team composition and the roles of each member during this process. The chapter then describes in detail how to create the logical design for a business solution. It also discusses the various tools and techniques that can be used for documenting the outputs of logical design. Finally, the chapter describes how to optimize the logical design. Validating against requirements is recommended as the best strategy for optimizing the logical design in this chapter.

  • Chapter 6, “Creating the Physical Design,” describes the physical design process of the planning phase. The chapter first discusses the purpose of physical design. The chapter also discusses the deliverables of physical design. The chapter then describes in detail the tasks involved in completing the physical design process: research, analysis, rationalization, and implementation.

  • Chapter 7, “Designing the Presentation Layer,” discusses how to design the presentation layer of an application. The chapter begins with an overview of the presentation layer and its two components: user interface and user process. The chapter then describes how to design the user interface and user process components of an application and also recommends some guidelines for the design process.

  • Chapter 8, “Designing the Data Layer,” describes how to design the data layer for an application. The chapter also discusses how to optimize data access and implement data validation in an application.

  • Chapter 9, “Designing Security Specifications,” describes the design guidelines for creating security specifications for an application. The chapter recommends some tools and methods for assessing the threats to an application and the mitigation techniques that can be used for resolving the threats. The chapter also describes some security features of Microsoft .NET technologies. Finally, the chapter discusses the steps and the guidelines that can be followed for designing authentication, authorization, and auditing for an application.

  • Chapter 10, “Completing the Planning Phase,” describes the tasks and plans on which the project team works to complete the planning phase of the project. This chapter describes the guidelines and recommended practices for designing for scalability, availability, reliability, performance, interoperability, and globalization and localization. The chapter discusses how to plan for administrative features such as monitoring, data migration, and licensing specifications. In addition, the chapter discusses the development plan, the test plan, the pilot plan, the deployment plan, and the migration plan. The chapter also discusses the purpose and contents of a technical specification document.

  • Chapter 11, “Stabilizing and Deploying the Solution,” describes the tasks involved in stabilizing and deploying a solution. The chapter first discusses the stabilizing phase and explains in detail the various types of testing that can be performed to stabilize a solution. The chapter also describes the tasks involved in conducting a pilot. Next, the chapter describes the process of deployment. The chapter discusses how to plan for deployment, and the various strategies that can be used for deploying a solution.

  • Appendix A, “Questions and Answers,” lists all of the review questions from the book showing the page number where the question appears and the suggested answer.

  • The glossary provides definitions for many of the terms and concepts presented in this training kit.


Where to Find Specific Skills in This Book

The following tables provide a list of the skills measured by certification exam 70-300, Analyzing Requirements and Defining Microsoft .NET Solution Architectures. The table specifies the skill and the location in this book where you can find the lesson relating to that skill.

NOTE
Exam skills are subject to change without prior notice and at the sole discretion of Microsoft.
Envisioning the Solution

Skill Being Measured

Location in Book

Develop a solution concept.

Chapter 3, Lesson 2

Analyze the feasibility of the solution.

  • Analyze the business feasibility of the solution.

  • Analyze the technical feasibility of the solution.

  • Analyze available organizational skills and resources.

Chapter 3, Lesson 2

Analyze and refine the scope of the solution project.

Chapter 3, Lesson 2

Identify key project risks.

Chapter 3, Lesson 4

Gathering and Analyzing Business Requirements

Skill Being Measured

Location in Book

Gather and analyze business requirements.

  • Analyze the current business state.

  • Analyze business requirements for the solution.

Chapter 2, Lessons 1 and 2, and Chapter 4, Lesson 4

Gather and analyze user requirements.

  • Identify use cases.

  • Identify globalization requirements.

  • Identify localization requirements.

  • Identify accessibility requirements.

Chapter 2, Lessons 1 and 2, and Chapter 4, Lesson 4

Gather and analyze operational requirements.

  • Identify maintainability requirements.

  • Identify scalability requirements.

  • Identify availability requirements.

  • Identify reliability requirements.

  • Identify deployment requirements.

  • Identify security requirements.

Chapter 2, Lessons 1 and 2, and Chapter 4, Lesson 4

Gather and analyze requirements for hardware, software, and network infrastructure.

  • Identify integration requirements.

  • Analyze the IT environment, including current and projected applications and current projected hardware, software, and network infrastructure.

  • Analyze the impact of the solution on the IT environment.

Chapter 2, Lessons 1 and 2, and Chapter 4, Lesson 4

Developing Specifications

Skill Being Measured

Location in Book

Transform requirements into functional specifications. Considerations include performance, maintainability, extensibility, scalability, availability, deployability, security, and accessibility.

Chapter 4, all lessons; Chapter 6, Lesson 3; and Chapter 10, Lesson 1

Transform functional specifications into technical specifications. Considerations include performance, maintainability, extensibility, scalability, availability, deployability, security, and accessibility.

  • Select a development strategy.

  • Select a deployment strategy.

  • Select a security strategy.

  • Select an operations strategy.

  • Create a test plan.

  • Create a user education plan.

Chapter 10, Lesson 4

Creating the Conceptual Design

Skill Being Measured

Location in Book

Create a conceptual model of business requirements or data requirements. Methods include Object Role Modeling (ORM).

  • Transform external information into elementary facts.

  • Apply a population check to fact types.

  • Identify primitive entity types in the conceptual model.

  • Apply uniqueness constraints to the conceptual model.

  • Apply mandatory role constraints to the conceptual model.

  • Add value constraints, set-comparison constraints, and subtype constraints to the conceptual model.

  • Add ring constraints to the conceptual model.

Chapter 4, all lessons and Chapter 2, Lesson 3

Creating the Logical Design

Skill Being Measured

Location in Book

Create the logical design for the solution.

  • Create the logical design for auditing and logging.

  • Create the logical design for error handling.

  • Create the logical design for integration.

  • Create the logical design for globalization.

  • Create the logical design for localization.

  • Create the logical design for security.

  • Include constraints in the logical design to support business rules.

  • Create the logical design for the presentation layer, including the user interface (UI).

  • Create the logical design for services and components.

  • Create the logical design for state management.

  • Create the logical design for synchronous or asynchronous architecture.

Chapter 5, all lessons

Create the logical data model.

  • Define tables and columns.

  • Normalize tables.

  • Define relationships.

  • Define primary and foreign keys.

  • Define the XML schema.

Chapter 5, Lesson 3

Validate the proposed logical design.

  • Review the effectiveness of the proposed logical design in meeting business requirements. Business requirements include performance, maintainability, extensibility, scalability, availability, deployability, security, and accessibility.

  • Validate the proposed logical design against usage scenarios.

  • Create a proof of concept for the proposed logical design.

Chapter 5, Lesson 4

Creating the Physical Design

Skill Being Measured

Location in Book

Select the appropriate technologies for the physical design of the solution.

Chapter 5, Lesson 2

Create the physical design for the solution.

  • Create specifications for auditing and logging.

  • Create specifications for error handling.

  • Create specifications for physical integration.

  • Create specifications for security.

  • Include constraints in the physical design to support business rules.

  • Design the presentation layer, including the UI and online user assistance.

  • Design services and components.

  • Design state management.

Chapter 6, all lessons; Chapter 7 all lessons; Chapter 9, Lesson 3

Create the physical design for deployment.

  • Create deployment specifications, which can include coexistence and distribution.

  • Create licensing specifications.

  • Create data migration specifications.

  • Design the upgrade path.

Chapter 10, Lesson 2

Create the physical design for maintenance.

  • Design application monitoring.

Chapter 10, Lesson 2

Create the physical design for the data model.

  • Create an indexing specification.

  • Partition data.

  • Denormalize tables.

Chapter 8, Lesson 2

Validate the physical design.

  • Review the effectiveness of the proposed physical design in meeting the business requirements. Business requirements include performance, maintainability, extensibility, scalability, availability, deployability, security, and accessibility.

  • Validate use cases, scenario walk-throughs, and sequence diagrams.

  • Create a proof of concept for the proposed physical design.

Chapter 6, Lessons 3 and 4

Creating Standards and Processes
Skill Being Measured | Location in Book
Establish standards. Standards can apply to development documentation, coding, code review, UI, and testing. | Chapter 11, Lesson 2
Establish processes. Processes include reviewing development documentation, reviewing code, creating builds, tracking issues, managing source code, managing change, managing release, and establishing maintenance tasks. Methods include Microsoft Visual Studio .NET Enterprise Templates. | Chapter 11, Lesson 2
Establish quality and performance metrics to evaluate project control, organizational performance, and return on investment. | Chapter 11, Lessons 1 and 2


Getting Started

This self-paced training course contains hands-on procedures to help you learn about building solution architecture in a Microsoft .NET environment.

Hardware Requirements

Each computer must have the following minimum configuration. All hardware should be on the Microsoft Windows 2000 Professional Hardware Compatibility List.

  • Pentium II, 266 MHz or faster

  • 128 MB RAM

  • 4-GB hard drive

  • CD-ROM drive

  • Microsoft Mouse or compatible pointing device

Software Requirements

The following minimum software is required to complete the procedures in this course.

  • Microsoft Windows 2000 Professional with Service Pack 3, or Microsoft Windows XP Professional

  • Microsoft Office 2000 Professional with Service Pack 3 or later

  • Microsoft Visio 2000 Professional or later


Setup Instructions

Set up your computer according to the manufacturer’s instructions.

The Solution Documents

The Supplemental Course Materials CD-ROM contains a set of files that you will need to copy to your hard disk to complete many of the exercises in this book. To access the Solution Documents folder:

  1. Insert the Supplemental Course Materials CD-ROM into your CD-ROM drive.

    NOTE
    If Autorun is disabled on your machine, run StartCD.exe in the root directory of the CD-ROM or refer to the Readme.txt file.

  2. Select Solution Documents on the user interface menu, and then browse to the chapter folder you want to view.

The eBook

The CD-ROM also includes a fully searchable electronic version of the book. To view the eBook, you must have Microsoft Internet Explorer 5.01 or later and the corresponding HTML Help components on your system. If your system does not meet these requirements, you can install Internet Explorer 6 SP1 from the CD-ROM prior to installing the eBook.

To use the eBook

  1. Insert the Supplemental Course Materials CD-ROM into your CD-ROM drive.

    NOTE
    If AutoRun is disabled on your machine, refer to the Readme.txt file on the CD-ROM.

  2. Click eBook on the user interface menu and follow the prompts.

    NOTE
    You must have the Supplemental Course Materials CD-ROM inserted in your CD-ROM drive to run the eBook.


The Microsoft Certified Professional Program

The Microsoft Certified Professional (MCP) program provides the best method to prove your command of current Microsoft products and technologies. Microsoft, an industry leader in certification, is on the forefront of testing methodology. The exams and corresponding certifications are intended to validate your mastery of critical competencies as you design and develop, or implement and support, solutions with Microsoft products and technologies. Computer professionals who become Microsoft certified are recognized as experts and are sought industry‑wide.

The Microsoft Certified Professional program offers multiple certifications, based on specific areas of technical expertise:

  • Microsoft Certified Professional (MCP). Demonstrated in-depth knowledge of at least one Microsoft Windows operating system or architecturally significant platform. An MCP is qualified to implement a Microsoft product or technology as part of a business solution for an organization.

  • Microsoft Certified Solution Developer (MCSD). Professional developers qualified to analyze, design, and develop enterprise business solutions with Microsoft development tools and technologies including the Microsoft .NET Framework.

  • Microsoft Certified Application Developer (MCAD). Professional developers qualified to develop, test, deploy, and maintain powerful applications using Microsoft tools and technologies including Microsoft Visual Studio .NET and XML Web services.

  • Microsoft Certified Systems Engineer (MCSE). Qualified to effectively analyze the business requirements, and design and implement the infrastructure for business solutions based on the Microsoft Windows and Microsoft Server 2003 operating system.

  • Microsoft Certified Systems Administrator (MCSA). Individuals with the skills to manage and troubleshoot existing network and system environments based on the Microsoft Windows and Microsoft Server 2003 operating systems.

  • Microsoft Certified Database Administrator (MCDBA). Individuals who design, implement, and administer Microsoft SQL Server databases.

  • Microsoft Certified Trainer (MCT). Instructionally and technically qualified to deliver Microsoft Official Curriculum through a Microsoft Certified Technical Education Center (CTEC).


Microsoft Certification Benefits

Microsoft certification, one of the most comprehensive certification programs available for assessing and maintaining software-related skills, is a valuable measure of an individual’s knowledge and expertise. Microsoft certification is awarded to individuals who have successfully demonstrated their ability to perform specific tasks and implement solutions with Microsoft products. Certification brings a variety of benefits to the individual and to employers and organizations.

Microsoft Certification Benefits for Individuals

As a Microsoft Certified Professional, you receive many benefits:

  • Industry recognition of your knowledge and proficiency with Microsoft products and technologies.

  • A Microsoft Developer Network subscription. MCPs receive rebates or discounts on a one-year subscription to the Microsoft Developer Network (http://msdn.microsoft.com/subscriptions/) during the first year of certification. (Fulfillment details will vary, depending on your location; please see your Welcome Kit.)

  • Access to technical and product information direct from Microsoft through a secured area of the MCP Web site (go to http://www.microsoft.com/traincert/mcp/mcpsecure.asp).

  • Access to exclusive discounts on products and services from selected companies. Individuals who are currently certified can learn more about exclusive discounts by visiting the MCP secured Web site (go to http://www.microsoft.com/traincert/mcp/mcpsecure.asp, log in, and select the “Other Benefits” link).

  • MCP logo, certificate, transcript, wallet card, and lapel pin to identify you as a Microsoft Certified Professional (MCP) to colleagues and clients. Electronic files of logos and transcript can be downloaded from the MCP secured Web site (go to http://www.microsoft.com/traincert/mcp/mcpsecure.asp) upon certification.

  • Invitations to Microsoft conferences, technical training sessions, and special events.

  • Free access to Microsoft Certified Professional Magazine Online, a career and professional development magazine. Secured content on the Microsoft Certified Professional Magazine Online Web site includes the current issue (available only to MCPs), additional online-only content and columns, an MCP-only database, and regular chats with Microsoft and other technical experts.

  • Discount on membership to PASS (for MCPs only), the Professional Association for SQL Server. In addition to playing a key role in the only worldwide, user-run SQL Server user group endorsed by Microsoft, members enjoy unique access to a world of educational opportunities (go to http://www.microsoft.com/traincert/mcp/mcpsecure.asp).

An additional benefit is received by Microsoft Certified System Engineers (MCSEs):

  • A 50 percent rebate or discount on a one-year subscription to TechNet or TechNet Plus during the first year of certification. (Fulfillment details will vary, depending on your location. Please see your Welcome Kit.) A TechNet subscription provides MCSEs with a portable IT survival kit that is updated monthly. It includes the complete Microsoft Knowledge Base as well as service packs and kits.

An additional benefit is received by Microsoft Certified System Database Administrators (MCDBAs):

  • A 50 percent rebate or discount on a one-year subscription to TechNet or TechNet Plus during the first year of certification. (Fulfillment details will vary, depending on your location. Please see your Welcome Kit.) A TechNet subscription provides MCSEs with a portable IT survival kit that is updated monthly. It includes the complete Microsoft Knowledge Base as well as service packs and kits.

  • A one-year subscription to SQL Server Magazine. Written by industry experts, the magazine contains technical and how-to tips and advice—a must for anyone working with SQL Server.

A list of benefits for Microsoft Certified Trainers (MCTs) can be found at http://www.microsoft.com/traincert/mcp/mct/benefits.asp.

Microsoft Certification Benefits for Employers and Organizations

Through certification, computer professionals can maximize the return on investment in Microsoft technology. Research shows that Microsoft certification provides organizations with:

  • Excellent return on training and certification investments by providing a standard method of determining training needs and measuring results.

  • Increased customer satisfaction and decreased support costs through improved service, increased productivity and greater technical self-sufficiency.

  • Reliable benchmark for hiring, promoting, and career planning.

  • Recognition and rewards for productive employees by validating their expertise.

  • Retraining options for existing employees so they can work effectively with new technologies.

  • Assurance of quality when outsourcing computer services.


Requirements for Becoming a Microsoft Certified Professional

The certification requirements differ for each certification and are specific to the products and job functions addressed by the certification.

To become a Microsoft Certified Professional, you must pass rigorous certification exams that provide a valid and reliable measure of technical proficiency and expertise. These exams are designed to test your expertise and ability to perform a role or task with a product, and are developed with the input of professionals in the industry. Questions in the exams reflect how Microsoft products are used in actual organizations, giving them “real-world” relevance.

  • Microsoft Certified Product (MCPs) candidates are required to pass one current Microsoft certification exam. Candidates can pass additional Microsoft certification exams to further qualify their skills with other Microsoft products, development tools, or desktop applications.

  • Microsoft Certified Solution Developers (MCSDs) are required to pass three core exams and one elective exam. (MCSD for Microsoft .NET candidates are required to pass four core exams and one elective.)

  • Microsoft Certified Application Developers (MCADs) are required to pass two core exams and one elective exam in an area of specialization.

  • Microsoft Certified Systems Engineers (MCSEs) are required to pass five core exams and two elective exams.

  • Microsoft Certified Systems Administrators (MCSAs) are required to pass three core exams and one elective exam that provide a valid and reliable measure of technical proficiency and expertise.

  • Microsoft Certified Database Administrators (MCDBAs) are required to pass three core exams and one elective exam that provide a valid and reliable measure of technical proficiency and expertise.

  • Microsoft Certified Trainers (MCTs) are required to meet instructional and technical requirements specific to each Microsoft Official Curriculum course they are certified to deliver. The MCT program requires on-going training to meet the requirements for the annual renewal of certification. For more information about becoming a Microsoft Certified Trainer, visit http://www.microsoft.com/traincert/mcp/mct/ or contact a regional service center near you.


Technical Training for Computer Professionals

Technical training is available in a variety of ways, with instructor-led classes, online instruction, or self-paced training available at thousands of locations worldwide.

Self-Paced Training

For motivated learners who are ready for the challenge, self-paced instruction is the most flexible, cost-effective way to increase your knowledge and skills.

A full-line of self-paced print and computer-based training materials is available direct from the source—Microsoft Press. Microsoft Official Curriculum courseware kits from Microsoft Press are designed for advanced computer system professionals and are available from Microsoft Press and the Microsoft Developer Division. Self-paced training kits from Microsoft Press feature print-based instructional materials, along with CD-ROM-based product software, multimedia presentations, lab exercises, and practice files.

Microsoft Certified Technical Education Centers

Microsoft Certified Technical Education Centers (CTECs) are the best source for instructor-led training that can help you prepare to become a Microsoft Certified Professional. The Microsoft CTEC program is a worldwide network of qualified technical training organizations that provide authorized delivery of Microsoft Official Curriculum courses by Microsoft Certified Trainers to computer professionals.

For a listing of CTEC locations in the United States and Canada, visit the Web site at http://www.microsoft.com/traincert/ctec/.


Technical Support

Every effort has been made to ensure the accuracy of this book and the contents of the companion disc. If you have comments, questions, or ideas regarding this book or the companion disc, please send them to Microsoft Press using either of the following methods:

E-mail:

tkinput@microsoft.com

Postal Mail:

Microsoft Press

Attn: MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Editor

One Microsoft Way

Redmond, WA 98052-6399

For additional support information regarding this book and the CD-ROM (including answers to commonly asked questions about installation and use), visit the Microsoft Press Technical Support Web site at http://www.microsoft.com/mspress/support/. To connect directly to the Microsoft Press Knowledge Base and enter a query, visit http://www.microsoft.com/mspress/support/search.asp. For support information regarding Microsoft software, please connect to http://support.microsoft.com/.


Chapter 1: Introduction to Designing Business Solutions

Chapter 1
Introduction to Designing Business Solutions
About This Chapter

In this introduction to designing business solutions, you will learn about Microsoft® Solutions Framework (MSF), a set of models, principles, and guidelines for designing applications. You will learn about the MSF Process Model and its various phases. You will also learn about the key activities that you perform in designing an application, and about the deliverables associated with those activities. In addition, you will be introduced to the case study that illustrates the concepts and practices that you will learn.

Before You Begin

To complete the lessons in this chapter, you must have

  • A general understanding of the software development life cycle.

  • General knowledge of Microsoft technologies.


Lesson 1: Overview of Microsoft Solutions Framework

MSF provides a set of models, principles, and guidelines for designing and developing enterprise solutions in a way that ensures that all elements of a project, such as people, processes, and tools, can be successfully managed. MSF also provides proven practices for planning, designing, developing, and deploying successful enterprise solutions. In this lesson, you will learn about the process model and team model that MSF provides.

After this lesson, you will be able to

  • Describe the phases in the MSF Process Model.

  • Describe the roles in the MSF Team Model.

  • Describe the MSF disciplines: risk management, readiness management, and project management.

  • Describe how managing tradeoffs helps to ensure the success of an enterprise project.

  • Describe the purpose of iteration in an enterprise project.

  • Describe the waterfall model and the spiral model.

Estimated lesson time: 15 minutes
What Are Process Models?

To maximize the success of enterprise projects, Microsoft has made available packaged guidance for effectively designing, developing, deploying, operating, and supporting solutions, including those created with Microsoft technologies. This knowledge is derived from the experience gained within Microsoft and from customers and vendors about large-scale software development and service operation projects, the experience of Microsoft’s consultants in conducting projects for enterprise customers, and the best knowledge from the worldwide Information Technology (IT) industry.

A process model guides the order of project activities and represents the life cycle of a project. Historically, some process models are static and others do not allow checkpoints. Two such process models are the waterfall model and the spiral model.

Waterfall and spiral models

Figure 1.1 shows the waterfall model’s cascading checkpoints and the spiral model’s circular approach to process.

Figure 1-1 The waterfall model and the spiral model
Figure 1-1. The waterfall model and the spiral model

These models provide two different approaches to the project life cycle. The preceding illustration shows the waterfall model’s cascading checkpoints and the spiral model’s circular approach to process.

  • Waterfall model. This model uses milestones as transition and assessment points. When using the waterfall model, you need to complete each set of tasks in one phase before moving on to the next phase. The waterfall model works best for projects in which the project requirements can be clearly defined and are not liable to modifications in the future. Because this model has fixed transition points between phases, you can easily monitor schedules and assign clear responsibilities and accountability.

  • Spiral model. This model is based on the continual need to refine the requirements and estimates for a project. The spiral model is effective when used for rapid application development of very small projects. This approach can generate great synergy between the development team and the customer because the customer is involved in all stages by providing feedback and approval. However, the spiral model does not incorporate clear checkpoints. Consequently, the development process might become chaotic.

How the MSF Process Model Works

The MSF Process Model describes a generalized sequence of activities for building and deploying enterprise solutions. This process is flexible and can accommodate the design and development of a broad range of enterprise projects. The MSF Process Model is a phase-based, milestone-driven, and iterative model that can be applied to developing and deploying traditional applications, enterprise solutions for e-commerce, and Web-distributed applications.

MSF Process Model

The MSF Process Model combines the best principles of the waterfall and spiral models. It combines the waterfall model’s milestone-based planning and resulting predictability with the spiral model’s benefits of feedback and creativity.

Figure 1.2 shows the MSF Process Model.

Figure 1-2 The MSF Process Model
Figure 1-2. The MSF Process Model
Phases of the MSF Process Model

The MSF Process Model consists of five distinct phases:

  • Envisioning

  • Planning

  • Developing

  • Stabilizing

  • Deploying

Each phase culminates in a milestone. Figure 1.3 illustrates the phases and milestones of the MSF Process Model. You will learn about these phases in detail in Lesson 2.

Figure 1-3 Phases and milestones of the MSF Process Model
Figure 1-3. Phases and milestones of the MSF Process Model
How to Organize Project Teams

Along with the MSF Process Model, MSF provides the MSF Team Model for organizing project teams. The MSF Team Model emphasizes the importance of clear roles, responsibilities, and goals of individual members to the success of the project. This model also increases the accountability of each team member. The flexibility of the MSF Team Model helps you to adapt it to the scope of the project, the size of the team, and the skills of the team members. This model forms the basis of creating effective, resilient, and successful project teams.

Roles in the MSF Team Model

In an enterprise solution project, a large number of activities must be performed, and the project must be viewed from several perspectives. To accommodate these needs, the MSF Team Model specifies six distinct roles, and each role has clearly defined responsibilities and goals.

IMPORTANT
The team works toward a single vision, and team members operate as peers. Within the team, each role contributes to and is equally responsible for the success of the project.

The roles in the MSF Team Model are as follows:

  • Product management. Responsible for managing customer communications and expectations. During the design phase, product management gathers customer requirements and ensures that business needs are met. Product management also works on project communication plans such as briefings to the customers, marketing to users, demonstrations, and product launches.

  • Program management. Responsible for the development process and for delivering the solution to the customer within the project constraints.

  • Development. Responsible for developing the technology solution according to the specifications provided by the program management role.

  • Testing. Responsible for identifying and addressing all product quality issues and approving the solution for release. This role evaluates and validates design functionality and consistency with project vision and scope.

  • Release management. Responsible for smooth deployment and operations of the solution. Release management validates the infrastructure implications of the solution to ensure that it can be deployed and supported.

  • User experience. Analyzes performance needs and support issues of the users and considers the product implications of meeting those needs.

In a small project, individuals on the project team can take on more than one role. Note that combining roles on a project introduces risk to the project. Therefore, it is important to assign appropriate roles to the members. For example, it is not recommended that an individual be assigned to both the program management role and the development role.

To help minimize risks, use Table 1.1 as a guide in determining which roles can be combined and which ones should not be combined.

Table 1-1. Combining Roles Within a Team
Role | Product management | Program management | Development | Testing | User experience | Release management
Product management |  | N | N | P | P | U
Program management | N |  | N | U | U | P
Development | N | N |  | N | N | N
Test | P | U | N |  | P | P
User experience | P | U | N | P |  | U
Release management | U | P | N | P | U |
Legend: P: Possible U: Unlikely N: Not recommended |  |  |  |  |  |
Additional team members

In addition to the roles defined previously, the project team also includes the project stakeholders, though they are not part of the MSF Team Model. These stakeholders include the following roles:

  • Project sponsor. One or more individuals initiating and approving the project and its result.

  • Customer (or business sponsor). One or more individuals who expect to gain business value from the solution.

  • End user. One or more individuals or systems that interact directly with the solution.

  • Operations. The organization responsible for the ongoing operation of the solution after delivery.

MSF Disciplines

MSF guidance includes disciplines for managing the people, processes, and technology elements that most projects encounter. The three key MSF disciplines are risk management, readiness management, and project management.

MSF risk management process

The MSF risk management discipline advocates proactive risk management, continuous risk assessment, and decision making throughout the project life cycle. The team continuously assesses, monitors, and actively manages risks until they are either resolved or turn into problems to be handled as such.

The MSF risk management process defines six logical steps through which the team manages current risks, plans and executes risk management strategies, and documents knowledge for the enterprise.

  1. Risk identification allows individuals to identify risks so that the team becomes aware of any potential problems.

  2. Risk analysis transforms the estimates or data about specific project risks that emerges during risk identification into a form the team can use to make decisions about prioritization.

  3. Risk planning uses the information obtained from risk analysis to formulate strategies, plans, and actions.

  4. Risk tracking monitors the status of specific risks and documents the progress in their respective action plans.

  5. Risk control is the process of executing risk action plans and their associated status reporting.

  6. Risk learning formalizes the lessons learned and relevant project documents and tools, and records that knowledge in reusable form for use within the team and by the enterprise.

More Info
You will learn more about MSF risk management in Chapter 3, “Envisioning the Solution.”
MSF readiness management process

The MSF readiness management discipline includes a process to help you develop the knowledge, skills, and abilities (KSAs) needed to create and manage projects and solutions. Figure 1.4 illustrates the four steps of the readiness management process: define, assess, change, and evaluate.

Figure 1-4 MSF readiness management
Figure 1-4. MSF readiness management

Each step of the process includes a series of tasks to help reach the next milestone.

  • Define. During this step, the team identifies the scenarios, competencies, and proficiency levels needed to successfully plan, create, and manage the solution. This is also the time to determine which competencies and corresponding proficiency levels are required for each role in the organization. The assigned role determines whether an individual needs to be proficient in one or many of the defined competencies.

  • Assess. It is during this step that the team begins analysis of the current competencies as they relate to the various job roles. The purpose of this analysis is to determine the skills of individuals within each of these roles. The team then compares the competencies identified in the previous step to the current competencies. Comparing current skill levels to required skill levels is necessary to develop a learning plan, so that team members can reach the necessary competency levels.

  • Change. During this step, team members begin to improve their skills by means of structured learning to raise current proficiency levels to the desired levels. This step consists of:

    • Training. The learning and mentoring that occurs according to what was outlined in the learning plan.

    • Tracking progress. The tracking of progress that enables individual or overall readiness to be determined at any time during the life cycle. This tracking enables the team members to make necessary adjustments to the learning plan.

  • Evaluate. During this step, the team determines whether the learning plans were effective and whether the lessons learned are being successfully implemented on the job.

The MSF readiness management process is an ongoing, iterative approach to readiness. The process is adaptable for both large and small projects. Following the steps in the process helps manage the various tasks required to align individual, project team, and organizational KSAs.

MSF project management process

To deliver a solution within project constraints, strong project management skills are essential. Project management is a process that combines a set of skills and techniques to address the following tasks:

  • Integrate planning and conduct change control

  • Define and manage the scope of the project

  • Prepare a budget and manage costs

  • Prepare and track schedules

  • Ensure that the right resources are allocated to the project

  • Manage contracts and vendors and procure project resources

  • Facilitate team and external communications

  • Facilitate the risk management process

  • Document and monitor the team’s quality management process

The MSF Team Model does not contain a project manager role; however, most project management functions are conducted by the MSF program management role.

The differentiating factor of the MSF approach to project management is that the project management job function and activities do not form a hierarchical structure in the decision-making process. MSF advocates against a rigid, dictatorial style of project management. This rigid style hinders the development of an effective team of peers, which is a key success factor of MSF.

In MSF, all team roles fulfill a specific goal, all of which are considered equally important. Major decisions are made by consensus of the core team. If that consensus cannot be achieved, the program management role makes the final decision on the issue by transitioning into the role of decision leader to enable the project to continue. Program management makes the decision with the goal of meeting the customer’s requirements and delivering the solution within the constraints. After the decision is made, the team returns to operating as a team of peers.

How to Manage Tradeoffs

Projects frequently fail, are completed late, or exceed the planned budget. Ambiguous project scope can contribute to or be the cause of each of these problems. The scope of a project specifies what the solution will and will not do. To effectively define and manage the scope, you need to:

  • Identify project constraints

  • Manage tradeoffs

  • Establish change control

  • Monitor project progress

In the process of identifying and managing tradeoffs, you are not necessarily reducing the features of a solution, but identifying tradeoffs might result in a reduction of features. Managing tradeoffs provides a structured way to balance all parts of the project while realizing that you cannot attain all of your goals at the same time. Both the team and the customer must review the tradeoffs and be prepared to make difficult choices.

The tradeoff triangle and the project tradeoff matrix are two of the tools that MSF uses for managing tradeoffs.

Tradeoff triangle

In projects, there is a clear relationship between such project variables as resources, schedule, and features of the project. The relationship between these variables is illustrated in Figure 1.5.

Figure 1-5 The tradeoff triangle
Figure 1-5. The tradeoff triangle

As illustrated by the triangle, any change to any one of the components implies that a corresponding change might need to be made to the other components. The key to developing a solution that meets the customer requirements is to determine and maintain the correct balance between resources, deployment date, and features.

Often, project teams are reluctant to reduce the number of features in the solution. The tradeoff triangle helps to explain the constraints and present the options for tradeoffs.

NOTE
If you add quality as a fourth dimension to the tradeoff triangle, the triangle transforms into a tetrahedron. By reducing the quality requirements, you could simultaneously reduce resources, shorten the schedule, and increase the number of features, but this strategy is the worst approach for developing a solution.
Project tradeoff matrix

The project tradeoff matrix is a tool that the team and the customer can use when making tradeoff decisions. These decisions are made early in the project.

Figure 1.6 is an example of a project tradeoff matrix.

Figure 1-6 A project tradeoff matrix
Figure 1-6. A project tradeoff matrix

The tradeoff matrix helps identify the project features that are considered essential, the features that are not essential but that would be good to include, and the features that can be eliminated or added to the next version to accommodate the other two variables. To understand how the tradeoff matrix works, the variables of resources, schedule, and features can be inserted into the blanks of the following sentence:

Given fixed ____________, we will choose a ___________ and adjust ___________ if necessary.

The following are the various logical possibilities:

  • Given fixed resources, we will choose a schedule and adjust the feature set if necessary.

  • Given fixed resources, we will choose a feature set and adjust the schedule if necessary.

  • Given a fixed feature set, we will choose appropriate resources and adjust the schedule if necessary.

  • Given a fixed feature set, we will choose a schedule and adjust resources if necessary.

  • Given a fixed schedule, we will choose appropriate resources and adjust features if necessary.

  • Given a fixed schedule, we will choose a feature set and adjust resources if necessary.

IMPORTANT
For the tradeoff process to work effectively, both the team and the customer must agree to and formally approve the tradeoff matrix for the project. This approval process is also referred to as signing off.
How to Use Iteration in Projects

While development of the solution continues through its phases, each iteration of the process brings the solution closer to its final release. Iterations are continued within a specific phase until the goal for the phase has been reached. In addition, an iteration allows the project to be developed in smaller steps, with future iterations being based on the success or failure of an earlier step. Deliverables such as the vision/scope document and other documents, code, designs, and plans are developed in an iterative manner. Instances of iteration in a project life cycle include:

  • Creating versioned releases

  • Creating living documents

  • Creating periodic builds (weekly or daily)

Versioned releases

When using MSF, a team develops solutions by building, testing, and deploying a core of functionality, and then adding sets of features to the solution in every release. This is known as a version release strategy.

Figure 1.7 illustrates how functionality develops during the creation of many versions of a solution. The time between versions depends on the size and scope of the project.

Figure 1-7 Functionality of versioned releases
Figure 1-7. Functionality of versioned releases

Versioned releases improve the team’s relationship with the customer and ensure that the best ideas are reflected in the solution. Customers will be more receptive to deferring features until a later release if they trust the team to deliver the initial and subsequent solution releases on time. Several guidelines facilitate the adoption of versioned releases:

  • Create a multiple version release plan. Thinking beyond the current version enhances a team’s ability to make good decisions about what to create now and what to defer. This allows the team to make the best use of the available resources and schedule. In addition, you can prevent unwanted expansion of scope by providing a timetable for future feature development.

  • Work through iterations rapidly. A significant benefit of versioning is that it delivers usable solutions to the customer quickly and improves them incrementally over time. Maintain a manageable scope so that iterations are achievable within acceptable time frames.

  • Deliver core functionality first. Delivering a basic solution that is solid and usable is more effective than developing a solution that the customer cannot use for weeks or months. Delivering core functionality first enables developers to incorporate customer feedback that will motivate feature development in subsequent iterations.

  • Create high-risk features first. During risk assessment, the team identifies the riskiest features. Schedule these features for proof-of-concept testing first. If you encounter any problems that require major changes to the architecture, you can implement the changes earlier in the project and minimize the impact to schedule and budget.

Living documents

To ensure that you do not spend too much time refining the early phases of the project, you need to create living documents—that is, documentation that changes as the project changes. Living documents allow teams to make modifications to any aspect of the project design and development when there is a change in requirements. This process ensures that the completed solution meets the final requirements and not just the initial set of requirements. MSF project documents are developed iteratively.

For example, the MSF Process Model recommends that planning documents start out as generalized documents without extensive details. They are submitted for review by the team and stakeholders during the initial stages of the project. As the solution progresses through different phases, the documents are developed into detailed plans. These plans are once again reviewed and modified iteratively. The type and number of these plans depends on the size of the project.

Daily builds

MSF recommends the preparation of frequent builds of the components of a solution for testing and review. This approach applies to developing code in addition to builds of hardware and software components. By creating daily builds, you can ensure that you understand the stability of the total solution and have accumulated ample test data before releasing the solution.

Using the daily build approach is particularly effective for larger, complex projects that are divided into smaller subsystems. Separate teams develop and test these subsystems and then consolidate them into a single solution. Developers complete core functionality of the solution or product first, and add additional features later. Development and testing occur continuously and simultaneously. Creating daily builds ensures that all code is compatible and allows the various subteams to continue their development and testing iterations.


Lesson 2: Phases in the MSF Process Model

As stated in Lesson 1, the MSF Process Model is milestone based and consists of five phases: envisioning, planning, developing, stabilizing, and deploying. During each phase, the project team performs a distinct set of activities. In this lesson, you will learn about the various phases in detail. You will also learn about the milestones and deliverables of each phase.

After this lesson, you will be able to

  • Describe the tasks, milestones, and deliverables of the envisioning, planning, developing, stabilizing, and deploying phases of the MSF Process Model.

Estimated lesson time: 30 minutes
What Is the Envisioning Phase?

The MSF process begins with the envisioning phase. Envisioning can be defined as creating a broad description of the goals and constraints of the project. In this phase, you identify the team and what the team must accomplish for the customer. The purpose of the envisioning phase is to build a shared vision of the project among all the key stakeholders of the project.

During the envisioning phase, the program management team identifies the tasks and deliverables that address the requirements and goals of the project. This phase culminates in a vision/scope approved milestone. This milestone indicates that the customer and the team agree about the purpose and direction of the project.

Envisioning process

The team performs the following key tasks during the envisioning phase:

  • Setting up the team. Creation of a project team that represents all roles of the MSF Team Model. (The person who creates this team is usually identified by senior management.) When setting up a team, it is important to consider the skills, experience, and performance level of the team members. In addition, there are practical considerations such as availability of resources and project budget.

  • Defining the project structure. Identification of an administrative structure for the project team and the standards for managing the project.

  • Defining the business goals. Analysis of the business problem and opportunities in order to identify the objectives for the solution.

  • Assessing the current situation. Evaluation of the current situation and analysis of the difference between the current and expected situation. The purpose of this evaluation is to create the problem statement and identify the direction of the project.

  • Creating a vision statement and defining the scope of the project. Creation of a vision statement that communicates the long-term direction for guiding the team toward its business goals. Identification of the scope of the project defines what will and will not be included in the solution.

    NOTE
    A shared and clearly articulated vision is fundamental to the success of the project.

  • Defining requirements and user profiles. Identification of the stakeholders, end users, and sponsors for the project and documentation of their requirements for the solution. This information helps to evaluate the vision/scope of the project and to create a solution concept.

  • Developing a solution concept. Creation of a baseline solution concept, that is, the outlining of the approach that the team will take to create the solution. This concept is created by using the requirements that have been identified.

  • Assessing risk. Identification and assessment of the risks to the project, and creation of a risk mitigation plan. This is an iterative step that is conducted during all stages of the product life cycle.

  • Closing the envisioning phase. End of the envisioning phase. Accomplished when the vision/scope document is formally approved by all stakeholders and the project team.

Milestones of the envisioning phase

Each phase in the MSF Process Model has interim milestones and a major milestone. Interim milestones are associated with the various activities that are performed in a phase, such as creating a team and creating a vision/scope document. The major milestone indicates that the team can progress to the next phase in the MSF Process Model. For example, the major milestone of the envisioning phase is the vision/scope approved milestone. When the team reaches this milestone, the team can progress to the planning phase of the MSF Process Model.

The interim milestones of the envisioning phase are as follows:

  • Core team organized. The key members of the team have been identified. The team might not be completely assembled at this time. A project structure document specifies the roles and responsibilities of each member of the team. This document also outlines the hierarchy of accountability in the team, the points of contact with the customer, and the structure of the team.

  • Vision/scope created. The first version of the vision/scope document is completed and is distributed among the team, customers, and stakeholders for review. During the review cycle, the document undergoes iterations of feedback, discussions, and corresponding modifications.

The envisioning phase culminates with the vision/scope approved milestone. At this stage, the project team and the customer have agreed on the direction for the project, the scope of the solution, and a general timetable for delivering the solution.

Deliverables of the envisioning phase

The team creates deliverables for each task in the envisioning phase. Together, these deliverables provide context and direction for the team for the remainder of the project, and communicate the project vision and scope to the customer. The deliverables that the team creates during the envisioning phase include:

  • Vision/scope

    • Problem statements and business objectives

    • A review of the existing processes

    • A broad definition of user requirements

    • User profiles identifying who will benefit from the solution

    • A vision statement and scope definition

    • The solution concept outlining the approach the team will take to plan the project

    • Solution design strategies

  • Project structure

    • A description of all MSF team roles and a list of corresponding team members

    • A project structure and process standards for the team to follow

  • Risk assessment

    • A preliminary risk assessment

    • A list of the primary identified risks

    • Plans for mitigating or eliminating the identified risks

What Is the Planning Phase?

During the planning phase, the team determines what to develop and plans how to create the solution. The team prepares the functional specification, creates a design of the solution, and prepares work plans, cost estimates, and schedules for the various deliverables.

The planning phase involves the analysis of requirements. These requirements can be categorized as business requirements, user requirements, operational requirements, and system requirements. These requirements are used to design the solution and its features and to validate the correctness of the design.

After gathering and analyzing the requirements, the team creates the design of the solution. The team creates user profiles that specify the various users of the solution and their roles and responsibilities. The team then creates a series of usage scenarios. A usage scenario specifies the activity performed by a particular type of user. Therefore, the team needs to create usage scenarios for all user profiles. After creating usage scenarios, the team creates use cases for the usage scenarios. A use case specifies the sequence of steps that a user will perform in a usage scenario.

Design stages

The three design stages are:

  • Conceptual design, in which you view the problem from the perspective of the users and business requirements and define the problem and solution in terms of usage scenarios.

  • Logical design, in which you view the solution from the perspective of the project team and define the solution as a set of services.

  • Physical design, in which you view the solution from the perspective of the developers and define the technologies, component interfaces, and services of the solution.

You document the solution design in the functional specification. The functional specification describes the behavior and appearance of each feature of the solution. It also describes the architecture and the design for all features.

Design process

The team performs the following key tasks during the planning phase:

  • Developing the solution design and architecture. Identification of business requirements, user requirements, and technologies and the use of this information to design a proposed application model.

  • Creating the functional specification. Creation of a functional specification that describes the requirements that must be met by the solution.

  • Developing project plans. Identification of and planning for the tasks that will be performed by the project team, and the consolidation of these plans into a master project plan. The master project plan also includes items such as the approach, dependencies, and assumptions for the solution.

  • Creating project schedules. Creation of the master project schedule. This schedule consists of milestone-based schedules for each of the team roles in the project team.

  • Creating the development, testing, and staging environments. Creation of a separate environment in which to develop and test the solution. This environment is independent of the environment in which the solution will finally be deployed.

  • Closing the planning phase. Completion of the milestone approval process. Documentation of the results of completing the tasks performed during the planning phase.

Milestones of the planning phase

During the planning phase, the team performs multiple tasks. The interim milestones of the planning phase are as follows:

  • Technology validation complete. During technology validation, the team evaluates the products and technologies that will be used to create or deploy the solution. The team also audits the customer’s current production environment. This includes server configurations, network, desktop software, and all relevant hardware.

  • Functional specification complete. At this milestone, the functional specification is completed and submitted for review to the customers and stakeholders. Remember that the design document is different from the functional specification. The design document is written for the project team and describes the internal workings of the solution.

  • Master plan complete. The master plan is a combination of the plans of various roles on the team. Its length and complexity depends on the size of the project.

  • Master project schedule complete. The master project schedule includes all detailed project schedules and the solution release date. Like the master project plan, the master project schedule combines and integrates information from each of the roles on the team, in this case scheduling information.

  • Development and test environments set up. A working environment allows proper development and testing of the solution and avoids any negative impact on systems to which the solution will eventually be deployed. This is also the environment in which the infrastructure components, such as server configurations, deployment automation tools, and hardware, are identified and configured.

The major milestone of the planning phase is the project plan approved milestone. At this milestone, the project team and key project stakeholders agree that interim milestones have been met, that due dates are realistic, that project roles and responsibilities are well defined, that everyone agrees to the deliverables for the project, and that mechanisms are in place for addressing areas of project risk.

Deliverables of the planning phase

The planning phase deliverables provide the basis for making future tradeoff decisions. The following deliverables are produced during the planning phase:

  • Functional specification

  • Risk management plan

  • Master project plan and master project schedule

What Is the Developing Phase?

During the developing phase, the project team creates the solution. This process includes creating the code that implements the solution and documenting the code. In addition to developing code, the team also develops the infrastructure for the solution.

Development process

The team performs the following key tasks during the developing phase:

  • Starting the development cycle. Verification that all tasks identified during the envisioning and planning phases have been completed so that the team can begin developing the solution.

  • Creating a prototype application. Verification of the concepts of the solution design in an environment that resembles the environment to which the solution will be eventually deployed. This environment is as similar as possible to the production environment. This task is completed before development begins.

  • Developing the solution components. Development of the solution’s core components and the extension of these components to the specific needs of the solution.

  • Building the solution. A series of daily or frequent builds that culminate with major internal builds that signify points when the development team is delivering key features of the solution.

  • Closing the developing phase. Completion of all features, and delivery of code and documentation. The solution is considered complete, and the team enters a milestone approval process.

Milestones of the developing phase

During the developing phase, the team creates a proof-of-concept application and then creates the solution. The interim milestones of the developing phase are as follows:

  • Proof-of-concept application complete. The proof-of-concept application tests key elements of the solution in a test environment. The team leads the operations team and users through the solution to validate their requirements.

  • Internal builds complete. Because a solution is developed in segments, it is a good practice to synchronize the solution segments at product level. You do this with the help of internal builds. The number and frequency of internal builds depends on the size and complexity of the project.

The developing phase culminates in the scope complete milestone. At this milestone, all features are complete and have gone through unit testing. The product is now ready for external testing and stabilization. Additionally, customers, users, operations and support personnel, and key project stakeholders can evaluate the product and identify any issues that must be addressed before the solution is shipped.

Deliverables of the developing phase

The deliverables of the developing phase include:

  • Source code and executable files

  • Installation scripts and configuration settings for deployment

  • Finalized functional specification

  • Performance support elements

  • Test specifications and test cases

What Is the Stabilizing Phase?

During the stabilizing phase, the team performs integration, load, and beta testing on the solution. In addition, the team tests the deployment scenarios for the solution. The team focuses on identifying, prioritizing, and resolving issues so that the solution can be prepared for release. During this phase, the solution progresses from the state of all features being complete as defined in the functional specification for this version to the state of meeting the defined quality levels. In addition, the solution is ready for deployment to the business.

Stabilization process

The team performs the following key tasks during the stabilizing phase:

  • Testing the solution. Implementation of test plans to validate the solution. Once the solution is considered stable, a pilot is conducted in a test environment. A rigorous test includes:

    • Component testing

    • Database testing

    • Infrastructure testing

    • Security testing

    • Integration testing

    • User acceptance and usability testing

    • Stress, capacity, and performance testing

    • Regression testing

    • Recording the number of bugs

  • Conducting the pilot. Deployment of the solution in a staging area and testing of the solution with actual users and real usage scenarios.

Test tracking and reporting

Test tracking and reporting occurs at frequent intervals during the developing, testing, and stabilizing phases. During the stabilizing phase, reporting is dependent upon the issue and bug count. Regular communication of test status to the team and other key stakeholders ensures a well-informed team.

Milestones of the stabilizing phase

The interim milestones of the stabilizing phase are as follows:

  • Bug convergence. A milestone of the stabilizing phase that marks the point at which the team makes measurable progress against the active issue and bug count. At bug convergence, the rate of bugs resolved exceeds the rate of bugs found. Because the bug rate will still rise and fall—even after it starts its overall decline—bug convergence usually manifests itself as a trend rather than a fixed point in time.

    After bug convergence, the number of bugs should continue to decrease until zero-bug release. Bug convergence informs the team that the end of the project is near.

  • Zero-bug release. A milestone of the stabilizing phase that marks the point at which the issue and bug count has met the zero-defect metric for this point in the project.

  • Release candidates. A series of milestones of the stabilizing phase that reflect incremental improvements in the reduction of the issue and bug count as compared to that of the zero-bug release milestone.

  • Golden release. A milestone of the stabilizing phase that is identified by the combination of zero-defect and success criteria metrics.

The stabilizing phase culminates in the release readiness milestone. After the solution has been reviewed and approved, it is ready for full deployment in the production environment. The release readiness milestone occurs when the team has addressed all issues and has shipped the product. At the release readiness milestone, the responsibility for managing and supporting the solution is officially transferred from the project team to the operations and support teams.

Deliverables of the stabilizing phase

The deliverables of the stabilizing phase are as follows:

  • Final release

  • Release notes

  • Performance support elements

  • Test results and testing tools

  • Source code and executable files

  • Project documents

  • Milestone review

What Is the Deploying Phase?

During this phase, the team deploys the solution technology and site components, stabilizes the deployment, transfers the project to operations and support, and obtains final customer approval of the project. After deployment, the team conducts a project review and a customer satisfaction survey. The deploying phase culminates in the deployment complete milestone.

Deployment process

The team performs the following key tasks during the deploying phase:

  • Completion of deployment and operations procedures. Formal documentation of deployment and operational procedures to outline how the project team intends to perform deployment and transition tasks.

  • Deployment and stabilization. Completion of the actual component and site deployments.

  • Project review. Completion of post-project reviews with the customer and project team.

NOTE
Stabilizing activities might continue during this phase because the project components are transferred from a test environment to a production environment.
Milestones of the deploying phase

The interim milestones of the deploying phase are as follows:

  • Core components deployed. Most infrastructure solutions include a number of components that provide the underlying structure for the entire solution. Though these components do not represent the solution from the perspective of the customer, successful deployment of sites depends on these components. Depending on the solution, the core technology might need to be deployed before or simultaneously with site deployments. To avoid delays, core components must be reviewed and approved for deployment while other parts of the solution are still being stabilized.

  • Site deployments complete. At the completion of this milestone, all intended users must be able to access the solution. Lead developers for each site must confirm that their sites are operating. This milestone might not be applicable for projects that do not include client-side deployments.

  • Deployment stable. At this milestone, the customer and team agree that the sites are operating satisfactorily. Some issues might arise with the various site deployments. These issues can be tracked and resolved.

    NOTE
    The customer might agree that the team has met its objectives before it can declare the solution to be in production and close the project. Making this agreement requires a stable solution and clearly stated success criteria. For the solution to be considered stable, appropriate operations and support systems must be implemented.

    The period between the deployment stable milestone and the deployment complete milestone is sometimes referred to as a quiet period. Although the team is no longer active, team resources will respond to issues that are presented to them. Typical quiet periods last between 15 and 30 days. During this period, the team measures the effectiveness and performance of the solution and can estimate the maintenance effort required for continuing operations. The team can also work on the next release of the solution during this time.

  • Deployment complete. This milestone is the culmination of the deploying phase. By this time, the deployed solution should be providing the expected business value to the customer.

    It can be difficult to determine when a deployment is complete. Newly deployed systems often go through a continuous process of identifying and managing production support issues. The team can have a difficult time closing the project because of the ongoing issues that arise after deployment. Therefore, the team needs to clearly define a completion milestone for the deployment rather than attempting to reach a point of absolute finality.

Deliverables of the deploying phase

The deliverables of the deploying phase are as follows:

  • Operation and support information systems

    • Procedures and processes

    • Knowledge base, reports, and logbooks

  • Documentation repository for all versions of documents and code developed during the project

  • A training plan

  • Project completion report

    • Final versions of all project documents

    • Customer satisfaction data

    • Definition of next steps


Lesson 3: Introducing the Case Study?Adventure Works Cycles Application

Lesson 3: Introducing the Case Study—Adventure Works Cycles Application

This lesson introduces the scenario that is used to illustrate the concepts and procedures for designing applications that are based on the Microsoft .NET Framework. This scenario will be used in many of the forthcoming lessons.

After this lesson, you will be able to

  • Recognize the basic business requirements of the case study application.

Estimated lesson time: 10 minutes
The Adventure Works Cycles Case Scenario

The purpose of this case study is to enable you, the application architect, to understand the nature of business problems that you will need to solve. Adventure Works Cycles, a large, multinational manufacturing company, produces and distributes metal and composite bicycles to North American, European, and Asian commercial markets. While its base operation is located in Bothell, Washington, and employs 500 people, several regional sales teams are located throughout the company’s market region.

In 2000, Adventure Works Cycles bought a small manufacturing plant, Wide World Importers, which is located in Mexico City, Mexico. Wide World Importers manufactures several critical subcomponents for the Adventure Works Cycles product line. These subcomponents are shipped to the Bothell location for final product assembly. In 2001, Wide World Importers became the sole manufacturer and distributor of the touring bicycle product group.

After a successful fiscal year, Adventure Works Cycles is looking to broaden its market share by focusing its sales efforts on the company’s best customers, extending product availability through an external Web site, and reducing the cost of sales by reducing production costs.

What Are the Business Problems?

The business problems can be categorized according to the various departments—Sales, Human Resources (HR), Wide World Importers Acquisition, Purchasing, Information Systems, Production, System Administration, and Engineering.

Business problems in the Sales department

Sales representatives from regional sales offices have assigned sales territories in the United States, Canada, England, Australia, Germany, and France. Each regional office consists of several sales representatives and a team manager. In their daily sales activities, sales representatives use both laptops and Handheld PCs that run Microsoft® Windows CE.

A typical work day for a sales representative starts with the representative dialing in to the regional office and downloading current data such as inventory, product, and promotional information. During customer visits, the sales representative takes orders on the laptop or Handheld PC. At the end of each day, the sales representative sets up appointments for the following day or week, checks the appointments of other representatives in the area for possible collaboration, and updates the contact list. The sales representative dials back in to the regional office, sends updated information, and receives any new internal communications from the base office or regional office. The company currently uses Microsoft Outlook® for e-mail.

The sales teams have identified the following requirements that will enable them to perform their jobs better:

  • Customer segmentation and profiling. The sales team needs to be able to extract valuable information from raw data available in the databases to answer questions such as the following:

    • What are the early warning signs of problems?

    • Who are the best customers across all product lines? With whom should the sales team focus its efforts for building long-term relationships?

    • What are customers’ issues, categorized according to demographic groups (geographic location, revenue history, and so on)?

    • What products are the customers buying and at what rate?

  • Sales activity.

    • The current discount policy allows sales representatives the discretion to discount a particular order up to 15 percent. Sales managers can increase their own discounts or customer discounts up to 20 percent. The product should allow employees to provide appropriate discounts to customers, depending on the employee’s role.

    • To support sales activity throughout the world, the sales team needs international support, including the ability to have product information, especially dates and pricing, available in multiple languages and currency types.

  • Internal communication. Each sales representative must receive customer and sales data pertinent only to that representative. Each team manager must receive relevant customer and appointment data along with detailed information for each sales representative on that manager’s team. A manager must be able to assign customers to sales representatives based on their relationships with the customers, though usually customers are assigned by region.

  • Opportunity management. Sales representatives need a method to store and access sales opportunity data and, when a sale is generated, to convert some or all of the information into a sales order without reentering information.

  • Decision support system. The decision support system should provide the following features:

    • Allow marketing/sales staff to query and use customer data to generate standard reports; execute custom queries; obtain information related to promotion tracking, sales forecasting, and customer segmentation; and access third-party data sources and financial evaluation tools.

    • Present all customer activity in a unified way, including multiple contacts, conversations, and transactions.

    • Allow marketing personnel to initiate new promotions and programs on a multinational basis. Currently, sales representatives do not know how to associate these programs with specific areas for the best impact.

    • Identify, analyze, and share all aspects of customer relationships with individuals throughout multiple departments.

Business problems in the HR department

The current retention rate of Adventure Works Cycles employees is 90 percent for hourly employees and 75 percent for salaried employees. Management predicts that they will need to hire 35 percent more workers during the next fiscal year to replace departing employees and meet the projected increase in production. In addition, the acquisition of Wide World Importers has significantly increased the department’s hiring and employee retention tasks because of the increase in employees and job candidates.

Management has determined that they need a solution to track both employee reviews and the resumes of prospective employees. In addition, they want to improve their ability to forecast the number of employees needed and to plan for changes in work compensation and benefits. The HR department requires the following features from the solution:

  • Resume and review management. All resumes and reviews are stored in documents of different formats. A system is needed to provide:

    • Unified storage for all file types

    • Access to existing employee data (relational database tables) with links to reviews or resumes

    • Tools for converting all files types to documents that can be shared internally across departments

    • Ability to secure some areas of documents, such as salary information, from designated users

    • Ability to search resumes or reviews for keywords or phrases

  • Analysis and planning. The HR department needs support for performing the following types of analysis:

    • Compensation and benefits analysis, including impact of international currency exchange rates

    • Planning to assess the required workforce

    • Payroll cost simulations and forecasting

Business problems in the Wide World Importers Acquisition department

Wide World Importers is located in Mexico City, Mexico. They manufacture several critical components used in the Adventure Works Cycles product line. Adventure Works Cycles recently purchased Wide World Importers in an effort to expand its infrastructure to support the expected growth of the company. Wide World Importers is considered a separate business unit from Adventure Works Cycles; however, it is imperative that some applications and data be shared between the two companies. The business problems associated with this department are as follows:

  • Data transfer. Adventure Works Cycles cannot migrate and transfer data regularly because:

    • Wide World Importers does not have a high-speed data transfer utility for moving data from their local database to the three Microsoft SQL Server™ databases in Bothell.

    • Adventure Works Cycles has a centralized environment; it needs to enhance the scalability of its production database by transitioning to a distributed environment.

    • The data is currently not being transferred by means of a secure network connection.

  • Administration and support. Wide World Importers has limited Information Systems (IS) support. Departments maintain their own workstations and the servers that support the Oracle database are monitored and maintained by two administrators and the IS manager. The company lacks many of the standardized processes used by Adventure Works Cycles in its daily operations management.

Business problems in the Purchasing department

Adventure Works Cycles currently uses several vendors to supply various components and raw materials for its product line. The Purchasing department has identified a major supplier who is interested in establishing an Electronic Data Interchange (EDI) with Adventure Works Cycles to transmit critical data and documents such as purchase orders, invoices, payments, and product specifications. Purchasing agents and accounting employees spend more than 50 percent of their time handling these major vendors. After the EDI solution is fully implemented, the Purchasing department manager anticipates a 30 percent increase in employee efficiency in these departments.

The Adventure Works Cycles application must provide the following features:

  • The ability for Adventure Works Cycles and the vendors to transmit and receive a variety of data and file types, including structured and semi-structured data

  • The ability for vendors to submit their data directly to the Microsoft SQL Server™ purchasing tables

  • A Web-based system that provides secure information specific to each vendor

  • The ability to automatically detect when the vendors have incoming files or other data ready for Adventure Works Cycles to receive

Business problems in the Information Systems department

The Adventure Works Cycles Internet site is being developed. Currently, customers can access basic product information, find the closest sales office, and request printed information. They cannot order products online or view the status of an existing order. The ability to search the current Web site for product information is limited to viewing products by category. To increase its customer base and provide additional functionality for existing customers, Adventure Works Cycles is expanding its Internet site to include the following features:

  • Online product ordering for customers

  • Online order-status checking

  • Better search capabilities for product information

  • Ability to access explicit sections of engineering product specifications

  • Ability to view product information and pricing in international currency and character sets

In addition to the Internet site, Adventure Works Cycles has a small intranet Web site consisting of a home page and links to all department sites. Each department is responsible for maintaining its own site and notifying the IS department of any changes that need to be made to its links on the home page. The focus for the intranet site is to improve internal communication. Jose Lugo, Adventure Works Cycles’ finance manager, says that it is difficult to get information from one department and supply it to other departments. The department managers want to route more file transactions and data access through the internal Web site. This intranet site must support the following features:

  • The ability to search for information across departmental sites.

  • The ability to change or update to internal information (pricing changes, customer complaints, and so on).

  • The availability of product data to all departments. It must be visible and adaptable to multiple needs (sales, marketing, and engineering).

Business problems in the Production department

The Adventure Works Cycles product line consists of nine bicycle product groups. Each product contains one or more subcomponents, depending on the customer order. Currently, production receives a specification from the Engineering department and uses it to assemble the product. A product clerk enters all the specification information used by production. Certain basic product information is available to customers on the external Web site. However, customers do not have access to the entire product specification. The entire product specification is available to the sales staff from the internal site.

As products move through each assembly area, subcomponents and other value-added materials are added to the product until it reaches the final assembly area. Some of the problems associated with production workflow are as follows:

  • Scheduling and production. To avoid delays in production, the team needs:

    • Easier access to manufacturing data, such as work orders and inventory levels, that is applicable to a specific assembly area.

    • The ability to analyze workflow data.

  • Inventory auditing. Instead of manually auditing and updating the inventory system, the company wants to use barcode scanning by using a Handheld PC with the existing inventory audit application.

Business problems in the System Administration department

Full availability of Adventure Works Cycles’ key systems has become a focus for the System Administration department. Complaints about the amount of system downtime have been increasing steadily.

The System Administration department does not have central control of database management functions. As a result, each database group is developing its own practices and procedures. This decentralized approach might not be an optimal use of resources. In addition, the IS staff has requested a better method of monitoring system resources across all operating systems.

The System Administration department at Adventure Works Cycles must provide the following functionality to address these business problems:

  • Availability of services at all times to support Adventure Works Cycles’ key systems

  • Backup and recovery systems for all databases being used at Adventure Works Cycles, including data stored at World Wide Importers

  • Monitoring of all resources across all operating systems

Business problems in the Engineering department

The Engineering department is responsible for designing the major components for all Adventure Works Cycles products. The team needs a system to manage the documentation needs of the department. Some of the requirements of this system are as follows:

  • Collaborative content management. The department needs an automated system that allows them to control how drawings and specifications are reviewed, approved, and released to manufacturing for use.

  • Accessing and storage of multiple file types. The department needs a consistent method for storing, retrieving, and archiving various files, such as computer-aided design (CAD) drawings and XML product specifications. This system must be linked to the tabular data used to track drawing and specification versions.

What Are the Requirements of the Adventure Works Cycles Application?

The Adventure Works Cycles application is a Web-based retail application. It is intended for both customers and other businesses, such as retail stores reselling Adventure Works Cycles products. In addition, the application needs to host one or more pages to allow potential job applicants to submit resumes to Adventure Works Cycles and retrieve and edit the resumes.

Business tasks

The Adventure Works Cycles application must support the following tasks:

  • Customers must be able to place orders.

  • Customers must be able to delete orders.

  • Application system must be able to reject orders.

  • Customers must be able to modify existing orders that are being processed.

  • Customers and resellers must be able to review existing orders.

  • Customers must be able to create new customer records.

  • Customers must be able to edit customer information.

  • Customers must be able to submit resumes for employment consideration.

  • Customers must be able to retrieve and edit previously submitted resumes.

NOTE
Customers and resellers can access only their own information.
Web site requirements

The Internet Web site for Adventure Works Cycles must support the following features:

  • Every page on the Web site must display a search option with appropriate search controls and a navigation bar on the left side.

  • The customer must be able to search for products by using a part of a product description and a price range.

  • The home page must display products that are on sale and special offers, and it must include a picture and description of each product.

  • A Groups page must display a hierarchical list of links to groups of bicycle models or bicycle parts in a tree structure.

  • A Product Details page must display information about a single product model. It must contain the product name and description, a large picture, and a price range. If the model is available in multiple sizes, multiple colors, or both, appropriate drop-down lists must be provided. When the customer selects a size or color, the other list is repopulated, and the price range narrows to the price of the specific product.

  • A Current Order page must display the products a customer has ordered and the quantity of each product, and it must include unit and total prices. A customer must be able to change quantities or remove items from this page. A Continue Shopping button must take the customer back to the last instance of the Products page visited.

  • A Customer Sign-in page must allow registered customers to sign in with their e-mail addresses and passwords. New customers must be able to register from this page. (Resellers will not use this page.)

  • A Sign-in Information page must allow customers to input or change their e-mail addresses, passwords, and other personal information.

  • An Address Maintenance page must allow customers to create, view, update, and delete billing and shipping addresses in their profiles.

  • An Addresses Selection page must allow customers to select or remove billing and shipping addresses for an order.

  • An Order Summary page must display an order, and it must include sales tax, shipping cost, and the details of reseller discounts. The customer must be able to change the quantities and remove items.

  • An Arrange Payment page must allow customers to use credit cards that are on file in the database or to input new credit card information. Resellers must be able to select payment types and input purchase order numbers.

  • An Order Confirmation page must display a summary of the submitted order, and it must include an order date, a confirmation number, and order status.

  • An Order Status Lookup page must display a list of all orders entered by the signed-in customer. The customer must be able to select one of the orders so that it can be displayed in the Order Confirmation page.

  • An Available Jobs page must allow customers to submit their resumes.

In the remaining chapters, you will learn how to design a solution that meets the requirements of the Adventure Works Cycles application.


Summary

  • The MSF Process Model is a combination of the waterfall and spiral process models.

  • The MSF Process Model is a milestone-based, iterative approach to developing solutions.

  • The MSF Team Model specifies six roles for project teams that are involved in developing solutions: product management, program management, development, testing, release management, and user experience.

  • You need to define the scope of a project by managing tradeoffs.

  • MSF recommends an iterative approach to designing solutions.

  • You implement iterations in a development life cycle by creating versioned releases and maintaining living documents.

  • You create the vision/scope document during the envisioning phase of the MSF Process Model.

  • You create functional specifications during the planning phase of the MSF Process Model.

  • You create the solution during the developing phase of the MSF Process Model.

  • You test the solution and conduct pilots during the stabilizing phase of the MSF Process Model.

  • You deploy the solution in the production environment and submit the solution to the operations and support team during the deploying phase of the MSF Process Model.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. Describe the differences between the waterfall model and the spiral model, and describe how MSF uses both in the MSF Process Model.

  2. In the MSF Team Model, who is responsible for the design process?

  3. The tradeoff triangle describes the three types of tradeoffs that a project team and the customer can make. What is a fourth tradeoff that could be considered but that should never be compromised?

  4. Using the following statement, complete the tradeoff matrix below.

    “Given a fixed feature set, we will choose resources and adjust the schedule as necessary.”

    Fixed

    Chosen

    Adjustable

    Resources

    Schedule

    Features

  5. Describe the purpose of performing daily builds in the MSF Process Model.

  6. When you reach the release readiness milestone, what phase have you completed?

  7. During which phase of the MSF Process Model is the initial risk assessment document created?

  8. When are test cases established in the MSF Process Model?

  9. List several types of tests that are performed during the stabilizing phase.

  10. Why is it important to create a vision statement for the project during the envisioning phase?

  11. What are some of the key tasks that are performed during the planning phase?

  12. Describe the quiet period and the activities that occur during this period.


Chapter 2: Gathering and Analyzing Information

Chapter 2
Gathering and Analyzing Information
About This Chapter

Gathering and analyzing information are steps that you perform throughout the Microsoft® Solutions Framework (MSF) Process Model. These lessons provide you with an overview of how to gather and analyze information. You will learn about the types of information that you need to gather, sources of information, and some techniques for gathering information. In addition, you will learn how to analyze all the gathered information and become familiar with some techniques for analyzing information.

NOTE
This chapter presents information that is not specific to a particular phase in the MSF process but that is relevant to all phases. It is important to learn information gathering and analysis techniques before you start the process of envisioning and designing a solution.
Before You Begin

To complete the lessons in this chapter, you must

  • Be familiar with the MSF Process Model.

  • Have Microsoft Visio® 2000 Professional, for creating diagrams.


Lesson 1: Gathering Information

When gathering information, you need to be aware from the outset of the various types and characteristics of information to ensure that you gather the appropriate information. The purpose of this lesson is to introduce you to the various ways you can think about the information you need to gather about a business challenge. By taking a broad view of information, you can increase your chances of gathering all of the input you need to make an effective analysis.

After this lesson, you will be able to

  • Identify the types of information that you should gather.

  • Identify the techniques for gathering information.

  • Identify various sources of information for gathering requirements.

  • Create an information gathering strategy.

Estimated lesson time: 20 minutes
Categories of Information

An enterprise architecture is a representation of a business—a dynamic system—at a single point in time. The enterprise architecture for a business aligns information technology groups and processes with the goals of a business. To gather information about an enterprise architecture, use four descriptive categories from an enterprise architecture model to guide and classify the information you gather. The four categories are business, applications, operation, and technology.

Business

The business category describes how the business works. It describes the functions and the cross-functional activities that an organization performs. Information from this category also describes the business’s high-level goals and objectives, products and services, financial structures, integrated business functions and processes, major organizational structures, and the interaction of these elements. It includes broad business strategies and plans for transforming the organization from its current state to its future state.

Application

The application category includes the services and functionality that can cross organizational boundaries and link users of different skills and functions to achieve common business objectives. Information in the application category describes the automated and non-automated services that support the business processes. It provides information on the interaction and interdependencies of the business’s application systems.

Automated business services can include complete applications, utilities, productivity tools, components, and code modules that allow for the analysis of information or task functionality.

In an organization, identical tasks are often repeated multiple times by using different tools. As you gather information about processes in the organization, investigate the different applications used to conduct company activities. These existing applications or portions of these applications can provide core services for any new solution. It is more cost effective to reuse than to re-create these services. The information you gather will help to refine the business processes by indicating potential inefficiencies or redundancies.

The application category provides information about the current use of systems and services. You will also obtain indicators about future directions when you gather information from resources such as users and business documents.

Operations

The operations category describes what the organization needs to know to run its business processes and operations. This category includes standard data models, data management policies, and descriptions of the patterns of information consumption and production in the business.

You should identify the information’s origin, ownership, and consumption. Tracking and analyzing its access and use patterns provides the basis for making data distribution, replication, and partitioning decisions, in addition to identifying what is needed to establish standards and guidelines for replication, repositories, and data warehousing. Often, the consumers of information are not adequately questioned to determine not only what information they need, but also what they do with the information when they have it.

The relationship between key business processes and the information required to perform these processes helps to set standards and guidelines for creating, retrieving, updating, and deleting information and data; for sharing critical documents and data; and for defining security levels and standards for access. Realize that not all information is centralized or easy to access by each person or system that needs the information. Often, the information most critical to a business resides on database servers, on the workstations that make up the active working environment of the business, and possibly in the heads of the employees (meaning that the information is not recorded anywhere).

Technology

The technology category defines the technical services needed to perform and support the business mission, including the topologies, development environments, application programming interfaces (APIs), security, network services, database management system (DBMS) services, technical specifications, hardware tiers, operating systems, and more.

This category also provides information about the standards and guidelines that a business uses for acquiring and deploying workstation and server tools, base applications, infrastructure services, network connectivity components, and platforms.

Technology provides the link between applications and information. Applications are created and based on different technologies. They use technology to access information, which is stored by using various storage technologies.

You can use information from the technology category to determine the standard interfaces, services, and application models to be used in development. This information can translate into development resources for the project teams, including component and code libraries, standards documents, and design guidelines. This information can also provide a basis for an application’s design goals and constraints.

What Are the Techniques for Gathering Information?

There are six main techniques that you can use for gathering information:

  • Shadowing

  • Interviewing

  • Focus groups

  • Surveys

  • User instruction

  • Prototyping

NOTE
You might not use all of these techniques. You need to identify which techniques will work best for the specific source you are going to extract information from. In addition, you need not be an expert on all of the techniques. For implementing these techniques, you might need training or the help of an expert.
Shadowing

Shadowing is a technique in which you observe a user performing the tasks in the actual work environment and ask the user any questions related to the task. You typically follow the user as the user performs daily tasks. The information you obtain by using this technique is firsthand and in context. In addition, you understand the purpose of performing a specific task. To gather as much information as possible, you need to encourage the user to explain the reasons for performing a task in as much detail as possible.

Shadowing can be both passive and active. When performing passive shadowing, you observe the user and listen to any explanations that the user might provide. When performing active shadowing, you ask questions as the user explains events and activities. You might also be given the opportunity to perform some of the tasks, at the user’s discretion.

TIP
Shadowing works well for tasks that are performed frequently. However, if a task is performed only occasionally, finding an opportunity to shadow someone for that specific task might be difficult.

Shadowing is a good way to get an idea of what a person does on a day-to-day basis. However, you might not be able to observe all the tasks during shadowing because more than likely the person will not, during that session, perform all the tasks he or she is assigned. For example, accounting people might create reports at the end of the month, developers might create status reports on a weekly basis, and management might schedule status meetings only biweekly.

In addition to the information that you would collect from the individual, you might collect relevant work artifacts, such as documents and screen shots of the current solution.

NOTE
In information gathering, an artifact is any item that is physically available in the business environment that describes an element or core business process. Artifacts are discussed in detail later in this lesson.
Examples of questions for shadowing

While gathering information by using the shadowing technique, you encourage the user to answer the following questions:

  • How do users structure their work?

  • What decisions do users make when starting or completing a task?

  • How does the current implementation define the way users perform their jobs?

  • How often does the system interfere with their jobs?

  • How do interruptions affect users? Can users resume where they left off after being interrupted?

  • With how many people does a specific user interact during a given activity?

  • What modifications has the user made over time to make it easier to complete the task?

  • Are there any variations in the steps that the user performs to complete the task? What are these variations, and under what conditions are the variations used?

In addition to learning how users perform their tasks, you can learn about the parts of the current solution and process that cause users to feel dissatisfied or frustrated.

During the shadowing process, look for answers to the following questions:

  • How do users currently perform these tasks?

  • How can the processes be made more efficient? Should any tasks that are performed manually be performed by an automated solution?

  • Which related tasks might affect the design of the solution?

  • What system features are needed to support the tasks?

  • What are the performance criteria?

  • How should the features of the solution be structured?

  • How can the current system be improved?

  • Which features of the current system are being used frequently, and which features are being used rarely?

  • What do users like and dislike about the current system?

  • How can training and support costs be reduced?

  • What information about the users is not documented?

  • What are the users’ working environments?

  • What are the characteristics and preferences of users?

  • What are the concepts and terminology used by the users?

  • What training has been provided to users?

  • What training do users need?

  • Have users been through training, or are they self-taught? How does the training or lack of training affect their ability to use the system and perform their tasks?

NOTE
Ensure that you observe and question both the management and users. If there are external customers, include them in your observations.
Interviewing

While shadowing provides an effective means to discover what is currently being done in a business, it might not provide all the necessary information. Shadowing is not the best option for gathering information about tasks such as management-level activities; long-term activities that span weeks, months, or years; or processes that require little or no human intervention. An example of a process that requires no human intervention is the automatic bill-paying service provided by financial institutions. For gathering information about such activities and processes, you need to conduct interviews.

An interview is a one-on-one meeting between a member of the project team and a user or a stakeholder. The quality of the information a team gathers depends on the skills of both the interviewer and the interviewee. An interviewer who becomes an ally can learn a great deal about the difficulties and limitations of the current solution. Interviews provide the opportunity to ask a wide range of questions about topics that you cannot observe by means of shadowing.

Some important points to remember before conducting interviews include:

  • Start with non-specific set of questions and encourage interviewees to think about all the tasks they perform and any information they can provide.

  • Using the answers to the questions, ask interviewees to put the larger tasks they perform in order, and to break the larger tasks into smaller tasks.

  • Specifically ask interviewees to identify information that is usually missing and alternative paths that can occur.

  • Reiterate through the preceding steps several times and continue to ask interviewees what else might be involved.

  • Ask interviewees for ideas that they have to improve the situation, but avoid assuming that those ideas are the correct solution.

Examples of questions for interviewing

While conducting an interview, structure questions carefully so that you do not ask misleading questions or questions that ask for more than one type of information. Some of the questions that you might ask during an interview are:

  • What problems do you encounter while performing your tasks?

  • What kind of help do you need when you work remotely?

  • Do you have special needs that are not documented?

  • What business policies help you or hinder you in performing your job?

  • What individuals or documents provide essential information that you need to do your job?

  • What other users or systems, such as third-party suppliers or support specialists, affect your work?

Focus groups

A focus group is a session in which individuals discuss a topic and provide feedback to a facilitator. Focus groups concentrate on group interviewing techniques. Use this method in cases in which there are more users than you can involve directly in the information gathering process. For the information gathered during a focus group to be useful, ensure that the participants of the focus group represent the users or stakeholders associated with the business. You should also ensure that you have appropriately defined the topic of the focus group and that you keep the group focused on this topic.

Focus groups allow you to gather detailed information about how an activity fits into the business as a whole. Individuals in a focus group can fill knowledge gaps for one another and provide a complete description of a business process.

Focus groups might not be successful if the participants are located in different geographical locations. Focus groups also might not work if the users that were identified to participate do not perform the same activity or do not have enough knowledge about the activity. Finally, focus groups are not successful if the facilitator is unable to direct the meeting and keep the discussion focused.

Surveys

Surveys consist of sets of questions that are created to gather information. Examples of surveys include user registration forms and customer feedback or satisfaction forms.

Creating survey questions can be a labor-intensive process. You need a trained professional for creating the survey questions and analyzing the results of the survey. You can use surveys to gather information and to identify further information gathering activities that you need.

One of the benefits of using surveys is that they enable users to respond anonymously. You can collect information that might be impossible to collect with any other technique. However, you might need to treat the responses to the survey with confidentiality to protect the respondents. You might want to modify or neutralize the language so that the identity of the person remains confidential. Surveys provide results that can be tabulated and easily interpreted.

NOTE
The results of a survey can be affected by user attitudes. Surveys are therefore very subjective.

Examples of information that can be collected by using surveys include:

  • Organizational structures, policies, or practices that facilitate or interfere with tasks

  • Frustrations with technical support structures or policies

  • Special needs related to hardware or software

  • Training issues, such as the effectiveness of current training programs, types of training programs that users like, and training programs that work best in the users’ work environment

User instruction

When you use the user instruction technique, users actually train you on the tasks that they perform. This allows you to participate in the activity and view each step of the process from the user’s perspective. You might also gain knowledge that an individual has learned over time and that is unavailable from artifacts or systems.

User instruction can be time consuming if the process you are investigating is long. This method could also be frustrating for the researcher if the user is not accustomed to teaching others. In addition, different users might perform the same task differently. Consequently, you should collect information from multiple users.

Planning
Identify the experts in different activities within the business. They might know shortcuts that overcome problems in a process. Experts can act as models for developing new processes or improving existing processes.

You can also use help desks at a business to gather information about the user experience. A help desk is a useful source because it provides a direct perspective on the problems experienced by users. Gathering information from help desk is one way of benefiting from user instructions.

By allowing users to teach you the tasks they perform, you can gather information to determine:

  • User interface design

  • Training needs for both current and future processes

  • System performance criteria

  • The impact of the physical environment on a task

Prototyping

Prototyping allows you to gather information by simulating the production environment. You can use several tools to collect information, such as a camera to monitor visual activity or a computer program to monitor keystrokes and mouse clicks. The tool that you select for prototyping depends on the type of information you want to collect.

Use prototypes when it is impossible to shadow a person in the normal work environment. The data that you collect by prototyping is typically empirical rather than responses from users. Therefore, you can easily validate this data. However, the cost of prototyping might be high.

Prototypes can help you to verify or document information from the user and business perspectives, including:

  • Customer quality requirements

  • Response-time requirements and goals

  • Ease of use

  • Integration of current technologies and applications

  • User interface issues, such as the features that users want to see added to an application

  • Verification of workflow processes

What Are the Sources of Information?

You have learned about the different types of information that you can gather in a business. This information can be found in various forms. The number and diversity of information sources depends on the size of the business. Some of the information sources are:

  • Artifacts

  • Systems

  • People

Artifacts

An artifact in information gathering is an item that is physically available in the business environment and that describes an element or core business process. As in archeology, artifacts help us understand the current environment. They provide information about tasks, processes, business needs, and constraints. Examples of artifacts include training manuals, video recordings, regulatory requirements, earlier program files or tapes, help desk documentation, and financial reports.

You can easily identify some artifacts that are used in a business. For example, employees keep frequently used artifacts around their work areas. Other artifacts might be stored in file cabinets or on computer media and are therefore less visible. You might require access to proprietary artifacts to review all information thoroughly. Use discretion in handling artifacts that are directly or indirectly part of the intellectual property that allows a business to compete in the marketplace.

Individuals in a business typically develop their own artifacts. For example, a user might create an instruction sheet for an application or process, or outline how to accomplish a task in e-mail messages. These unofficial artifacts provide valuable information. They indicate not only what people do in their daily work, but also the type of support information that is lacking in the current solution and possibly why they need to perform these tasks. Sometimes these artifacts will be the only documentation you will find related to certain processes.

During a project, the project team creates artifacts such as project meeting notes, summaries of the information gathered within the business, and the vision document. Some artifacts, such as meeting notes, are used exclusively by the project team. However, the vision document is shared by both the project team and stakeholders.

Systems

Systems describe an element of the business that is performing an action. A specific system is a set of discrete processes that accomplish an action. A system might be composed of subsystems. A system can be a tangible process, such as an inventory tracking system, or an intangible process, such as the methods that a manager uses to identify and resolve problems within a department.

Systems can be complex because they can contain multiple subsystems and many categories of information. In addition, all the subsystems might not be readily apparent. For these reasons, you might need to budget additional time to understand a system completely. Systems indicate how a business conducts day-to-day activities.

TIP
It is a good practice to enlist the help of someone who is an expert on the system and have the expert lead you through the different processes that the system performs.
People

The people who are stakeholders in the business can be the source of valuable insights into the business, often providing information that is not documented anywhere. These stakeholders include executives, developers, managers, customers, and users. In cases where documentation is incomplete (or non-existent), people might be the only source for the information you need to learn about the business.

Before approaching people to gather information, take the time to identify the different roles that the people perform in the business. For example, the group of people who provide support and information to users to help them perform their tasks might provide insight into which areas cause the most difficulties for users. Long-term employees with experiences in multiple operations within the business can provide insight as to how different activities relate to each other. Also, if the business uses a third-party vendor for any of its processes, the vendor might have a unique perspective on the efficiency of the business and its processes.

Planning
Before talking to users, you should gain some experience with the systems that they use. Gaining this experience helps you avoid broad questions like “How do you use the system?” “What do you do throughout the day?” or “What is a workday like for you?”
How to Define the Information Gathering Strategy

When gathering information, you should define an information gathering strategy. Defining an information gathering strategy includes identifying the users, defining questions, and choosing an appropriate technique for gathering information.

When defining an information strategy, you need to keep in mind the following questions:

  • What sources do you want to poll for information?

  • What information do you need to collect?

  • What techniques will you use to collect the information and to what sources will each technique be applied?

  • How will you record the information you collect?

  • What time frame will you use to collect the information?

The following are some of the guidelines that you can use to define an information strategy:

  • Use multiple information gathering techniques. If you rely on only one information gathering technique, you might have an incomplete view of the business. By combining various techniques, you overcome any shortcomings associated with any one technique. For example, assume that a process occurs once per month in the accounting department of a business. If you shadow a user in the accounting department for a few days, you might miss important information about the process because the user might not perform the tasks for this process while you are shadowing. By complementing shadowing with a focus group or a follow-up interview, you can gather information about all the processes that occur in the accounting department.

  • Identify the most effective technique. Weigh the advantages and disadvantages of each technique when you are developing your information gathering strategy. For example, you might need to collect information as quickly as possible to respond to an immediate business challenge. Surveys take time to plan, administer, and analyze. Instead, shadowing, interviews, or user instruction can help you gather information quickly.

  • Remember all perspectives, types of information, and information sources. Regardless of the information gathering technique, remember that you need to gather information from both user and business perspectives. Explore as many sources of information as possible within the time you have to gather information.

  • Gather information from groups that use similar business processes. Different groups in a business might be following similar processes and might have responded to similar business challenges. Information gathered from those groups might help the project team to look at the business challenge from a new perspective.


Lesson 2: Analyzing Information

In this lesson, you transition from the process of gathering information to the process of analyzing information. The processes of gathering and analyzing information are iterative. You gather some information and analyze it. As you review that information, you will undoubtedly discover that you have more questions. You will then formulate your questions and take them back to the appropriate sources for clarification. Having this new information will help you to continue analyzing the business. This form of collaboration will continue throughout the life cycle of the project, although most of the information gathering and analysis will occur at the beginning of the life cycle.

After this lesson, you will be able to

  • Analyze enterprise architecture information.

  • Describe use cases and usage scenarios.

  • Create internal project documentation.

Estimated lesson time: 20 minutes
Enterprise Architecture Information

When you think you have gathered enough information from the customer, you will have a large amount of information that you need to review to determine what information is most relevant to the business challenge. You need to synthesize the information to create a detailed description of the current state of the business.

As you analyze the information you have gathered, verify that you have enough information to indicate the current state of the business and product requirements, including:

  • Security needs.

  • Support structures for the solution and their characteristics.

  • Planned changes in the business that could affect the product design.

  • Performance that users expect or that the business needs to remain competitive.

  • Existing applications that will need to interact with the new product.

  • How the existing business processes affect the solution.

As you synthesize and analyze the information, you can identify any gaps that exist in the information you collected, and, if necessary, gather additional information.

When the development team actually develops the final product, it will need to verify that the final product meets all the requirements that were established during the gathering and analyzing processes. The team will also need to document the effects that the new product might have on the existing environment in terms of new requirements for the business, such as support, maintenance, and extensibility issues. The new requirements must also adhere to the constraints that you documented during analysis.

High-Level Use Cases and Usage Scenarios

After you have synthesized the information, you can develop use cases and usage scenarios to document the business processes and business and user requirements in more detail. The use cases and usage scenarios that you develop will provide structure for the development team when it designs the solution. In addition, each use case and usage scenario will correspond to one or more requirements. This correspondence allows you to ensure that the requirements are being met.

Use cases

Use cases show the functionality of a system and how an individual interacts with the system to obtain value.

The purposes of use cases are to:

  • Identify the business process and all activities from start to finish.

  • Document the context and environmental issues.

  • Establish a connection between business needs and user requirements.

  • Describe needs and requirements in the context of use.

  • Focus users and the development team.

Use cases provide the following benefits:

  • Provide context for requirements

  • Facilitate common understanding

  • Provide the basis for usage scenarios

  • Facilitate objectivity and consistency in evaluating user suggestions

Usage scenarios

Use cases describe the high-level interactions between an individual and a system. Usage scenarios provide additional information about the activities and task sequences that constitute a process. Together, use cases and usage scenarios provide a description of a workflow process.

You will learn how to create use cases and usage scenarios in Lesson 4.

Draft Requirements Document

After the team has gathered information from the customers, one of the steps in analysis is to create a draft requirements document. This document includes a preliminary list of requirements from the information that is gathered by the team. The main purpose of this document is to record any possible requirements and, in doing that, to ensure that no valuable information is lost. The information that you gather from different sources will include requirements and wants from the business and user perspectives. The requirements indicate what the product or solution needs to do to solve the business challenge as derived from the business and user perspectives. The wants indicate what stakeholders and users would like to see in the final product or solution.

The requirements listed in the draft requirements document are not refined and therefore can be a combination of requirements and wants. These requirements are refined further in later stages of envisioning and planning, when the team gathers more information from the customers.

You will learn more about identifying requirements, wants, and constraints in Chapter 4, “Creating the Conceptual Design.”

Example of an interview

Following is an example of an interview from the Adventure Works Cycles scenario that was introduced in Chapter 1, “Introduction to Designing Business Solutions.”

Summary of an interview with the territory sales manager

We had a great year in sales this year. Our jobs have been a lot easier since the company equipped us with laptop computers and PDAs. We have been doing some forecasting for the next year, and we are starting to see a slow decline in sales, particularly if we continue to operate like we have in the past. The sales department has established a number of goals for the new fiscal year. The top three goals are (a) focus on our best customers, (b) use sales staff time more effectively, and (c) manage sales opportunities better.

We don’t have an easy way to analyze our customer base. Currently, customer data is stored in our systems, but there’s no easy way to retrieve the data and allow us to view the data in different ways. To better identify our best customers and why they are our best customers, we need a way to access our data and to be able to analyze it in a meaningful way.

Another problem we’ve experienced in recent months is in presenting our products and achieving sales in our foreign markets. Currently, all the information on our computers is written in English only. We need to store multilingual and multiregional information in the database rather than depending on the sales force to translate the information.

Our team needs to obtain the latest pricing information on a daily basis, and we should be doing this every day. Currently, the sales representative connects to the corporate network and downloads the new pricing list each day in the morning. However, the download process does not identify which prices have been modified for that individual sales representative. So the sales representative must download the entire list every morning. You can imagine how customers feel when they have negotiated a deal with us only to find out that the price was incorrect.

Another area that needs definite improvement is in our sales opportunities management. Employees are supposed to use our customer management system to plan, execute, and track sales and marketing strategy. In addition to that, sales representatives need to install a large application on their laptop computers and connect to the corporate network to use it. We want to be more mobile than that; we want to be able to access this information from a Web site. The information must be easy to access and meaningful for the sales representatives and the company; otherwise it doesn’t help anyone. We want to achieve the following goals with the new system: Minimize the amount of technical knowledge that sales and marketing needs to access the data, and allow the staff to obtain standard reports, generate custom queries, track promotions, and view customer segmentation information. In addition, we want this system to be flexible enough so that we can add third-party data sources and financial evaluation tools. No matter who views a particular customer’s information, that individual must get a clear, unified view of the customer and the customer’s relationship with us.
Example of a use case diagram

Figure 2.1 shows a preliminary use case, which is based on the interview shown in the previous section.

Figure 2-1 Use case diagram
Figure 2-1. Use case diagram
Example of a draft requirements document

Figure 2.2 contains a list of draft requirements that you might have identified from the interview and use case.

Figure 2-2 Draft requirements document
Figure 2-2. Draft requirements document

As you analyze information, you will most likely find that you need to gather additional information. The number of iterations that you conduct depends on the business challenge, the complexity of the problem, and other factors, such as time limits imposed by stakeholders.

Figure 2.3 is an example of the draft requirements document with additional questions that you might ask your customers for clarification about specific requirements.

Figure 2-3 Additional questions for requirements
Figure 2-3. Additional questions for requirements
Internal Project Team Documentation

After gathering information, as a part of analysis, the team creates several internal documents that are not typically provided to the customers. These documents—the actors catalog, business rules catalog, and glossary—are living documents and are refined during the course of project life cycle.

Actors catalog

The actors catalog contains information about all the actors that will be used in use cases. (An actor is an entity that interacts with the system.) The actors catalog contains the following information:

  • Actor name

  • Responsibility of the actor

  • Source for this information

For example, in the Adventure Works Cycles scenario, a sales representative is an actor whose responsibilities include establishing contacts with customers within a geographic region, and acquiring knowledge about products and their specifications and information about all the customers. The source of this information is tracked in case you need to go back to the source for additional information or clarification.

Figure 2.4 is an example of an actors catalog.

Figure 2-4 Actors catalog
Figure 2-4. Actors catalog
Business rules catalog

The business rules catalog is a living document that lists the business rules for a solution. The business rules catalog is a predecessor for the requirements document. This document is created early in the design process, when the team gathers information. This document, like the actors catalog, is meant only for the team and is typically not provided to the customer.

The business rules catalog includes the following fields to document information about a business rule:

  • Identification number for the business rule, for tracking and traceability

  • Short title for the business rule

  • Description of the business rule

  • Authority (the source of the business rule)

  • UC/BR (use case or business rule), which specifies either the use case to which the business rule might refer or another business rule to which the business rule relates

  • Current functionality, which indicates the functionality related to the business rule in the current system

For example, a business rule identified during interviews and conversations with the sales manager in the Adventure Works Cycles scenario is that sales representatives can provide a discount of up to 10 percent to their customers. However, sales managers can approve and provide a discount of up to 20 percent to their customers.

Figure 2.5 is an example of a business rules catalog.

Figure 2-5 Business rules catalog
Figure 2-5. Business rules catalog
Glossary

When designing a business solution, the team will identify terms that need to be defined. The glossary contains a list of these terms and their meanings. The purpose of the glossary is to ensure that everyone is using the same terms and that everyone understands what those terms mean.


Lesson 3: Using Modeling Notations

You use models to describe business processes, to understand the current state of the business, and to model new processes that do not exist but that you plan to create in the future. Models help you depict business processes and their relationship with other processes. You also depict the tasks that comprise the process. In this lesson, you will learn about the benefits of models and the different types of modeling notations that you can use.

NOTE
This lesson assumes that you use Microsoft Visio® for Enterprise Architects for creating diagrams.
After this lesson, you will be able to

  • List the benefits of modeling.

  • Describe the role of Unified Modeling Language (UML) in conceptual design.

  • Describe the purpose of various UML views.

  • Describe the purpose of the various UML diagrams.

  • Describe the role of Object Role Modeling (ORM) in conceptual design.

  • Describe the relationship between UML views and the different phases of the MSF Process Model.

Estimated lesson time: 20 minutes
Benefits of Modeling

You use models to describe both the current and proposed solution to a business challenge. Some of the benefits of using models are:

  • Models provide you with a common terminology that can describe both the current and proposed solutions.

  • Models help to describe complex problems in a simpler structure and enable easy communication.

  • Models enable consensus by helping the project team understand the business challenge, the business and user requirements, and the information that must be gathered.

As the business processes are modeled and adapted to reflect the requirements, you can build a model of the architecture that describes the final business solution. Two commonly used modeling notations are:

  • Unified Modeling Language (UML)

  • Object Role Modeling (ORM)

What Is UML?

UML is a standard modeling language that you use to model software systems of varying complexities. These systems can range from large corporate information systems to distributed Web-based systems.

UML was developed to provide users with a standard visual modeling language so that they can develop and exchange meaningful models. UML is independent of particular programming languages and development processes. You use UML to:

  • Visualize a software system with well-defined symbols. A developer or application can unambiguously interpret a model written in UML by another developer.

  • Specify the software system and help build precise, unambiguous, and complete models.

  • Construct models of the software system that can correspond directly with a variety of programming languages.

  • Document the models of the software system by expressing the requirements of the system during its development and deployment stages.

    More Info
    For additional information about UML, you might find the following references useful: The Unified Modeling Language User Guide by Grady Booch, Ivar Jacobson, and James Rumbaugh (Addison-Wesley, 1999) and Use Case Driven Object Modeling with UML: A Practical Approach by Doug Rosenberg with Kendall Scott (Addison-Wesley, 1999).

  • It is a simple, extensible, and expressive visual modeling language.

  • It consists of a set of notations and rules for modeling software systems of varying complexities.

  • It provides the ability to create simple, well-documented, and easy to understand software models.

  • UML is both language independent and platform independent.

What Are UML Views?

UML enables system engineers to create a standard blueprint of any system. UML provides a number of graphical tools that you can use to visualize and understand the system from different viewpoints. You can use diagrams to present multiple views of a system. Together, the multiple views of the system represent the model of the system.

You use models or views to depict the complexity of a software system. The various UML views depict several aspects of the software system. The views that are typically used are:

  • The user view. The user view represents the goals and objectives of the system from the viewpoint of the users and their requirements for the system. This view represents the part of the system with which the user interacts. The user view is also referred to as the use-case view.

  • The structural view. The structural view represents the static or idle state of the system. The structural view is also referred to as the design view.

  • The behavioral view. The behavioral view represents the dynamic or changing state of the system. The behavioral view is also referred to as the process view.

  • The implementation view. The implementation view represents the structure of the logical elements of the system.

  • The environment view. The environment view represents the distribution of the physical elements of the system. The environment of a system specifies the functionality of the system from the user’s point of view. The environment view is also referred to as the deployment view.

What Are UML Diagrams?

The various UML views include diagrams that provide multiple perspectives of the solution being developed. You might not develop diagrams for every system you create, but you must understand the system views and the corresponding UML diagrams. Similarly, you might not use every diagram to model your system. You need to identify which models will best suit the needs of modeling the system successfully.

Use the following UML diagrams to depict various views of a system:

  • Class diagrams. A class diagram depicts various classes and their associations. Associations are depicted as bidirectional connections between classes.

  • Object diagrams. An object diagram depicts various objects in a system and their relationships with each other.

  • Use case diagrams. A use case diagram represents the functionality that is provided to external entities by the system.

  • Component diagrams. A component diagram represents the implementation view of a system. It represents various components of the system and their relationships, such as source code, object code, and execution code.

  • Deployment diagram. A deployment diagram represents the mapping of software components to the nodes of the physical implementation of a system.

  • Collaboration diagrams. A collaboration diagram represents a set of classes and the messages sent and received by those classes.

  • Sequence diagrams. A sequence diagram describes the interaction between classes. The interaction represents the order of messages that are exchanged between classes.

  • State diagrams. A state diagram describes the behavior of a class when the external processes or entities access the class. It depicts the states and responses of a class while performing an action.

NOTE
You can use Visio to generate UML diagrams. Visio enables you to design and document your solution from the initial analysis and design stages to the final deployment of your system.
Relationship Between UML Views and the MSF Process Model Phases

You create different UML diagrams in different phases of the MSF Process Model. The software development life cycle is typically composed of the UML notations to depict various views of a system. For example, during the planning phase, you might use a set of diagrams to depict the proposed design for the solution. During the developing phase, you can use a different type of diagram to depict software components.

Figure 2.6 depicts the UML views and the diagrams associated with the views.

Figure 2-6 MSF Process Model and UML views
Figure 2-6. MSF Process Model and UML views

Table 2.1 lists the UML views and the corresponding phases of the MSF Process Model.

Table 2-1. UML Views and the MSF Process Model Phases
UML views | UML diagrams | Purpose | Create the diagram | Use the diagram
User view | Use case diagrams | To understand user requirements | Envisioning and planning phases | All phases
Structural view | Class diagrams, Object diagrams | To identify the basic components of the system | Planning phase | Developing and stabilizing phases
Behavioral view | Collaboration diagrams, Sequence diagrams, State diagrams | To identify the behavior of the system in various circumstances and conditions | Planning phase | Developing and stabilizing phases
Implementation view | Component diagrams | To know how the various structural blocks identified in structural view can be grouped and packaged | Planning phase | Developing and stabilizing phases
Environment view | Deployment diagrams | To know the physical and deployment aspects of the system | Planning phase | Developing and stabilizing phases
What Is ORM?

The Object Role Modeling (ORM) method is a fact-oriented method for analyzing information, in terms of objects and the roles they play, at the conceptual level. By using this methodology, you can document business rules and design databases to model complex, data-related business requirements.

You use ORM to model business requirements during the conceptual design stage of the planning phase. A benefit of the ORM method is in its conceptual approach to modeling. This approach helps to ensure the correctness, clarity, adaptability, and productivity of a solution by allowing you to describe the solution by using concepts and language that people can understand easily.

The quality of a solution depends on its design. To design a solution, you build a formal model of the application area. The application area is called the universe of discourse (UoD) in ORM. ORM uses a natural language and intuitive diagrams. You present information as elementary facts. An elementary fact asserts that an object has a property, or that one or more objects participate in a relationship.

NOTE
The associated language, FORML (Formal Object-Role Modeling Language), is supported in Visio for Enterprise Architects.
More Info
For more information about modeling languages, see Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design by Terry Halpin (Morgan Kaufmann Publishers, 2001).
ORM conceptual schema design procedure

The ORM conceptual schema design procedure (CSDP) focuses on the analysis and design of data. The conceptual schema specifies the information structure of the application: the types of fact that are of interest; constraints on these facts; and the derivation rules for deriving some facts from others. The CSDP consists of the following tasks:

  • Analyzing external information and transforming it into elementary facts.

  • Applying a population check to fact types. (All combined instances of an item in the UoD are known as that item’s population.)

  • Identifying primitive entity types in the conceptual model.

  • Applying uniqueness constraints to the conceptual model.

  • Applying mandatory role constraints to the conceptual model.

  • Adding value constraints, set-comparison constraints, and subtype constraints to the conceptual model.

  • Adding ring constraints to the conceptual model.

Analyze and transform external information into elementary facts

This is the most important stage of the CSDP. In this stage, the information required from the system is presented in natural language. Examples of such information include output reports and input forms of the required system. ORM models represent the set of all valid data use cases in the UoD.

Some of the important terms used in modeling are:

  • Instance. An item of interest in the UoD.

  • Population. The group of all combined instances of a given type of item of interest in the UoD is known as that item’s population. In database terms, all rows in a table make up that table’s population.

  • Set. Any group of instances, but a set is not necessarily the same as a population. A set could be part of a population, or a combination of instances from more than one population. All populations are sets, but not all sets are populations.

  • Fact instance. An individual observation of the relationship between two or more data values.

  • Fact type. The set of fact instances that share the same object types and predicate relationships.

  • Object type. The set of all possible instances of a given object.

  • Predicate. A verb phrase that the domain expert uses to relate object types.

Consider the following example of a fact instance:

The author known as Hemingway wrote the book known by the title “A Farewell to Arms.”

In this example, the author, Hemingway, and the book, A Farewell to Arms, are both data values, related by the action verb “write.”

Table 2.2 contains another example. This table displays data used by a university to maintain details about its academic staff and academic departments.

Table 2-2. Example of a table used to store data
Employee Number | Employee Name | Department | Room | Telephone Extension | Telephone Access
715 | Adams, J | Computer Science | 69-301 | 2345 | Local
720 | Bassli, S | Biochemistry | 62-406 | 9642 | Local
139 | Canuto, S | Mathematics | 67-301 | 1221 | International
430 | Culp, S | Computer Science | 69-507 | 2911 | International
503 | D’Hers, T | Computer Science | 69-507 | 2988 | Local
651 | Jones, B | Biochemistry | 69-803 | 5003 | Local

Each fact defines a relationship between two objects. Some of the elementary facts that can be stated from the above table are:

  • The Instructor with Employee Number 715 has Employee Name “Adams, J.”

  • The Instructor with Employee Number 715 works for the Department named “Computer Science.”

  • The Instructor with Employee Number 715 occupies the Room 69-301.

  • The Instructor with Employee Number 715 uses the Telephone Extension 2345.

The name of the Object Role Modeling method reflects the way it uses objects and roles. Objects are either values or entities. Values are character strings or numbers and are identified by constants such as “Adams, J” and 715. Entities are real-world objects that have descriptions, such as the Instructor with Employee Number 715.

You can combine facts. For example, two facts stated earlier can be combined as follows:

The Instructor with Employee Number 715 and Employee Name “Adams, J” works for the Department named “Computer Science.”

Apply a population check to fact types

To apply a population check, you must enter a meaningful sample population into the model. A meaningful sample population represents instances of information in the UoD, and the real-world problem that the project team is trying to solve. The sample population can be from sources such as reports, charts, graphs, input screens, and forms. In the data maintained by the university about its academic staff and academic departments displayed earlier, each row in the table represents one fact instance. Each column in the table represents instances of an object type’s role in the fact type.

Identify primitive entity types

To model business requirements, you must identify object types in the UoD. Object types can be classified as entity types and value types. Primitive entity types represent the most basic entity types in a UoD, and they are mutually exclusive and exhaustive. They are the lowest common denominator of a group of entity types. All primitive entity types are atomic and mutually exclusive:

  • Atomicity. Primitive entity types are atomic because they cannot be broken down into other entity types or structures.

  • Mutual exclusivity. The populations of two or more primitive entity types never overlap. A union of the members of two or more primitive entity types will never produce redundant instances.

    An example of a primitive entity type would be the combination of the StartTime and StopTime object types into a new Time primitive entity type.

Consider the following fact types:

  • Professor obtained Degree from University

  • Senior Lecturer obtained Degree from University

  • Lecturer obtained Degree from University

The common predicate in these fact types suggests that the entity types—Professor, Senior Lecturer, and Lecturer—can be combined to the single primitive entity type: Academic.

Apply uniqueness constraints

You should explicitly test and enforce uniqueness to ensure the strict use of elementary facts and to eliminate redundancy. A uniqueness constraint prevents duplication of role instances spanned by the constraint. A uniqueness constraint placed across all roles in a predicate effectively prevents the duplication of instances of the fact type. Uniqueness constraints are used to assert that entries in one or more roles occur at most once.

Some of the benefits of uniqueness constraints are that they:

  • Prevent fact redundancy. Uniqueness constraints ensure that no fact instances are repeated.

  • Enforce internal uniqueness. A uniqueness constraint on roles within a single predicate is an internal uniqueness constraint. An internal uniqueness constraint ensures that fact table entries for a role, or combination of roles within a single predicate, occur only once. All instances of a fact type must be unique for the fact type to be elementary. For example, the university academic staff is classified as professors, senior lecturers, or lecturers, and each instructor specializes in a research area. The internal uniqueness constraints on the fact types assert that each instructor has at most one rank, holds at most one specialization, works for at most one department, and has at most one employee name.

  • Enforce external uniqueness. An external uniqueness constraint spans roles from two or more predicates and ensures that instances of the role combination occur only once. For example, the external uniqueness constraint stipulates that each department and employee name combination applies to, at most, one academic.

Apply mandatory role constraints

In a relationship, you might have to enforce the fact that every instance of an object type has information recorded. You accomplish this by placing constraints on the object type’s population. A mandatory role constraint forces all instances of an object type to participate in a role.

Mandatory role constraints have the following characteristics:

  • Global nature. Mandatory role constraints are global in nature, to the extent that they force the enumeration of the entire population of an object type. This constraint is important because it forces you to consider all instances for inclusion in all other roles in which an object type participates. For example, if you model a mandatory constraint on an employee’s name and birth date, you must know both items for all employees.

  • Implied with functional dependency. A role is functionally dependent on another if there is a many-to-one or a one-to-one relationship between the roles, and if the first role in the relationship always has a uniqueness constraint. For example, if it is mandatory that each father have a child, and that children are functionally dependent on their fathers, it is mandatory that all children have fathers.

Mandatory role constraints are expressed in FORML notation by the inclusion of the word “Each” in front of an object type. Consider the following example:

Each Person has Name.

In the FORML expression, the word “Each” indicates that the Person role in this fact type has a mandatory role constraint on it and that the name of each instance of the object type Person is known.

Add value constraints, set-comparison constraints, and subtype constraints

Constraints are used to limit populations. ORM provides several methods of limiting the domain of an object type. The domain of a population represents all of the possible values that exist in the population. It is not necessary to use each member of the domain.

For example, an object could be constrained to allow only a number between 1 and 5, or to allow only the names of the days of the week.

Value constraints

Limit the population of an object type to a specific domain of allowable values. The FORML expression of a value constraint follows the pattern of specifying the object type and then the phrase “The possible values of,” followed by the object type and the word “are,” followed by an enumerated list of values. The following FORML expression represents a value constraint on the Person object type that restricts the domain of the object type to Jeff, Maria, and Pierre.

Person(Name) is an entity object type.
Every Person is identified by one distinct Name.
The possible values of "Name" are: "Jeff", "Maria","Pierre".
Set constraints

Often, a relationship exists between the populations of two different fact types. ORM uses set constraints to capture these relationships. Set constraints limit the instances that can participate in a fact type. A set constraint is external and spans roles in two different fact types. By constraining the roles in two different fact types, you constrain the fact instances in each of the fact types. Set constraints restrict two populations in relation to each other. Some of the different types of set constraints are:

  • Set exclusion constraint. Prevents instances in one set from appearing in another.

    No Employee that is paid some HourlyWage is paid some Salary.

  • Set equality constraint. Forces all instances in one set to appear in another.

    Employee e is paid some Salary if and only if Employee e works as some SalesManager.

  • Set subset constraint. Limits instances in one set to those that are also in another.

    If Employee e works as some SalesManager then Employee e works as some Salesperson.
Entity subtypes

You might need to control a subset of an object type’s population differently from the entire population. This subset of the population might participate in different fact types. In addition, you must classify a subset of a group of objects into more specific groups to understand them or gather more useful information from them.

For example, the specialization of the population of the Vehicle object type might result in the object types GasVehicle and DieselVehicle. You could further specialize each of those as ConsumerVehicle and CommercialVehicle object types.

An entity subtype is an object type that is contained in another object type. Entity subtypes must be well defined in terms of relationships played by their supertypes. Entity subtypes with the same supertype might overlap. You must be able to identify entity subtypes and supertypes.

An object type’s FORML expression is annotated to represent every entity subtype in which the object type participates, either as a parent or as a child. The following FORML expression represents the subtype relating to the Salesperson object type:

Salesperson is an entity object type.
Salesperson is primarily identified by the identification scheme of Employee.
Salesperson is a subtype of Employee / Employee is a supertype of Salesperson.
Employee is the primary supertype of Salesperson.
Subtype definition: The subset of Employee who is Salesperson.
Each Manager is a Salesperson but not every Salesperson is necessarily a Manager.
Add ring constraints to the conceptual model

An object type plays just one role in a fact type. When two roles in a fact type are played by the same object type, the path from the object type through the role pair and back to the object type forms a ring. For example, consider the following fact type: Person voted for Person. This has two roles—voting and being voted for. However, both roles can be played by the same object, such as PersonA voting for PersonA.

Ring constraints control the population of an object type’s roles when the object type has two roles in a single fact type. Different types of ring constraints are:

  • Irreflexive. An irreflexive (ir) ring constraint prevents an instance from being related to itself. The FORML expression for an irreflexive ring constraint is:

    No Object is related to itself.

  • Symmetric. The symmetric (sym) ring constraint ensures that a mirror image of every tuple exists in the fact type’s population. In functional programming languages, a tuple is a data object containing two or more components. The FORML expression for a symmetric ring constraint is:

    If Object o1 is related to Object o2
then Object o2 is related to Object o1.

  • Asymmetric. An asymmetric (as) ring constraint ensures that no mirror images of any tuple exist in the fact type’s population. The FORML expression for an asymmetric ring constraint is:

    If Object o1 is related to Object o2
then it cannot be that
Object o2 is related to Object o1.

  • Antisymmetric. An antisymmetric (ans) ring constraint ensures that no mirror images of any tuple exist in the fact type’s population, and that no instance is related to itself. The FORML expression for an antisymmetric ring constraint is:

    If Object o1 is related to Object o2
and o1 is not the same Object as o2, then it cannot be that
Object o2 is related to Object o1.

  • Intransitive. An intransitive (it) ring constraint enforces hierarchical relationships between instances in a population. The FORML expression for an intransitive ring constraint is:

    If Object o1 is related to Object o2
and Object o2 is related to Object o3
then it cannot be that
Object o1 is related to Object o3.

  • Acyclic. An acyclic (ac) ring constraint prevents a path from looping back on itself through a chain of relationships. The FORML expression for an acyclic ring constraint is:

    An Object cannot cycle back to itself through one or more applications of the relationship:
Object is related to Object.


Lesson 4: Creating Use Cases and Usage Scenarios

Use cases and usage scenarios capture the functional requirements of a system. In this lesson, you will learn more about use cases and usage scenarios and how to create them.

After this lesson, you will be able to

  • Create use cases.

  • Describe usage scenarios.

  • Create usage scenarios.

  • Refine requirements from use cases and usage scenarios.

Estimated lesson time: 10 minutes
How to Create Use Cases

Use cases are functional descriptions of the transactions that are performed by the system when a user initiates an event or action. The use cases that you develop should represent the system processes, including all events that can occur in all possible situations.

Use cases consist of elements that are inside the system and are responsible for the functionality and behavior of the system. They are the actions that the system performs to generate the results that the users request. This model allows the project stakeholders to agree on the capabilities of the system and system boundary.

A use case diagram documents the following design activities:

  • Identifying the system

  • Identifying actors

  • Defining the interactions between the actor and the system

  • Determining the system boundary

Identifying the system

A system is a collection of subsystems that have a real-world purpose. For example, in a sales and marketing scenario, the order system might have a subsystem that determines applicable discounts for a customer invoice. When you develop use cases, you identify a single system or subsystem. A collection of use cases indicates the relationships among the subsystems that make up the system, in addition to the relationships between systems that interact with each other.

Identifying actors

The actor is an integral part of the use case. The use case represents the interactions between an actor and the system. An actor is an entity that interacts with the system to be built for the purpose of completing an event. An actor can be:

  • A user of the system.

  • An entity, such as another system or a database, that resides outside the system.

For example, in the Adventure Works Cycles scenario, some of the actors are sales representatives, sales managers, customers, and production clerks.

The roles played by actors explain the need and outcome of a use case. By focusing on the actors, the design team can concentrate on how the system will be used instead of how it will be developed or implemented. Focusing on the actors helps the team to refine and further define the boundaries of the system. Defining the actors also helps to identify potential business users that need to be involved in the use case modeling effort.

When looking for actors, ask the following questions:

  • Who uses the system?

  • Who starts the system?

  • Who maintains the system?

  • What other systems use this system?

  • Who gets information from this system?

  • Who provides information to the system?

  • Does anything happen automatically at a preset time?

  • Who or what initiates events with the system?

  • Who or what interacts with the system to help the system respond to an event?

  • Are there any reporting interfaces?

  • Are there any system administrative interfaces?

  • Will the system need to interact with any existing systems?

  • Are any actors already defined for the system?

  • Are there any other hardware or software devices that interact with the system and that should be modeled during analysis?

  • If an event occurs in the system, does an external entity need to be informed of this event? Does the system need to query an external entity to help it perform a task?

Defining the interactions between the actor and the system

After you have identified the system and the actor, you need to describe the interaction between them. You need to create one use case for each interaction. Describe only those interactions that are important to the business challenge and the vision statement.

Determining the system boundary

One of the more difficult aspects of use case modeling is determining the exact boundary of the system to be built. People who are new to use case modeling might find it difficult to determine whether certain actors should be part of the system.

To define the boundary of the system, the team should try to answer the following questions:

  • What happens to the use cases associated with that actor?

  • Who or what interacts with those use cases now?

  • What if you find new requirements? Will these requirements be a part of the system?

  • Are these requirements necessary for this system?

  • Are these requirements something this system would logically do?

  • Can these requirements be handled by one of the current actors?

  • Are these requirements something the customer/user would expect the system to do?

Figure 2.7 depicts an example of a diagram of a set of use cases.

Figure 2-7 Example of a diagram of a set of use cases
Figure 2-7. Example of a diagram of a set of use cases

Typically, an actor is shown as a stick figure, a single use case is shown as an ellipse, and a set of cases are enclosed in a box, which represents a system.

What Are Usage Scenarios?

Use cases describe the high-level interactions between an actor and a system. The use cases grouped together describe a workflow process in detail. Usage scenarios provide additional information about the activities and task sequences that constitute a process. Usage scenarios document the sequence of tasks.

Usage scenarios describe in detail a particular instance of a use case. It takes many usage scenarios to document a use case completely. Whereas use cases are diagrams, usage scenarios are narratives.

Usage scenarios depict objects in a workflow process. Objects are something that are affected by the system, something that affects the system, or something that a system needs to be aware of to function properly. For example, objects in a training center include the customer, the training course, and the sales representative. Objects provide a view of the characteristics and behavior of elements in the problem domain that is addressed by the business challenge. In the conceptual design phase, you create usage scenarios that depict the objects in the problem domain.

In addition to objects, usage scenarios depict exceptions. Exceptions are atypical events or alternate task sequences to meet the use case. An example of an exception condition for entering information for a new customer into the training center contact system is when the system is down and the sales representative must use other means to take customer information.

Tips for handling exceptions in a system include:

  • Ask “what if” to capture exceptions to the work task or step.

  • Determine the relative probability of each exception.

  • Discuss how the exception is currently handled and any alternative methods.

  • Incorporate handling of high-probability exceptions into the design of the solution.

When you develop usage scenarios, you might identify a task that must be treated as a use case. For example, in the “Register customer for course” use case, you might determine that the task sequence “Process customer payment” is a high-level use case that is part of the workflow process and has several usage scenarios.

Consequently, each usage scenario for “Register customer for course” ends with “Entering course number.” Then you create all relevant usage scenarios for the new “Process customer payment” use case.

You identify the use cases that correspond to the workflow process and then develop usage scenarios that describe the task sequences for each use case. From the usage scenarios, you can determine the current state requirements.

Why Create Current State Usage Scenarios?

After you identify a use case, you can determine the different usage scenarios that can occur for the use case. You then use the information that you gathered from users to describe the different usage scenarios possible for the use case. Creating a usage scenario helps you determine if you gathered the appropriate level of information. Gathering the required amount of information for describing the current state is part of the iterative aspect of gathering and analyzing information.

You can create scenarios for both the current and the future states of the business environment. The current state scenario depicts how business activities are currently conducted; the future state scenario presents the activities as the business wants them to be. For both states, the scenario emphasizes business processes, information, users, and tasks.

In some situations, full scenarios need be developed only for use cases that are known to have many exceptions or dependencies. This allows the project team to balance costs against the potential benefits. Use cases and scenarios should be developed iteratively, and can be discovered or continued during development work on the initial set of use cases.

Benefits

Although there are various ways to analyze current work processes, use cases and usage scenarios are especially effective in modeling the process. Creating use cases and scenarios provides the following benefits:

  • By measuring productivity levels of the current system, the team can determine whether the new system has achieved usability goals.

  • The team can identify the problems in the system and what works in the system.

  • The team might discover that the problems perceived by users are different from the actual problems and their causes. The team can then concentrate on the real problems.

Creating a usage scenario

To create a usage scenario, you need to perform the following tasks:

  • Determine the preconditions for the usage scenario, specifying information or conditions that must exist before a scenario can be executed.

  • Identify the postconditions for the usage scenario, which identify the work or goal completed during the task sequence.

  • Break the activity into discrete steps.

  • Identify exceptions that might occur for any step. You might need to develop usage scenarios for these exceptions.

  • Identify the requirement that this particular usage scenario addresses, for tracking and traceability.

  • Identify the source for this usage scenario, for further discussion and clarification.

Following is an example of how you can derive a usage scenario from the Adventure Works Cycles use case:

Use case title: Customer requests product literature

Abbreviated title: Customer requests product literature

Use case ID: UC05.1

Requirements ID: 14.1

Description: Customer wants to obtain information for a product. The customer is able to view a copy online, print a copy, or request a hard copy to be delivered by mail.

Actors: Customer

Preconditions:

  • Customer has Internet access.

  • Customer has browsed to the Adventure Works Cycles Web site.

  • Customer has clicked Browse Product Descriptions.

  • Product information exists in the database, and the site is working properly.

Task sequence

Exceptions

Customer scrolls to desired product.

Product is not in current view.

Customer selects product by clicking on product graphic or details.

Customer views basic product information (name, description, image, in-stock status, price, item number).

Any piece of data is not available.

Customer clicks Need Complete Specification?

Customer views full product specification online (UC05.1.3).

Customer chooses printable version (UC05.1.2).

Customer clicks Mail Me Full Brochure (UC05.1.1).

Customer is not in database. Customer completes and saves profile.

Customer is in database. Customer confirms address.

Customer clicks Submit.

Submit process fails.

Customer browses away from product specification.

Postconditions: The request to receive the full specification by mail is complete and saved in the database.

Unresolved issues: How should saved requests best be queued for fulfillment?

If submit process fails three times, what process should be invoked?

Authority: Mike Danseglio

Modification history:

Date: November 6, 2002

Author: Heidi Steen

Description: Initial version

NOTE
Although this chapter teaches you how to create a detailed usage scenario, you would not create such a detailed usage scenario until the conceptual design phase. This example is used to teach you the technique of how to create a usage scenario.
How to Refine Requirements

As mentioned earlier, when you analyze information with use cases and usage scenarios or by using any other tool, you also refine the list of requirements. When you create more detailed use cases, you can differentiate between requirements, wants, and constraints, and also identify any hidden requirements from the gathered information. The requirements and wants will eventually define the features of the completed solution. At this stage, the team only describes, organizes, and prioritizes the requirements and wants. Later, in the process of developing the product, the development team will determine the features of the product.

NOTE
Refining requirements typically happens during the envisioning phase and the conceptual and logical design processes of a project life cycle. You create a first level of requirements during envisioning, and then further refine them to eventually derive the feature set and determine which requirements are in scope for this version of the product. Once you progress to physical design, any change in requirements will cause the project to re-iterate. Therefore, you should get an agreement from the customer about the requirements during the conceptual and logical design.
Requirements and wants

Requirements indicate the characteristics of the process that are essential for meeting the goals of the business. Wants are important but not essential to achieving the business goals or resolving the business challenge. Wants are based on the actual day-to-day experiences of people. However, they represent an ideal state of how people would like things to be in the business. As you discuss the requirements and wants with the customer, some wants might become requirements, and some requirements might become wants.

Constraints and assumptions

Constraints indicate the parameters to which the final business solution must adhere. They are aspects of the business environment that cannot or will not be changed. Often, these constraints become design goals for the application. If constraints are not identified properly, the project team might design a product that cannot be deployed within the business.

Examples of possible constraints that you should document include:

  • Budget limitations

  • Characteristics of existing or supporting systems

  • Network system architecture

  • Security requirements

  • Operating systems

  • Planned upgrades in technologies

  • Network bandwidth limitations

  • Maintenance and support agreements and structures

  • Knowledge level of development or support staff

  • Learning limitations of users

Assumptions are identified as you talk to the customer and analyze the data you have gathered. Assumptions and constraints are very similar. An example of an assumption is “We will use Microsoft .NET as the basis of the new solution.” In this case, the team is assuming that it will build the solution by using .NET.

A constraint prevents you from accomplishing something; an assumption is a piece of knowledge that you possess when beginning the project—it might be good or bad.

Hidden requirements

It is especially important to identify hidden requirements. Imagine completing the design and then learning about a merger your client will go through in the near future, meaning that you need to consider interacting with the systems of the acquired company. Your customers might feel the need to withhold this information, not realizing the impact to the project. Some examples of hidden requirements are:

  • Interoperability with peer networks and the Internet

  • No firewall to enable barrier-free connectivity

  • Mergers, acquisitions, and other changes in the business constituency

  • Meeting regulatory requirements that come into being after the project is in process

  • Maintenance of the deployed system after the expiration of the stipulated period

  • Personnel changes that might affect the project or the team


Activity: Gathering and Analyzing Information

In this activity, you use what you learned in the lessons to work through information gathering exercises.

Exercise 1: Preparing for an Interview

You will be interviewing the human resources manager at Adventure Works Cycles to gather information about their current system. To prepare, you want to develop a series of questions to ask during the interview. What questions would you formulate for the interview?

After you have completed your list, view the document named “Interview with the Human Resources Manager” in the \SolutionDocuments\Chapter02 folder on the CD to determine whether there are any other questions you would ask during the interview or in a subsequent interview with the human resources manager.

Some possible questions are:

  • How many employees does human resources have to account for currently?

  • How are the employees classified (full time versus part time versus contractors)?

  • How many new employees does the company anticipate it will hire in the next fiscal year?

  • What are the shortcomings of the current solution that you would like to see addressed in the new solution?

  • Describe how the hiring process works today.

  • Describe how the review process works today.

  • Describe how the usage of benefits is analyzed today, and how the results of the analysis are used to make future decisions about benefits.

  • How many different documents do you store for each employee? For each employment candidate?

  • What categories do you use to manage employees and candidates (such as skills, levels, industry keywords, or specialities)?

  • Are all documents currently in Microsoft Word format? If not, what other formats are they in?

  • What are the various storage areas for your documents? (List all network drives and databases, including server names.)

  • Who has the authority and ability to view, change, or enter employee and candidate records?

Exercise 2: Deriving Use Case Statements for the Sales Automation Project and for the Web Enhancement Project

Your team has completed most of the information gathering for the Adventure Works Cycles project. Using the interviews for the territory sales manager, the information services manager, the vice president of production, and the Web customer, and the shadowing report for the sales associate, derive as many use case statements as you can. Derive only the use case statements here. You will complete the full usage scenario in a later exercise. Develop use cases that follow the Actor-Action-Object format: An example of a use case statement would be “Sales Representative views product information.”

Use Visio to create a UML use case diagram.

To see one possible solution for this exercise, see the Visio document named C02Ex2_Answer.vsd in the \SolutionDocuments\Chapter02 folder on the CD.

Exercise 3: Developing Draft Requirements from Initial Information Gathering

You have started the initial gathering of information by talking to people in the Sales department, the network adminstrator, and the project sponsor. You also have a beginning collection of use cases. Identify phrases in the interviews or use cases that might eventually be requirements.

Use the Microsoft Excel document named C02Ex3.xls in the \SolutionDocuments \Chapter02 folder on the CD to record your work. Use the Original Tab to write down the actual phrases from the interview. To guide your work, three examples have been given in the Revised tab. To see one possible solution, see the document named C02Ex3_Answer.xls in the \SolutionDocuments\Chapter02 folder on the CD. The Original Tab contains the phrases from the interviews that are potential requirements. The Revised Tab shows revised phrases starting with the Sales Manager comments. The phrases have also been reorganized into related groups. This document also shows questions that could be derived from the first three potential requirement statements from the Sales Manager.

Exercise 4: Developing a Usage Scenario

You need to document the usage scenario for the use case “Customer requests product literature.” You will first need to define the actor, the objects, and the system. You will then need to complete the precondition and postcondition. Next, complete the task sequence and note any exceptions. Use the information in the interview and shadowing documentation, in addition to your own experience with developing software and completing online purchases.

Use the Excel document named C02Ex4 in the \SolutionDocuments\Chapter02 folder on the CD to record your work. To see one possible solution for this exercise, see the document named C02Ex4_Answer in the same folder on the CD.


Summary

  • Gathering and analyzing information are steps that you perform throughout the Microsoft Solutions Framework (MSF) Process Model.

  • Gathering and analyzing are iterative collaboration processes between you and your customer.

  • Some techniques for gathering are interviewing, shadowing, user instructions, and prototyping.

  • Analysis involves creating use cases and usage scenarios, draft lists of requirements, actors catalogs, and business rules catalogs.

  • Modeling represents another method of describing business processes. Models indicate relationships and behavior among business processes, in addition to the tasks that make up the processes.

  • ORM is a fact-oriented method for analyzing information at the conceptual level.

  • UML is a standard modeling language that you use to model software systems of varying complexity.

  • UML views depict several aspects of a software system by using UML diagrams.

  • UML diagrams depict various views of a system.

  • Creating use cases involves:

    • Identifying the system

    • Identifying actors

    • Defining interactions between the system and the actors

    • Determining the system boundary

  • Use cases describe the interactions between an actor and a system and are used to describe a workflow process.

  • Usage scenarios provide information about the activities and task sequences that constitute a process.

  • After you begin analysis, you need to eliminate redundancies to determine the information that is most important to the business and the business challenge.

  • You need to distinguish between requirements and wants when you synthesize the information from both the business and user perspectives.

  • Constraints indicate the parameters to which the final business solution must adhere and indicate the aspects of the business environment that cannot be changed.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What is the difference between the interviewing and focus-group techniques of gathering information?

  2. When should you use prototyping instead of shadowing to gather information?

  3. How do you identify the most effective information gathering technique for a project?

  4. What is the purpose of creating use cases?

  5. What is an actors catalog?

  6. What is ORM?

  7. What is UML?

  8. What are the purposes of the various UML views?

  9. What is an actor in a use case?

  10. What is the purpose of a usage scenario?

  11. What are the steps in creating a usage scenario?


Chapter 3: Envisioning the Solution

Chapter 3
Envisioning the Solution
About This Chapter

The success of a project depends on the ability of the project team members and the customers to share a clear vision of the goals and objectives of the project. You define the vision of the project during the envisioning phase of the Microsoft® Solutions Framework (MSF) Process Model. In the following four lessons, you will learn about the envisioning phase and the roles and responsibilities of team members during this phase. You will also learn how to define the vision of the project and analyze risks associated with the project.

Before You Begin

To complete the lessons in this chapter, you must

  • Understand the MSF Process Model.

  • Understand techniques for gathering and analyzing information.


Lesson 1: The Envisioning Phase

The envisioning phase is the period during which the team, the customer, and the sponsors define the high-level business requirements and overall goals of a project. The main purpose is to ensure a common vision and reach consensus among the team members that the project is both valuable to the organization and likely to succeed. During envisioning, you should focus on creating clear definitions of the problem. The envisioning phase culminates in the vision/scope approved milestone.

After this lesson, you will be able to

  • Describe the purpose of the envisioning phase.

  • Describe the roles and responsibilities of team members during the envisioning phase.

  • List the guidelines for setting up the project team.

  • Describe the deliverables of the envisioning phase.

Estimated lesson time: 5 minutes
Purpose of Envisioning

The first phase of the MSF Process Model is envisioning. During this phase, the team creates an overview of the business problem to be solved and how that problem relates to the business, the customers, and the environment. This helps the team get a clear vision of what the team must accomplish for its customers. For a successful project, you need to know what the customer wants to achieve with the solution.

Figure 3.1 indicates how the envisioning phase fits into the overall MSF Process Model.

Figure 3-1 Where are you in the MSF process?
Figure 3-1. Where are you in the MSF process?

For example, consider an organization that wants you to develop its Web site. “We need a Web site” is a good reason but not a good vision for the Web site project. To create the most effective solution, the team should identify the goals that the organization wants to achieve by building and deploying this Web site. In addition, the team needs to determine whether the Web site has any unique characteristics that the organization can take advantage of for maximum benefit. Does the organization want a complex site, or a site that supports a growing number of users? Perhaps the organization needs to plan for both complexity and scalability? The team should consider the intended market and expected volume of site visits. Another consideration for the team is the organization’s brand and projection of image in the marketplace.

Envisioning serves many purposes. The team uses the envisioning phase to:

  • Identify the goals and constraints of the project.

  • Answer feasibility questions, gain approval from key stakeholders, and acquire a common set of expectations from everyone involved.

  • Form the basis upon which team members build the solution later in the project.

  • Define the scope of the project, which helps in the detailed planning effort of the next phase.

  • Estimate the resources that are required to develop the solution.

  • Identify and schedule the major milestones for the project.

Roles and Responsibilities of the Team Members

Although the project team works as a single unit to achieve the vision/scope approved milestone of the envisioning phase, each role has a specific focus during each phase of the project life cycle.

Figure 3.2 shows the roles for the project team during the envisioning phase.

Figure 3-2 The MSF Team Model
Figure 3-2. The MSF Team Model

The MSF Team Model specifies six roles for a project in the envisioning phase:

  • Product management. The responsibility of product management includes ensuring that the team addresses the customer requirements. The product management role collaborates with the program management role and drives the effort to establish a shared project vision. To accomplish this goal, product management studies and analyzes the business problem, business requirements, project vision, business goals, and user profiles.

  • Program management. Program management establishes project design goals, defines success factors and metrics, articulates the solution concept, and sets up the project infrastructure.

  • Development. The development team provides feedback to the team on the technical implications of developing the product and on the feasibility of the solution concept.

  • User experience. The user experience team analyzes the performance needs and support issues of users and considers the product implications of meeting those needs.

  • Testing. The testing team provides feedback to the team on the quality goal for the solution and specifies the actions that will be needed to achieve that level of quality. The testing team then applies decisions about the quality goal to testing strategies and acceptance criteria that will be used to measure quality.

  • Release management. The release management team identifies what will be required to deploy the product, how the product will be deployed, when it will be deployed, and whether deployment will require additional infrastructure.

How to Form a Project Team

One of the tasks that you perform during the envisioning phase is setting up the team. It is important that the project team members are competent and can perform the tasks necessary for creating the solution. The task of forming a team brings together the skills that are essential for completing the project successfully. When identifying appropriate team members for a project, you need to consider the following for each member:

  • Knowledge. Represents the information that an individual must possess to perform the job competently, such as knowledge of computer science fundamentals.

  • Skills. Represent the behavior or abilities making up the competency and correspond to the skills of the team member, such as mathematical logic or artistic ability.

  • Performance level. Represents the ability and the expected results from capable execution. For example, you might choose a person who meets deadlines consistently while meeting the quality requirements for the assigned task.

In addition to considering each individual’s capabilities, there are some practical considerations to selecting team members. These include:

  • Availability of the team members.

  • Cost or project budget.

  • Security clearance of the team members.

How to Prepare the Deliverables of the Envisioning Phase

Although there are interim milestones during the envisioning phase, such as formation of the core team, creation of the draft version of the vision/scope document, and creation of the draft version of the risk assessment document, there are three major deliverables of the envisioning phase. These are as follows:

  • Vision/scope document. The vision/scope document describes the project goals and constraints. It outlines the product being developed, the needs it will meet, its features, and an initial schedule.

  • Project structure document. The project structure document outlines the project organization structure and describes the project management process. It outlines who is responsible for each role in the MSF Team Model and identifies the team lead for each role.

  • Risk assessment document. The risk assessment document provides an initial identification and analysis of risks associated with the project, along with mitigation and contingency plans to help the team in managing risks.

Depending on the extent of the project, additional deliverables for the envisioning phase can include:

  • An initial list of testable features

  • Preliminary requirements and use cases

  • Preliminary architecture

  • A graphical user interface (GUI) storyboard

In addition to the documents that are shared with the customers, the project team also develops the following documents for its internal use:

  • An actors catalog

  • A business rules catalog

  • A glossary of terms

NOTE
You learned about these documents in Chapter 2, “Gathering and Analyzing Information.”


Lesson 2: Creating a Vision/Scope Document

The final milestone of the envisioning phase is an approved vision/scope document. In this lesson, you learn how to create a vision/scope document for a project.

After this lesson, you will be able to

  • Describe the contents of the vision/scope document.

  • Create a problem statement.

  • Create a vision statement.

  • Create user profiles.

  • Define the project scope.

  • Create a solution concept.

  • Identify project goals.

  • Validate the vision/scope document.

Estimated lesson time: 20 minutes
What Is the Vision/Scope Document?

The vision/scope document is one of the final deliverables of the envisioning phase. This document contains the goals and constraints of a business solution. The vision/scope document represents the first agreement among everyone involved in the project. It guides the team to the high-level achievement of specific business goals. Initially, the team relies heavily on the vision/scope document to decide whether to go ahead with the project. After the project is approved, the team uses the vision/scope document to structure its planning efforts throughout the rest of the project.

To create the vision/scope document, the team conducts more interviews with customers and stakeholders, analyzes the high-level use case of the business to a lower level of detail, and identifies assumptions and constraints in the organization. Remember that you continue to gather and analyze information during all phases of the MSF process.

The vision/scope document must focus on understanding and defining the problem. The contents of the vision/scope document include the following:

  • Problem statement

  • Vision statement

  • User profiles

  • Scope of the project

  • Solution concept

  • Project goals

    • Business goals

    • Design goals

  • Critical success factors

  • Initial schedule

How to Create the Problem Statement

A problem statement is usually a short narrative describing the issues the business hopes to address with the project. It relates primarily to the current state of business activities. The more accurately the problem statement is defined, the more you are able to gauge its impact on the business needs of the organization.

Because the aim of any project is to solve a problem, the understanding of the problem determines the design of the solution. A problem statement outlines the business problem that the team is trying to solve. This statement must provide sufficient information about the business problem. A new team member can use the problem statement and the rest of the documentation to put the project into context.

Following are some examples of problem statements:

  • Telephone operators cannot deal with the high number of calls because of the time it takes them to navigate through and interact with the current application.

  • The organization needs to eliminate the ongoing costs associated with earlier versions of hardware and software.

  • Users need clear directions from the system to resolve errors when they occur.

  • We need to increase the number of online registrations by making our Web site easier to browse.

How to Create the Vision Statement

The purpose of the vision statement is to establish a common vision and reach consensus among the team members that the project is valuable to the organization and is likely to succeed. The vision statement also ensures agreement about the future of the project among the entire team.

Characteristics of a vision statement

A vision statement must be short enough to be remembered, clear enough to be understood, and strong enough to be motivational. A good vision statement has the following five characteristics:

  • Specific. A vision statement should be specific and include the ideal state of the business problem so that the end result is meaningful.

  • Measurable. By creating a vision statement that is measurable, the project team can determine the success of the project and whether it met the business goals.

  • Achievable. Given the resources, the time frames, and the skills of the team members, the vision statement should be achievable. An achievable vision statement motivates the team to complete the project.

  • Relevant. The vision statement should relate to the business problem being addressed. If the vision statement is not relevant, the project team might discover that they are trying to solve a business problem that does not exist, and the project might lose sponsorship.

  • Time-based. The vision statement should clearly indicate the estimated time frame for the delivery of the solution.

NOTE
The above qualities of the vision statement are also referred to as SMART characteristics, each letter of the acronym standing for one of the five characteristics.
Examples of vision statements

Consider an organization whose e-commerce Web site is experiencing much lower online sales than the Web sites of its competitors. In the envisioning phase of solving this business problem, you might use the following vision statement:

Before the end of the year, we will become the top revenue-producing company in the industry by increasing our online sales.

Consider another example. An online library has a huge catalog of books, magazines, articles, white papers, and journals. The library wants its subscribers to be able to track all items in the catalog that they want to be able to find again, regardless of which computer they used to access the Web site. A vision statement for such a project might be as follows:

During the current fiscal year, we will enable all our subscribers to create bookmarks to selected pages from our Web site for access from any computer or device the end user might use.

Note that both vision statements have all five SMART characteristics. Both vision statements are specific, measurable, achievable, relevant to the business problem, and have an estimated time of availability.

How to Create User Profiles

A business solution is used by a set of customers. Before getting much further into the design of the solution, it is important to understand the users for whom you are developing the solution. To capture a clear description of each user, the team creates user profiles. User profiles identify the users so that the team can assess the expectations, risks, goals, and constraints of the project.

When creating user profiles, take into account the following considerations:

  • Goals. An end-user’s goal would include a list of the things that the user expects to accomplish by interacting with the product.

  • Constraints. It is important to understand factors that might affect a user’s ability to use the solution, such as hardware and software. For example, for certain solutions, you might need to consider the operating systems that are in use by all kinds of users. There is no reason to design a solution for one specific operating system if the users are using several different operating systems in the organization.

  • Support issues. User profiles also contain information about the problems that users might have had with similar products. This information will help you plan for support features that users might require while using the new product.

  • Global users. Determine whether the solution will support various cultures and localization needs.

  • Geographical boundaries. Describe user locations, including geographical and physical locations, the number of users at each site, and the bandwidth and usage of the network links between sites.

  • Information flow between users. Describe the communication that occurs between users, including the types of communication, their importance, and the volume of data that flows between the various user communities.

  • User functions. Describe the tasks that the user performs, such as “completes customer profile,” and “edits customer order and details.” This information will be developed into the use cases.

  • Organizational communication. Some organizations have rigid hierarchical divisions that restrict how, why, and when individuals can communicate across the lines of hierarchy. In such a situation, you need to accommodate these restrictions. Document the composition and boundaries of the organizational hierarchy.

  • Decision-making policies. Describe decision-making policies that directly influence the effective implementation of the proposed solution.

  • Additional factors. You should also document the availability and usage of resources at each user location, and identify any additional factors, such as incompatible protocols, network operating systems, and applications that might affect the success of a geographically based solution.

How to Define the Scope

One of the critical factors in the success of a project is clearly defining the scope of the project. Scope defines what will and will not be included in a project. The scope uses the project vision as defined in the vision statement and incorporates the constraints imposed on the project by resources, time, and other limiting factors. The scope is defined by the features that the customer considers mandatory in the solution. The team must address these features in the first release of the solution. While defining the scope, the team might decide to wait until future releases of the project to incorporate functionality that is not directly related to the core features of the solution. The features that are considered out-of-scope should be documented in a next-version or future-project document.

To begin defining the scope of the project, you continue to develop the high-level use cases that you created for analyzing the business and recording high-level business requirements. For the purpose of defining the scope, you identify the areas in the use case that directly impact the business challenge and address the business. You might need to prioritize the business challenges and identify those that will be dealt with in future versions of the solution. You can typically draw a box around the relevant parts of the high-level use case and derive a new use case diagram that you will subsequently use in the project.

Figure 3.3 shows the use case diagram that represents a part of the business. The scope of the project is enclosed in a box.

Figure 3-3 Use case diagram showing the scope of the project
Figure 3-3. Use case diagram showing the scope of the project

Figure 3.3 shows only the use cases that are now within the scope of the project. To understand what is not within the scope of the project, refer to the Microsoft Visio® document named AWC Use Cases in the \SolutionDocuments\Chapter03 folder on the companion CD.

Refining requirements

An important activity in defining the scope of a project is refining the requirements. Remember that you continue to analyze and refine requirements during both the envisioning and planning phases. During the envisioning phase, you analyze the gathered information and identify specific phrases that will lead to a requirement statement. You then work through those phrases to express the requirements in the language of “what the business needs and wants.” You can also begin by collecting customer language directly from interviews and other sources. Consider the following high-level requirement:

The system must support localization to correspond to the end user’s culture.

After refining this requirement during the envisioning phase, you have the following requirement:

The system must have procedures for globalization, localization, and accessibility.

The tradeoff triangle and priorities

Defining the scope means balancing the needs of a diverse set of end users and considering other priorities prescribed by the customer. Several variables might affect the potential success of the project, including costs, resources, schedule, functionality, and reliability. The key is to find the right balance between these variables.

The tradeoff triangle in Figure 3.4 shows the three most critical elements in setting the scope of a project. The tradeoff triangle dictates that resources, schedule, and features are three interconnected elements of any project, and that constraining or enhancing one or more of these elements requires tradeoffs.

Figure 3-4 The tradeoff triangle
Figure 3-4. The tradeoff triangle
Role of versioning

While defining the scope of the project, you identify the requirements that will be addressed by the various versions of the solution. During envisioning, you define which use cases and then which related candidate requirements will be handled by the solution.

The features of the solution correspond to requirements. The decision to include a feature of the solution depends on how the feature relates to the business problem selected in the first version of the use case and on how many users are affected by the feature. You should give highest priority to features that will affect the greatest number of users.

After identifying and prioritizing business problems, you can focus on the use cases related to the highest priority problem. With each version, focus on the set of features that addresses the most urgent problem and affects the maximum number of users. Eliminate the features that are required by smaller numbers of users and those that address other problems. This enables you to define the scope of the solution for each version and for the entire project.

More Info
Remember, the requirement statements develop into feature lists during the planning phase, near the end of logical design. Chapter 5, “Creating the Logical Design,” describes the logical design stage.
Role of assumptions and constraints

The scope of the project is also affected by the assumptions and constraints made by the business and the customers. Typically, assumptions add to the constraints of the project. Examples of assumptions include:

  • We will use the Microsoft .NET Framework for development.

  • We will use two development teams.

  • We will have both OLAP and OLTP systems.

Constraints indicate the parameters to which the final business solution must adhere. They are aspects of the business environment that cannot or will not be changed. Often, these constraints become design goals for the application. If constraints are not identified properly, the project team might design a product that cannot be deployed within the business.

Examples of possible constraints that you should document include:

  • Budget limitations

  • Characteristics of earlier supporting systems

  • Network system architecture

  • Security requirements

  • Operating systems

  • Planned upgrades to technologies

  • Network bandwidth limitations

  • Maintenance and support agreements and structures

  • Knowledge level of development or support staff

  • Learning limitations of users

List the constraints that affect the business challenge and the potential solution. The project team uses these constraints to design a solution that optimizes the requirements and conforms to the parameters established by the constraints.

Role of estimates

Depending on the assumptions and constraints of the project, you can provide estimates for developing the solution. Estimates include time, effort, and cost. You estimate the time it will take to build the solution, the resources required to build the solution, the cost of resources, and their effort.

In addition, you might want to add disclaimers and contractual details in the estimates section. This helps you clarify the extent of your responsibilities in the project.

Benefits of defining the scope

Some of the benefits of defining the scope of a project are as follows:

  • The scope enables the team to focus on identifying the work that must be done.

  • The scope enables the team to divide large and vague tasks into smaller and more specific tasks.

  • The scope helps you specify the features that will be in each release of the solution.

  • The scope includes defined feature sets and functions, which helps you to divide work among subcontractors or partners on the team.

  • The scope clarifies what the team is and is not responsible for in the current deliverable.

Revising the scope

During the envisioning phase, the project variables start to become apparent. However, the team can more thoroughly understand the project variables with the help of a more detailed planning process. At this stage of the envisioning phase, the team is likely to know project variables only at a basic level. Defining and balancing the project variables is an iterative process. As analyzing, prototyping, and planning activities proceed, the team might need to revise the scope to:

  • Incorporate a better understanding of user requirements.

  • Incorporate a change in business requirements.

  • Adjust the solution according to technical issues or risks.

  • Make tradeoffs among the project variables, such as resources, schedule, and features, because project variables have changed.

How to Create the Solution Concept

The solution concept outlines the approach the team will take to meet the goals of the project and provides the basis for proceeding to the planning phase. After identifying the business problem and defining the vision and scope, the team creates the solution concept that explains in general terms how the team intends to meet the requirements of the project.

Figure 3.5 shows a sample solution concept for the scope identified for Adventure Works Cycles.

Figure 3-5 Solution concept
Figure 3-5. Solution concept
Creating a business-oriented draft

The solution concept can serve as a business case. Because it focuses only on the concepts and not the details of the solution, it is not very technical. For the team to get approval and funding, the team should establish an executive sponsor who will use the vision/scope document to establish funding.

The solution concept includes a conceptual model of the system’s software and hardware architectures. The solution concept is the proposed method of addressing the issues identified as being in scope. The team must evaluate the various options and select the one that is the best for its particular situation. A team can then narrow the range of solution concept options to a few alternatives.

For example, in the case of an e-commerce Web site, the choices might include building an e-commerce site internally from the very beginning, employing an outside company to build one, or purchasing a commercially available solution. Similar issues exist for hosting the e-commerce Web site: Should the site be hosted on local servers or should the company use a service provider?

Elements of the solution concept

After the team has evaluated its options, it chooses a solution concept that best meets its needs, resources, and the time frame available for implementation. The solution concept includes the following elements:

  • Project success factors and acceptance criteria. These criteria include a checklist of requirements that must be satisfied before the solution goes into production.

  • Initial approaches to developing and delivering the solution. These approaches include sample scenarios for the site and methods for implementing the solution, the number of users who will use the new solution, and a complete list of project deliverables that will make the new product operational.

  • Initial description of functionality of the solution that will address the business problem.

NOTE
Creating user profiles and the solution concept need not be a linear process in solution design. These steps can be done in parallel.
How to Identify Project Goals

For a project to be successful, it is essential that you correctly identify the goals of the project. Project goals can be categorized as follows:

  • Business goals

  • Design goals

Business goals

Business goals represent what the customer wants to achieve with the solution. Business goals form the basis for determining the success criteria of the solution. The purpose of defining business goals is to clearly articulate the objectives for the project and to ensure that your solution supports those business requirements. The team needs to determine the best method for identifying the goals and agreeing on them.

Throughout the life of the project, the team makes tradeoffs among resources, schedule, and features. It is important that business goals are prioritized in a way that will allow the team to have a clear understanding about which ones the customer believes are most important, in case some of the goals cannot be achieved.

For an e-commerce project, business goals might include the following:

  • Expand the company’s geographic market beyond the current range of physical stores.

  • Expand the company’s demographic market to include younger consumers who have higher disposable incomes and who shop online with greater frequency than the current customer base.

  • Shorten the time to sell products by using more efficient online sites.

  • Integrate all suppliers worldwide by using a workflow process, and shorten the order placement and delivery cycle time.

Design goals

Design goals are similar to business goals in many ways. The difference is that design goals focus more on the attributes of the solution and less on what the solution will accomplish for the business. Design goals address not only what the team wants to accomplish but also what the team is not trying to accomplish with the solution. As with business goals, you need to prioritize design goals so that the team knows which goals must be accomplished, in case the project cannot achieve all of them.

Consider the case of an e-commerce Web site. Some of the design goals for the online shopping cart might include:

  • Improve the user experience by reducing page-download wait times to 5 seconds or less.

  • Limit dependency on connectivity with the server.

  • Reduce the time and level of effort required for a user to complete the online registration.

For the server-side online library’s server-side bookmark project, the design goals might include:

  • The service and all supporting applications must be localized for users worldwide.

  • The service must have an availability of 99.99 percent.

  • The service cannot lose data.

  • The service must permit access only by authorized users.

For designing the interface of a mobile application, some of the design goals might include:

  • Users must be able to easily input and retrieve information.

  • The application must be customized for the intended mobile device.

How to Validate the Vision/Scope Document

After creating an early version of the vision/scope document, the team reviews and modifies the document. The envisioning phase culminates in the vision/scope approved milestone. This milestone represents the point at which the project team and customer agree on the overall direction for the project, including the scope of the solution. This baseline version of the document is a project deliverable that is used in the subsequent phases of the project.

The vision/scope document is formally approved in a vision/scope meeting. The team validates the work done in the use cases, usage scenarios, and usage profiles with the appropriate stakeholders. (This validation is a process that will occur throughout the project.) By having the customer validate the completed work, the team prepares the customer to understand the tradeoffs that are made in defining the scope. The customer is also educated about the project and the team’s approach, creating a feeling of involvement that can greatly reduce difficulties in consensus and in future feature discussions.

The vision/scope meeting ensures that the team and the customer arrive at a shared understanding regarding how the proposed solution will address the business challenge and how it is applicable to the current business scenario, given the scope that has been defined.

This meeting is a mechanism for the team to share ideas and achieve a shared vision with the customer. This meeting also enables the customers to understand that the team is listening to them and actively involved in the project. The team uses this meeting to decide whether the project should proceed. The available resources and the potential gains may not be worth the total cost of the project. This validation step allows the team to redefine either the project solution or the resources and constraints.

By approving the vision/scope document, the members of the project team, the customer, and the key stakeholders agree on the following:

  • A broad understanding of the business needs that will be met by the solution

  • The vision of the solution

  • The design goals for the solution

  • The risks that might be incurred by undertaking the project

  • Project management’s initial concept of the business solution

  • The members of the project team

  • The mechanism for managing the project

The complete vision/scope document for the Adventure Works Cycles case study is available in the \SolutionDocuments\Chapter03 folder on the companion CD. The Adventure Works Cycles team has defined the scope of version 1 of this project to include the sales order and analysis, contact management, and Web ordering processes. This leaves solutions for product tracking, human relations documentation, and vendor data for future versions or projects.

If any issues are discovered by the team that will cause significant changes in the scope or deliverables of the project, you might need to follow up with discussions or another vision/scope meeting.


Lesson 3: Creating the Project Structure Document

The project structure document is a key deliverable of the envisioning phase. This lesson describes the purpose of the project structure document and itemizes the major sections within the document.

After this lesson, you will be able to

  • Describe the purpose of the project structure document.

  • Describe the components of the project structure document.

Estimated lesson time: 5 minutes
What Is the Project Structure Document?

The project structure document defines the approach the team will take to organize and manage the project. It describes the team’s administrative structure, standards and processes, and project resources and constraints. It serves as an essential reference for the project team members on how they will work together successfully.

The project structure document can be the formal documentation of the approach followed by each of the MSF team roles in the project. In addition, it documents the change management and configuration management approaches that will be implemented for the project. The level of detail in the project structure document depends on the project. If you expect a lot of changes during the later stages of the project, the project structure document should describe in detail how the team will handle the changes.

The change management section of the project structure document for a project named Scout is shown below. The two companies involved in the project used in this example are Adventure Works Cycles and Contoso, Ltd.

Change Management

The highest priority in Scout is the delivery of the first feature sets by the project completion date. (To be determined upon completion of the Project Master Plan. Estimated completion dates are September 1, 2003, for the Web site and November 15, 2003, for the sales automation project.) Therefore, change control procedures will be implemented as follows.

Change Control Process and Documentation Owners:

The program manager will be responsible for the change control process and documents. The application project manager for Adventure Works Cycles will be the primary decision maker in the change control process to manage changes requested by the customer.

Features by Version:

During planning, requirements gathering, and feature specification development, each feature will be identified as Critical V1.0, Want V1.0, Critical V2.0, Want V2.0, Critical V3.0, or Want V3.0.

Change Advisory Board:

The Scout Change Advisory Board is made up of members from Contoso, Ltd. (the development team and the program manager), and the Adventure Works Cycles team (project manager and developers), all of whom can make feature-set change requests. Other team members can take their feature set suggestions to any one of these individuals, who can then add the suggestions to the list for discussion at the next status meeting. If the individual deems the items critical, the individual can bring them up as critical issues and start the evaluation prior to the next status meeting.

Feature Evaluations:

The feature definition and its effect on the design, its effect on the solution, its value to version 1.0 (or any other version), and its risk will be evaluated by the team.

Feature Tradeoffs:

Features will be compared to other features, and any possible tradeoffs will be determined.

Resource Tradeoffs:

The tradeoff triangle will be reviewed and the appropriate element (resource or feature) will be added or deleted. (The schedule is fixed.)

Resolved Feature to Design:

After a feature is resolved as Critical V1.0, V2.0, or V3.0 or Want V1.0, V2.0, or V3.0 and resources are added or other features are deleted or reduced, the features enter the appropriate point in the design process. The budget and contract will be adjusted. (If Adventure Works Cycles decides that the schedule is worth adjusting for a feature, they can request the schedule change, and appropriate changes to the contract, design, budget, and schedule can be made.)

Change Cutoff:

Both companies agree that once the scope complete milestone is 70 percent complete, any new features will be introduced only on the V2.0 or V3.0 lists.
Team role and responsibility

Program management is responsible for facilitating the creation of the project structure document. The key inputs are supplied by the team members.

Components of the project structure

There are three primary components of the project structure document:

  • Team and structure

  • Project estimates

  • Project schedules (early versions)

A project structure document is a tool for documenting the decisions made regarding the execution and management of the project, including:

  • Team and customer roles and responsibilities

  • Communication decisions

  • Logistical decisions

  • Change management decisions

  • Progress assessment decisions

What Are Team and Customer Roles and Responsibilities?

The roles and responsibilities section of the project structure document lists the names of the people involved in the project and their contact information, such as telephone numbers and e-mail addresses. In addition, this section describes the decisions regarding responsibilities of various roles in the subsequent phases of the project.

Decisions during the planning phase

During the planning phase, the team needs to make decisions to answer the following questions:

  • How will the project plans be developed?

  • In creating the project plan, how will the team use the knowledge and experience gained from the reviews of other projects?

  • Will the team have scheduled status meetings throughout the project?

  • How often will customer reviews occur?

  • How will the features be distributed among the various releases of the solution?

  • Who will identify the risks associated with the project and define contingencies?

  • What tools will be used to develop and track project plans?

  • Will the team have review meetings during the planning phase? Who will attend the review meetings?

Decisions during the developing phase

During the developing phase, the team needs to make decisions to answer the following questions:

  • With what groups, organizations, and third-party vendors will the team interact during the project? Who is responsible for creating and managing contracts with third-party vendors?

  • What is the role and responsibility of each team lead in the development work?

  • If different components in the solution are being developed by different teams, what are the roles and responsibilities of each of the component team leads in the project?

  • Will each component team be assigned a help desk, a user experience team, and a testing team?

  • What is the role of the executive staff in the project?

  • What is the role of subcontractors, if required, in the project? Who will select subcontractors and monitor their work?

What Are Communication Decisions?

The communication decisions section of the project structure document specifies the communication processes that the team will follow during the project. These processes apply to communication within the team and with customers. The team makes decisions to answer the following questions:

  • Who needs to be informed of the planning decisions?

  • How will the customers, stakeholders, and team be informed of the planning decisions?

  • What type of meetings will be held, where will they be held, and who will attend each type of meeting?

  • Who will produce the agenda of the meetings?

  • Who will facilitate the meetings?

  • Who will prepare and distribute the minutes of meetings?

  • Who must be informed of the project’s progress, and how will they be informed?

Decisions regarding project files

Typically, a file is maintained for every project in an organization. This file contains information such as contracts, schedules, and plans. In the project structure document, the team decides what information will be maintained in the project files. Some of the decisions that must be made regarding the project file include:

  • What information will be included in the project files, such as project specifications, schedules, plans, outstanding issues, contracts, and so on?

  • Who will create and maintain the project files?

  • Who can access the project files?

  • Who will keep the project files after the project is complete, and for how long will they be kept?

Decisions regarding post-implementation reviews

Post-implementation reviews are an important part of a project. They help you evaluate whether the project was a success and identify the support you need to provide. Some of the decisions that must be made regarding post-implementation reviews include:

  • When will the post-implementation review be conducted, and who will attend it?

  • What subjects will be addressed during the post-implementation review?

  • What information will be collected during the life cycle of the project to facilitate the post-implementation review? Who will collect this information?

What Are Logistical Decisions?

The logistical decisions section of the project structure document lists decisions made regarding the development of the solution. The team makes decisions to answer the following questions:

  • What development practices will be used for the project? Some possibilities include:

    • Development methods such as product specification checks and a zero-defect checklist

    • Testing methods

    • Documentation methods

    • Marketing methods

  • Who will define the content for the product specifications? Who will use the product specifications during the project, and how will they use the specifications?

  • What are the tools that will be used to define the solution features?

  • How will completion criteria for the product specifications be determined?

  • Who will provide the team with any updates to the product specifications?

  • What specifications will be provided to each of the third-party vendors working on the project? Who will create these specifications?

  • How will zero-defect methods be defined and implemented for the project?

  • Who will estimate the effort and time required for the project? What is the basis for this estimation (personal experience, post-implementation reviews, and so forth)?

  • Who needs training in the technologies and skills supported by the solution, such as project management training? Who needs training on the solution during the planning phase?

What Are Change Management Decisions?

The change management decisions section of the project structure document covers the processes the team will follow to handle any changes in the project. Some of the decisions that are made regarding change management include:

  • How will you define change on the project (for example, a change in schedule or an increase in project cost)?

  • What is the release date? Who will determine the release date, and how will it be determined? What will the basis be for determining the release date?

  • Who will define the change management process that will be used?

  • How will proposed changes be identified and tracked? Who will track this information?

  • How will you assess the impact of a change? How much deviation are you willing to accept before major rescheduling?

What Are Progress Assessment Decisions?

The progress assessment decisions section of the project structure document covers the processes the team will follow to track and evaluate the progress of the project. Some of the decisions that are made regarding progress assessment of the project include:

  • How will the progress of the project be assessed? What information will be collected to measure progress?

  • How will progress information for each task be obtained from team members? How often will this information be collected?

  • How often will group schedules be updated? How often will the master project schedule be updated?

  • Who will identify and assess the effect of each variance?

  • Who will be involved in developing adaptive actions? Who will recommend and approve adaptive actions? How will you track the effectiveness of these actions?

  • How will any outstanding issues be documented, tracked, and monitored?

  • What criteria will be used to define exceptions for exception reporting? Who will be involved in assessing and resolving the exceptions?

  • How will problems and issues be resolved between different teams? If a problem or issue cannot be resolved between teams, will the issue be escalated? If so, who will escalate it?


Lesson 4: Analyzing Risks

Risk is the possibility of a loss. The loss could be anything from the diminished quality of a solution to increased cost, missed deadlines, or project failure. MSF recommends that project risk be assessed continuously throughout a project. In this lesson, you will learn about analyzing risks and creating a risk document for the project.

After this lesson, you will be able to

  • Describe the MSF risk management process.

  • Identify the contents of a risk assessment document.

  • Identify the risks for a project.

Estimated lesson time: 10 minutes
What Is the Risk Management Process?

Risks arise from uncertainty surrounding project decisions and outcomes. An essential aspect of developing a successful solution is controlling and mitigating the risks that are inherent in a project. Most individuals associate the concept of risk with the potential for loss in value, control, functionality, quality, or timeliness of completion of a project. However, project risks also include the failure to maximize gain in an opportunity and uncertainties in decision making that can lead to a missed business opportunity.

The MSF risk management process, as shown in Figure 3.6, is a proactive approach that the team practices continuously throughout the project. The team continually assesses what can go wrong and how to prevent or minimize any loss. MSF advocates tracking risk by using a formal risk assessment document and prioritizing risks.

Figure 3-6 MSF risk management process
Figure 3-6. MSF risk management process

The MSF risk management process defines six steps through which the team manages current risks, plans and executes risk management strategies, and documents knowledge for future projects. The six steps in the MSF risk management process are as follows:

  1. Risk identification Identify the risks and make the team aware of potential problems.

  2. Risk analysis and prioritization Convert the information and data about potential risks to information that the team can use to make decisions and prioritize resources for mitigating the risk.

  3. Risk planning and scheduling Use the information developed in the risk analysis stage to formulate risk mitigation strategies, plans, and actions. Allocate time for risk planning in the project plan.

  4. Risk tracking and reporting Monitor the status of specific risks and the progress of their specific mitigation plans. Report this progress to the team, customers, and key stakeholders.

  5. Risk control Execute the risk mitigation plan and report the status of the risks to the team and customer.

  6. Risk learning Document the lessons learned from the project so that the team and the organization can reuse this information.

NOTE
The steps in risk management are logical steps; they do not need to be followed in chronological order. Teams often iterate through the identification, analysis, and planning steps as they develop experience on the project for a set of risks, and only periodically return to the learning step.
Contents of the Risk Assessment Document

During the envisioning phase, the team practices risk management by creating a risk assessment document, identifying and documenting all the known risks, and assessing them for probability of occurrence and impact.

The risk assessment document must contain the following items:

  • Risk statements, which capture the nature of each risk

  • Risk probability, which describes the likelihood of the occurrence of the risk

  • Risk severity, which specifies the impact of the risk

  • Risk exposure, which specifies the overall threat of the risk

  • Mitigation plans, which describe the efforts for preventing or minimizing the risk

  • Contingency plans and triggers, which specify the steps that you need to take when a risk occurs and when to take those steps

  • Risk ownership, which specifies the name of the team member who is responsible for monitoring the risk on a regular basis

How to Create the Risk Assessment Document

The program manager creates the risk assessment document. The team might compare the risks associated with different solution concepts before documenting the solution concept.

For example, imagine that you are creating an e-commerce Web site. One option would be to create the site from the very beginning. However, this would require assembling and managing extensive development resources. You would also need a lot of time to complete the project. Another option would be to quickly move to the development process by using Microsoft Solution Accelerator for the Internet Storefront. The preconfigured source code, MSF project planning principles, and resource kit with reference documents and tools could help the team achieve its business goals. In addition, this would help mitigate the risks associated with building an e-commerce site from the beginning.

Calculating risks

When you create a risk assessment document, assign a numeric value to risk probability and impact. Probability measures the likelihood that a loss will occur; impact measures the severity of that loss, should it occur. Then calculate the exposure of each risk by multiplying the two numbers. This process allows you to compare risks and determine their relative severity and priority. For example, use a number between 1 and 4 to designate probability and impact for each risk, with 4 being the highest and 1 being the lowest. By multiplying the numbers representing probability and impact for a risk, you obtain an exposure factor between 1 and 16. This process allows you to identify and address the most severe risks first.

IMPORTANT
You do not need to use the same numeric scale to assess both probability and impact. However, you must use a consistent scale to calculate the probability for every risk and its impact. If you can accurately calculate the financial loss that can be caused by each risk, you can express impact in financial terms. However, if you express the impact of some risks by using a number and others by using financial terms, you cannot compare the exposure of the different risks.
Creating a top 10 list

After creating the risk assessment document and ranking each risk according to its exposure, you can create a list of the top risks so that the team can focus on them. Often called a top 10 list, this list need not contain exactly 10 risks. The program manager should review the list frequently and update it according to the importance of the risks.

Risk exposure in an e-commerce project presents areas that are unique to the situation and that might be new to the team. Some possible risks to an e-commerce project include:

  • Inexperience with Web site creation, deployment, and ongoing support

  • Potential liabilities, such as image and brand damage for the company, if the site does not function correctly or suffers from availability issues

  • Security risks, which include intrusion into the system by malicious users and theft of confidential customer data such as credit card numbers


Activity: Developing a Vision/Scope Document

In this activity, you will use what you learned in the lessons to work through the envisioning phase of a project. Each of the exercises is based on the following scenario.

Scenario

Adventure Works Cycles, a large, multinational manufacturing company, produces and distributes metal and composite bicycles to North American, European, and Asian commercial markets. Its base operation is located in Bothell, Washington, and employs 500 people; several regional sales teams are located throughout the company’s market region.

Sales representatives from regional sales offices are responsible for assigned sales territories. Each regional office consists of several sales representatives and a team manager. In their daily sales activities, sales representatives use both laptops and Handheld PCs that run Microsoft Windows® CE.

A typical work day for a sales representative starts with the representative dialing in to the regional office and downloading current data such as inventory, product, and promotional information. During customer visits, the sales representative takes orders on the laptop or Handheld PC. At the end of the day, the sales representative sets up appointments for the following day or week, checks the appointments of other representatives in the area for possible collaboration, and updates the contact list. Finally, the sales representative dials back in to the regional office, sends updated information, and receives any new internal communications from the base office or regional office.

Currently, the sales teams at regional sales offices do not have an easy way to analyze the customer data. The customer data is stored in the systems, but there is no easy way to retrieve the data and allow the sales teams to request specific information. For example, the system does not provide a way to identify the best customers overall or the best customers of specific models. To better identify the best customers and to determine why they are the best customers, the company needs a way to access and analyze customer data in a meaningful way.

In recent months, the sales teams have been trying to present their products and achieve sales in the company’s European and Asian markets. Currently, all the information they have in their systems is written in English. A sales representative working in the Hanover office has said that she actually translates the product information into German before she goes on her sales calls. She knows the language quite well, but there might be some technical terms that she might not translate correctly. Because of this translation process, inaccuracies might appear in the translated materials. The company therefore needs to store multilingual and multiregional information in the database rather than relying on the sales force to translate the information.

The sales team needs to obtain the latest pricing information on a daily basis. Currently, the sales representative connects to the corporate network and downloads the new pricing list each day in the morning. However, the download process does not identify which prices have been modified for that individual sales representative. So the sales representative is required to download the entire list every morning. Typically, sales representatives will find out that nothing pertaining to their area or product has changed, and the 20 minutes that it took to download the latest information were wasted.

This difficulty in downloading information to find out whether there are changes has had some unfortunate results. Most sales representatives have stopped downloading the pricing information on a daily basis. Because they have stopped downloading this information, sales representatives frequently miss changes that affect them. When sales representatives miss changes that affect them, they need to redo orders, recalculate pricing, and notify customers of the price changes. As a result, customers are unhappy when they find out that the prices offered to them were incorrect. Currently, the sales teams can override the system and sell products to customers at the prices that were initially negotiated. But this process has received criticism from the corporate base office because the company has lost money in recent months because of this approach.

Currently, the sales opportunities are managed by individual sales representatives and are not entered into the system. Each sales representative creates a Microsoft Word document and stores information such as contact name, address, telephone number, products the contact is interested in, date first contact was made, date last contact was made, and so on. In addition, the sales associate tracks “rules,” which are statements that help the associate convert a sales opportunity into a sale. For example, a rule might be “Customer C will buy product P if (a) the price of product P is reduced by 5 percent or (b) product P comes with components X, Y, and Z as options.”

The regional sales office employees are supposed to use the customer-management system to plan, execute, and track sales and marketing strategy. The problem with the system is that the customer management system is an older fourth-generation-language model, and getting anything even remotely meaningful out of it is very difficult. In addition, the sales associates are required to install a large application on their laptops and connect to the corporate network to use it.

The sales teams have identified the following requirements that will help them perform their jobs better:

  • Customer segmentation and profiling. The sales team needs to be able to extract information from raw data available in the databases to answer questions such as the following:

    • What are the early warning signs of problems?

    • Who are the best customers across all product lines? On whom should the sales team focus its efforts for building long-term relationships?

    • What are customers’ issues, categorized according to demographic groups?

    • Where are the best customers of Adventure Works Cycles?

    • What products are the customers buying and at what rate?

  • Sales activity. To support sales activity throughout the world, the sales team needs international support, including Unicode characters, multiple languages, date and time data types, and multiple currency formats.

  • Internal communication. Each sales representative must receive customer and sales data pertinent only to that representative. In addition, each team manager must receive relevant customer and appointment data along with detailed information for each sales representative on the team.

  • Opportunity management. Sales representatives need a method to store and access sales opportunity data, and, when a sale is generated, to convert some or all of the information into a sales order without re-entering information.

  • Decision support system. The decision support system should support the following tasks:

    • Allow marketing and sales staff with little technical knowledge to query and use customer data to generate standard reports; execute custom queries; obtain information related to promotion tracking, sales forecast, and customer segmentation; and access third-party data sources and financial evaluation tools.

    • Present a single unified view of the customer and the customer relationship.

    • Allow sales representatives to initiate new promotions and programs on a multinational basis. Currently, sales representatives do not know how to associate these programs with specific areas for the best impact.

    • Allow sales representatives to identify, analyze, and share all aspects of customer relationships with individuals in multiple departments.

Exercise 1: Writing Problem Statements

Read the sample scenario describing the Adventure Works Cycles Sales department, and write problem statements for the project described. Ensure that the problem statements you write outline the business problems and provide direction to the project team in the scenario.

Sample possible problem statements include the following:

Sales are lost because we cannot identify the best customer opportunities.

Product information can be incorrect because of manual translation of the product information by the sales representatives.

Sales representatives often work with incorrect price and product data, because of difficulty in downloading that information.

Sales representatives have to guess which customers to focus on and can end up spending their time less productively than possible.

Exercise 2: Writing a Vision Statement

Write a vision statement for the application described in the sample scenario.

Get the right information to each specific person when and where that person needs it, and increase sales totals for each representative over the next year.

Exercise 3: Developing Project Goals

From the scenario given, identify the project goals, including the business goals and the design goals.

Business goals include the following:

Increase sales over the next year by making the sales force more productive.

Focus on the best sales opportunities.

Improve sales tracking and marketing strategies.

Design goals include the following:

Improve sales activity throughout the world by providing international support.

Provide specific data pertinent only to a specific employee.


Summary

  • Envisioning provides the team with a clear vision of what the team wants to accomplish for its customers.

  • The members of a team must have the competencies and proficiencies required to perform the task for developing the solution.

  • The scope of the project specifies what will and will not be included in the project.

  • The deliverables of the envisioning phase include the vision/scope document, the risk assessment document, and the project structure document.

  • The project team also develops documents such as the actors catalog, the business rule catalog, and a glossary of terms for its internal documentation.

  • The vision/scope document includes information about the team and project structure, the problem statement, the vision statement, the scope of the project, the solution concept, user profiles, and project goals.

  • The vision statement states the long-term solution that addresses the business problem.

  • The problem statement specifies the problem that will be addressed by the solution.

  • The scope of the project specifies what will and will not be included in the project.

  • The scope of the project is affected by the assumptions, constraints, and estimates of the project.

  • The solution concept specifies how the team intends to meet the goals of the project.

  • User profiles identify all probable users of the solution and their expectations, goals, risks, and constraints.

  • Business goals represent what the customer wants to accomplish with the solution.

  • Design goals represent the attributes of the solution that the project team is going to develop.

  • The project structure document includes information such the team’s administrative structure, standards and processes, and project resources and constraints.

  • The key components of the project structure document are:

    • Team and structure

    • Project estimates

    • Project schedules (early versions)

  • A project structure document is a tool for documenting the decisions made regarding the execution and management of the project, including:

    • Team and customer roles and responsibilities

    • Communication decisions

    • Logistical decisions

    • Change management decisions

    • Progress assessment decisions

  • The envisioning phase culminates with an approved vision/scope document.

  • The team, key stakeholders, and customers indicate the completion of the envisioning phase by approving the vision/scope document.

  • MSF advocates constant risk management throughout the life of the project.

  • The MSF risk management process defines six steps through which the team manages current risks, plans and executes risk management strategies, and documents knowledge for the enterprise. The six steps are as follows:

    • Risk identification

    • Risk analysis and prioritization

    • Risk planning and scheduling

    • Risk tracking and reporting

    • Risk controlling

    • Risk learning

  • During the envisioning phase, the team practices risk management by creating a risk assessment document. Contents of the risk assessment document include:

    • Risk statements

    • Risk probability

    • Risk severity

    • Risk exposure

    • Mitigation plans

    • Contingency plans and triggers

    • Risk ownership


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What is the purpose of envisioning?

  2. What are the responsibilities of the various roles during the envisioning phase?

  3. What are the outputs of the envisioning phase?

  4. What is the purpose of specifying the project scope?

  5. How does the envisioning phase end?

  6. What kinds of change management decisions are recorded in the project structure document?

  7. What is the difference between business goals and design goals?

  8. What are the guidelines for creating user profiles?

  9. What are the essential components of a risk assessment document?

  10. What are the guidelines for assessing risks for a project?


Chapter 4: Creating the Conceptual Design

Chapter 4
Creating the Conceptual Design
About This Chapter

During the envisioning phase, the project team gathers enough information to start the project, which allows them to create the baseline vision/scope document. Near the end of the envisioning phase, the team moves on to the planning phase of the Microsoft® Solutions Framework (MSF) Process Model. During this phase, you ensure that the business problem to be addressed is fully understood so that you can design the solution that addresses the business problem. In addition, you plan how the solution will be developed and determine whether you have the resources to develop the solution.

During the planning phase, you create a collection of models and requirements documents. This collection of models and documents makes up the functional specification, or blueprint, of the solution. You begin working on the functional specification of the solution during the planning phase.

In this chapter, you will learn about the purpose of the planning phase and the three design processes that occur during the planning phase: conceptual, logical, and physical design. You will also learn about the purpose and benefits of functional specification. In addition, you will learn about the conceptual design process in detail.

NOTE
There are many modeling techniques that you can use to model business processes and key activities in a business. This training kit primarily uses use cases and usage scenarios for modeling business processes.
Before You Begin

To complete the lessons in this chapter, you must

  • Understand the MSF Process Model.

  • Be able to create use cases, usage scenarios, and use case diagrams.

  • Be familiar with the outputs of the envisioning phase, such as vision/scope, project structure, and risk analysis documents.

  • Be able to distinguish between the different kinds of information: business, user, system, and operations.


Lesson 1: An Introduction to the Planning Phase

During the planning phase, the team defines the solution: what to build, how to build it, and who will build it. During this phase the team prepares the functional specification, works through the design process, and prepares work plans, cost estimates, and schedules for the various deliverables.

In this lesson, you will learn about the purpose of the planning phase and the responsibilities of the various MSF roles during the planning phase. In addition, you will learn about the key deliverables of this phase.

After this lesson, you will be able to

  • Describe the purpose of the planning phase.

  • Describe the three steps and interim roles of the planning phase.

  • Describe the responsibilities of the various MSF roles during the planning phase.

  • Identify the common deliverables of the planning phase.

Estimated lesson time: 5 minutes
What Is the Planning Phase?

Before you start learning more about the planning phase and its deliverables, it is important to understand where the planning phase fits in the overall MSF process.

Figure 4.1 illustrates how the planning phase fits into the MSF Process Model.

Figure 4-1 Where are you in the MSF process?
Figure 4-1. Where are you in the MSF process?
Moving to the planning phase

During the envisioning phase, the team gathers enough information to determine the scope of the project. The planning phase can begin during the envisioning phase, whenever enough information has been gathered for the team to begin organizing and analyzing that information. During the planning phase, the team takes the work it has done during the envisioning phase and continues to elaborate on it and further organize and analyze it.

Figure 4.2 illustrates how the project team moves from the envisioning phase to the planning phase.

Figure 4-2 Moving from the envisioning phase to the planning phase
Figure 4-2. Moving from the envisioning phase to the planning phase
Purpose of the planning phase

During the planning phase, the team continues with the work done during the envisioning phase, specifically the draft requirements, tasks and task sequences, and user profiles. The planning phase results in the architecture and design of the solution, the plans to accomplish developing and deploying the solution, and the schedules associated with tasks and resources. During the planning phase, the team works to articulate a clearer image of the solution. Although the planning process is intended to move the project forward, many teams get stuck in planning—in essence, they do too much planning. The key for the team is to know when it has enough information to move forward. Too little information is a risk, and too much information can cause a project team to stagnate.

The Three Design Processes: Conceptual, Logical, and Physical

There are three design processes in the planning phase: conceptual, logical, and physical design. These three processes are not parallel. Their starting and ending points are staggered. These processes are dependent on each other. Logical design is dependent on conceptual design, and physical design is dependent on logical design. Any changes to the conceptual design affect the logical design, leading to changes in the physical design.

Figure 4.3 illustrates the three processes within the planning phase.

Figure 4-3 The planning phase of the MSF Process Model
Figure 4-3. The planning phase of the MSF Process Model

Table 4.1 summarizes the design processes of the planning phase.

Table 4-1. The Three Design Processes
Type of design | Perspective | Purpose
Conceptual | View the problem from the perspective of the user and the business. | Defines the problem and solution in terms of usage scenarios.
Logical | View the solution from the perspective of the project team. | Defines the solution as a logical set of cooperating services.
Physical | View the solution from the perspective of the developers. | Defines the solution’s services and technologies.
NOTE
Conceptual design can be broken down further into conceptual design research, conceptual design analysis, and conceptual design optimization. This chapter focuses on the three steps of the conceptual design process.
Roles and Responsibilities in the Planning Phase

Although the project team works as a whole during the planning phase, each role on the team has a different responsibility during the planning phase:

  • Product management ensures that the plan meets the customer needs. This role is responsible for refining requirements, analyzing the current business state, optimizing the solution concept, and creating the conceptual design.

  • Program management ensures that the resources can accomplish the project plan. This role is responsible for the overall design, with an emphasis on logical design and the functional specification. The project management team creates the project plans and schedules and is responsible for completing the planning phase.

  • Development ensures that the plan is technically feasible. This role is responsible for creating the logical and physical design of the solution and adding it to the functional specification. This team also determines the time and effort required for developing and stabilizing the solution.

  • Testing ensures that the plan meets the requirements. This role is responsible for evaluating the design to determine whether features can be tested and for providing a plan and schedule for testing them.

  • Release management evaluates the design for ease of deployment, management, and support. In addition, this role plans for and schedules deployment of the solution.

  • User experience ensures that users will be able to use the product. This role is responsible for analyzing user needs and creating performance support strategies and for evaluating the completed design for usability. This role also estimates the time and effort required to develop user support systems and conduct usability testing for all user interface deliverables.

Milestones and Deliverables of the Planning Phase

The planning phase culminates in the project plan approved milestone, which is the point at which the project team, the customer, and project stakeholders agree on the project deliverables and that the plan meets the requirements and is likely to be successful. The final deliverables at this milestone of the planning phase are:

  • Functional specification (baseline). The functional specification represents what the product will be, based on input from the entire team. You will learn about the functional specification in Lesson 2.

  • Master project plan (baseline). The master project plan is a collection of plans that addresses tasks performed by each of the six team roles to achieve the functionality described in the functional specification. It documents the strategies by which the various teams intend to complete their work.

  • Master project schedule (baseline). The schedule applies a time frame to the master plan. The master project schedule synchronizes project schedules across the teams. It includes the time frame in which the teams intend to complete their work. Aggregating the individual schedules gives the team an overall view of the project schedule and is the first step toward determining a fixed ship date.

  • Updated master risk assessment document. The master risk assessment document that was developed during the envisioning phase is reviewed and updated regularly, but particularly at the milestones. It describes the risks associated with developing the solution. Typically, multiple risk assessments are sorted to identify the highest risks that must be addressed and aggregated to give an overall risk assessment.

All of these documents are living documents, evolving as the project progresses. Although these documents can be modified, any modifications to the documents must first be approved by a committee of users and stakeholders.

Figure 4.4 shows the deliverables of the planning phase.

Figure 4-4 Deliverables of the planning phase
Figure 4-4. Deliverables of the planning phase


Lesson 2: An Overview of the Functional Specification

During the planning phase, the focus of the project team begins to shift from problem definition to solution design. The planning phase of the MSF Process Model culminates in the project plan approved milestone. One of the primary deliverables at this milestone is the functional specification. The functional specification defines what will be built, how it will be built, and when it will be built. The project plan and schedule identify how the project will proceed and provide dates for various milestones in the project. In this lesson, you will learn about the goals and benefits of a functional specification. You will also learn about the risks of not creating a functional specification.

There is no finite beginning or ending point for the process of creating a functional specification. During the planning phase, each of the design processes—conceptual, logical, and physical—contributes different elements to the functional specification. With the completion of each task during the planning phase, the functional specification becomes more complete. The functional specification exists in a baseline version at the end of physical design and is updated throughout development as a best practice.

After this lesson, you will be able to

  • Describe the purpose of a functional specification.

  • Describe the goals and benefits of creating a functional specification.

  • List the risks of not creating a functional specification.

  • Describe the contents of a functional specification.

Estimated lesson time: 10 minutes
What Is a Functional Specification?

A functional specification is the virtual repository of project and design-related artifacts that are created during the planning phase of the MSF Process Model. The artifacts are a result of design activities during the conceptual design, logical design, and physical design processes of the planning phase. These artifacts can include Unified Modeling Language (UML) models such as use case diagrams, usage scenarios, candidate requirements (evolving), candidate features, and various information models.

More Info
UML is a standard modeling language used to document projects that use object-oriented design. The following references provide more information about UML: UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd edition by Martin Fowler and Kendall Scott (Addison-Wesley, 2000) and Use Case Driven Object Modeling with UML: A Practical Approach by Doug Rosenberg with Kendall Scott (Addison-Wesley, 1999).

It is important to remember that a functional specification is virtual in nature. Many of the conceptual, logical, and physical design artifacts are likely to be in electronic form and stored in the databases of various tools. The functional specification can manifest itself in different forms—electronic or paper; textual document or graphical; Microsoft Word document or Microsoft PowerPoint® presentation. Consequently, it is not easy to collate all these artifacts as a single physical document or deliverable. The functional specification is not just the work of one person or role but rather a joint effort by a number of roles on the team.

The functional specification describes the scope of the current version of the solution by listing which features will be a part of the solution. Excluded items should remain in the vision/scope document as potential features of a future version of the solution or as wants or items considered to be out of scope. The functional specification is used to record the decisions and agreements made regarding the functionality of the solution, its interface, design goals, and priorities.

You communicate the result of the design efforts of the team to the development team by using the functional specification. In addition to the development team, the testing team uses the functional specification to create test scripts, test plans, and data, and to test hardware requirements for the solution.

What Are the Goals of a Functional Specification?

Some of the goals of a functional specification are:

  • Consolidate a common understanding of the business and user requirements. The features of a solution depend on the business and user requirements that the solution is going to address. For a small project, the number of requirements might be small and easily documented. For a large and complex project, the number and complexity of requirements increases. A functional specification helps the customer and the project team arrive at a common understanding of the requirements of the solution.

  • Break down the problem and modularize the solution logically. For a complex project to be a success, it is important that the team identifies all parts of the problem clearly. Also, you need to break the solution into distinct, unambiguous parts. A functional specification helps you simplify a solution into logical parts and document them. It also helps the team make changes to the design early in the development process. Making changes to the solution at this stage is less risky and less expensive than making them later in the process.

  • Provide a framework to plan, schedule, and build the solution. The functional specification provides the program manager with a basis for identifying the team’s tasks and creating cost estimates and budgets for the entire project. In addition, the program manager can correctly estimate the resources and time required by the project, and create project plans and schedules. The testing team uses the functional specification to create test cases and test scenarios early in the project life cycle. The release management team uses the functional specification for deploying the solution and supporting the development and test environments.

  • Serve as a contract between the team and the customer for what will be delivered. In most organizations and on most projects, the functional specification serves as a contract between the team and the customer; it is the written evidence of what is to be developed and delivered. A functional specification is not necessarily a legal document, but it can serve as one. If third-party teams or other organizations are involved in the project, the functional specification can serve as an addendum to a project work order.

What Are the Risks of Not Creating a Functional Specification?

Sometimes, constraints such as budget and time prevent the team from creating and using the functional specification. Although the team can proceed to the developing phase of the MSF Process Model without a functional specification, the risks of the project increase significantly. Some of the risks of not creating the functional specification are:

  • The team might develop a solution that does not completely address the customer requirements.

  • The team might be unable to clearly define customer expectations and share a common understanding with the customer. Consequently, the team might not know whether they are developing the required solution.

  • The team might not have enough detail to validate and verify that the solution meets customer expectations and is of the required quality level.

  • The project manager might be unable to estimate the budget and schedule of the project accurately. The information in the functional specification helps the team estimate the effort and skills necessary for developing the solution.

Figure 4.5 illustrates the risks of not using the functional specification for developing a solution.

Figure 4-5 Relationship between functional specification and output
Figure 4-5. Relationship between functional specification and output
Elements of the Functional Specification

The possible elements of a functional specification are listed below. Each element might be a separate document.

  • Conceptual design summary. This section provides a summary of the conceptual design of the solution and includes information such as solution overview and solution architecture. The following artifacts from the conceptual design are used in the functional specification:

    • Use cases

    • Usage scenarios

    • Context models such as screen shots of existing systems and photocopies of current user manuals

    These artifacts can exist in various forms. For example, context models can be in the form of screen shots of an existing system or photocopies of current user manuals or reports; use cases can be in a use case documentation database; and conceptual user interface (UI) prototypes can be in electronic form.

  • Logical design summary. This section provides a summary of the logical design and includes information such as users, objects, and attributes. The following artifacts from the logical design phase are included in the functional specification:

    • Task and task-sequence models

    • Logical object and service models

    • Conceptual models of the proposed solution

    • UI screen flows

    • Logical database model

    • System architecture

  • Physical design summary. This section provides a summary of the physical design document and includes information from key sections of the document, such as the application and infrastructure sections. The following artifacts from the physical design phase are included in the functional specification:

    • Component packaging

    • Component distribution topology

    • Technology usage guidelines

    • Infrastructure architecture and design

    • Description of UI screens

    • Physical database model

  • Standards and processes. This section includes information about the standards and processes that the team uses as guidelines for performing various tasks for the project. In addition, this section includes details of quality and performance metrics that will be used. These metrics are gathered during tests and help achieve the goals defined by the requirements.

Depending on the size and scope of the project, you can include the following sections in the functional specification. To avoid unsynchronized versions, it is recommended that you use references to documents that exist separately rather than reproducing information. For example, do not include information in the functional specification that already exists in the vision/scope document or the risk assessment document.

  • Project vision/scope summary. This section summarizes the business opportunity, the solution concept, and the scope of the project as documented in the vision/scope document.

  • Project history. The section describes the important events and decisions that have been made up to the current date and that have helped deliver the project to its current state. The historical information ensures that the project team and the customer have the same understanding of the project. This information also helps to ensure a thorough understanding of the project.

  • Functional specification summary. This summary is often useful for customers and new team members. You create the first version of the summary after user requirements have been gathered and analyzed and the UI design has been created. In addition to references to the other documents that make up the entire functional specification, this section typically contains screen shots that illustrate the proposed functionality of the solution.

  • Requirements summary. This section provides a summary of the user, system, operations, and business requirements document. The business requirements summary describes what the customer, users, and stakeholders think the solution must do. The user requirements summary includes usage scenarios and describes who will use the solution, when the solution will be used, and how the solution will be used. The systems requirements summary includes information such as systems and services dependencies. The operation requirements summary includes information such as the security, manageability, and supportability requirements of an organization.

  • Usage scenario and use case studies summary. This section provides a summary of the contents of the usage scenarios document. This summary includes a brief statement of each of the key use cases that are included in the document.

  • Assumptions and dependencies. This section lists the project-oriented assumptions and dependencies. An example of a dependency might be the set of technical skills that is required for developing the solution. An example of an assumption might be that the deployment platform for the solution is the Microsoft Windows® operating system. You also need to identify tests that will challenge and validate these assumptions.

  • Security strategy summary. This section describes the security strategy that will influence the design of the solution. The physical design document contains the specific security details in a per-feature and per-component format. This section contains a synopsis of the security strategy, along with references to the security plan.

  • Installation and setup requirements summary. This section is a summary of the environmental requirements for installing the solution. This information is derived from the installation section of the deployment plan of the solution. The physical design document contains details on how these requirements will be addressed.

  • Removal requirements summary. This section describes how the solution should be removed from its environment. This should include a definition of what must be considered prior to removing the solution. In addition, this section also covers information about data that must be backed up before un-installing the solution, to ensure safe recovery and rebuilding later.

  • Integration requirements summary. This section contains a summary of integration and interoperability requirements and the project goals related to these requirements. It includes a summary of the migration plan. The physical design document contains information about how integration will be delivered.

  • Supportability summary. This section provides a summary of the supportability requirements and the project goals related to these requirements. This information is contained in the operations plan and the support plan. The physical design document describes how supportability will be delivered in the solution.

  • Legal requirements summary. This section provides a summary of any legal requirements that must be taken into account. Legal requirements are typically defined by the customer’s corporate policies and by regulatory agencies governing the customer’s industry.

  • Risk summary. This section describes the risks that might affect development and delivery of the solution. Along with each risk, this section contains information about the calculated exposure to the risk and a mitigation plan.

  • References. This section describes any internal or external resources that provide supplementary information to the functional specification.

  • Appendixes. This section is a collection of the outputs of the design process that the team used to develop the functional specification. It includes additional conceptual design details such as field surveys and user profiles, and physical design details such as existing server and client configurations.


Lesson 3: An Overview of the Conceptual Design Process

The planning phase of the MSF Process Model involves three design processes: conceptual, logical, and physical. The conceptual design starts during the envisioning phase of the MSF Process Model and continues throughout the planning phase. Because the MSF design process is evolutionary as well as iterative, conceptual design serves as the foundation for both logical and physical design.

In this lesson, you will learn about the conceptual design process. You will also learn about the goals and benefits of conceptual design.

After this lesson, you will be able to

  • Define conceptual design.

  • Describe the goals of conceptual design.

  • Describe the steps in conceptual design.

  • Describe the research step of conceptual design.

Estimated lesson time: 10 minutes
What Is Conceptual Design?

Conceptual design is the process of gathering, analyzing, and prioritizing business and user perspectives of the problem and the solution, and then creating a high-level representation of the solution.

Developing requirements

During information gathering, draft requirements are captured. It is important that the project team understands the difference between the different categories of requirements: user, system, operation, and business. Draft requirements can be gathered from the initial interviews or from other information that has been gathered. They can then be developed into more-precise statements as the business problem is better understood by the team. These requirements, called the candidate requirements, are later transformed from the language of the user into the language of requirements.

NOTE
You will learn more about transforming draft requirements to candidate requirements in Lesson 4.
Communicating requirements through modeling

To create an accurate and usable conceptual design of a solution, you need to set up an effective method of understanding and communicating the solution with all types of users. For this, you create models of the tasks covered by the scope of the solution. One way to model these tasks and their task sequences is to generate use cases and usage scenarios.

More Info
For more detailed information about writing use cases, you might find the following reference useful: Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley, 2001).

Consider the example of a team that has been assigned to design an e-commerce Web site. To determine what the customer requires from the e-commerce Web site, the team asks the customer what lines of products will be sold on the site and how end users will use the site. To answer these questions, the customer must consider the product catalog and its maintenance, and the various activities that end users will perform on the site. The team can generate a set of tasks and describe them in use cases. For each activity that the customer describes, the architect creates a detailed usage scenario. Exceptions and alternatives that occur in an activity are also recorded in the usage scenario.

Conceptual design in the MSF Process Model

As defined by the MSF Process Model, conceptual design occurs during the planning phase. However, the project team might have begun conceptual design while drafting the vision document during the envisioning phase. After the team has established enough information to further gather and refine requirements, conceptual design can begin.

Figure 4.6 illustrates when the conceptual design occurs in the MSF Process Model.

Figure 4-6 When does conceptual design take place?
Figure 4-6. When does conceptual design take place?

Remember that the design process is iterative. Consequently, the logical and physical designs might overlap with the conceptual design. These three design phases are not parallel; they have different starting points and baselines. Because of the iterative nature of the design process, conceptual design might be modified as a result of the logical and physical designs.

What Are the Goals of Conceptual Design?

Without a conceptual design, you might create a great solution to the wrong problem. Some of the goals of creating a conceptual design are:

  • Understanding the business problem to be solved. Conceptual design involves understanding the problem to be solved and framing the future state of the process to the point of improving the business processes. It embodies a process for refining, documenting, and validating what the users and the business need from the solution.

  • Understanding the requirements of the business, the customer, and the end user. Conceptual design helps the project team determine a project’s needs in context, resulting in a view of the solution that focuses on both the process and the user. The view is not limited to a list of desirable functions; it also includes the broader context of business processes and activities.

  • Describing the target future state of the business. Conceptual design also formalizes the target future state of the business activities. This future state becomes the basis for the next phases of the design process.

In conceptual design, the project team attempts to understand the context of the problem, records the business activities, and tries to portray their boundaries and their relationships. The entire functional specification is not created during conceptual design. However, the project team uses conceptual design to begin work on the functional specification.

Table 4.2 clarifies the scope of the conceptual design.

Table 4-2. Scope of the Conceptual Design
Conceptual design is not | But it helps you to
The complete functional specification | Begin the functional specification
A definition of system components | Identify the parts of the business problem that will be addressed by the eventual components
A technology solution | Records the business activities and portray their boundaries and their relationships
What Are the Steps in Conceptual Design?

Conceptual design has the following three steps and associated baselines. Conceptual design is an iterative process and the steps are repeated as required.

  1. Research. During this step, you perform the following tasks:

    • Obtaining answers to key questions

    • Identifying key business processes and activities

    • Prioritizing processes and activities

    • Validating, refining, and extending draft requirements, use cases, and usage scenarios created during the envisioning phase

  2. Analysis. During this step, you perform the following tasks:

    • Reviewing the user and business research

    • Refining candidate requirements

    • Documenting and modeling the context, workflow, task sequence, and environmental relationships

  3. Optimization. During this step, you perform the following tasks:

    • Optimizing the solution concept created during the envisioning phase

    • Validating and testing the improved business processes

    The optimization baseline leads to the baseline of the conceptual design.

Figure 4.7 illustrates the steps in the conceptual design.

Figure 4-7 Steps in conceptual design
Figure 4-7. Steps in conceptual design

During the research step of conceptual design, the team gathers more information to refine and validate data collected during the envisioning phase. Typically, the information gathered during the envisioning phase is high level and lacking in detail. During the first step of the conceptual design, the team needs to collect detailed information. For example, the team first identifies questions raised by the first iteration of information gathering; the team then continues to clarify the tasks, business processes, and workflow. As greater detail is discovered, the results are incorporated in the use cases and draft requirements.

More Info
You will learn about the analysis step of conceptual design in Lesson 4 and about the optimization step in Lesson 5.


Lesson 4: Building the Conceptual Design

After gathering detailed information about business and user requirements and business process, the team proceeds to the analysis step of conceptual design. At this step, the team analyzes the artifacts created during envisioning phase and elaborates and refines them.

In this lesson, you will learn how to use requirement restating to refine the information you have gathered. You will also learn how to categorize requirements and refine use cases and usage scenarios. In addition, you will learn how to make high-level architectural choices for the solution.

After this lesson, you will be able to

  • Describe the analysis step of conceptual design.

  • Restate requirements.

  • Categorize requirements as user, system, operations, and business requirements.

  • Refine use case diagrams.

  • Select an appropriate application architecture for a solution.

Estimated lesson time: 20 minutes
What Is the Analysis Step in Conceptual Design?

In the analysis step of the conceptual design, you synthesize the information that you gathered in the research step and create detailed usage scenarios. The purpose of the analysis step is to:

  • Review user and business processes and activities

  • Document and model the context, workflow, task sequence, and environmental relationships of the business

Tasks in the analysis step

In the analysis step, you perform the following tasks:

  • Synthesizing information

  • Refining use case diagrams

  • Selecting an appropriate application architecture for the solution

  • Creating a conceptual model of the solution

Synthesizing information is the process of assimilating gathered data and interpreting the results. The team transforms the gathered data into meaningful information. To synthesize data, the project team performs the following tasks:

  • Identify discrete pieces of information about what the user said and did.

  • Record the detailed flow of the tasks that the user performed.

  • Identify tools and pieces of information that were used.

  • Identify exceptions and alternatives that occur while the user performs task.

  • Model the relationship between business processes, business systems, and users.

  • Model the current environment in which the user works and any possible changes to that environment.

Deliverables of the analysis step

Table 4.3 lists the key tasks and deliverables of the analysis step.

Table 4-3. Tasks and Deliverables of Conceptual Design Analysis

Tasks

Deliverables

Synthesize gathered information

  • Information models:

    • Relationship between business processes, business systems, and users

    • Workflow process

    • Task sequence

  • Updated user profiles

  • Candidate requirements

  • Detailed use cases

Create usage scenarios

Current usage scenarios
How to Restate Requirements

When you restate requirements, keep the following criteria in mind:

  • Requirements must be well defined. A well-defined requirement is a complete sentence and typically uses “shall,” “may,” “must,” or “should.”

  • Requirements must be concise. Each requirement must address one item only.

  • Requirements must be testable. Each requirement should have specific inputs resulting in known outputs.

  • Requirements should be organized in a hierarchy of related requirements. You need to group related requirements together under a single high-level requirement to form feature sets.

  • Requirements should be written in the language of the business and should not use jargon.

Table 4.4 shows potential requirement statements that the project team collected and formulated from the interview texts during the envisioning phase.

Table 4-4. Draft Requirement Statements in the Envisioning Phase
Requirement ID | Requirement
1 | Identify best customers by product and location (profit analysis and geographical analysis); these are the customers on which the sales team should focus.
2 | Identify decreases in a customer’s sales.
3 | Identify best customers.
4 | Identify top buyers.

During the analysis step of conceptual design, the team restates the requirements to ensure that each requirement is a concise, complete, and testable statement. While the team is refining requirements, they might also discover new requirements. Restated versions of the requirements are listed in Table 4.5, based on the requirements in Table 4.4. The restated requirements are now concise, complete, and testable. Multiple related requirements are organized in a logical hierarchy.

Table 4-5. Restated Requirements
Requirement ID | Requirement
1.1 | Must be able to analyze customer data
1.1.1 | Must be able to analyze profit levels by product
1.1.2 | Must be able to analyze profit levels by customer
1.1.3 | Must be able to analyze profit levels by region
1.2 | Must be able to sort (descending, ascending) customers
1.3.1 | Must be able to sort (descending, ascending) customers by amount of sales
1.3.2 | Must be able to sort (descending, ascending) customers by amount of sales of particular products
1.3.3 | Must be able to sort (descending, ascending) customers by amount of sales in regions and amount of sales over a specified period of time
1.3.4 | Must be able to sort (descending, ascending) customers by amount of sales over a specified period of time
1.4 | Must be able to identify sales trends
1.4.1 | Must be able to identify drop in sales
1.4.2 | Must be able to identify drops in a customer’s sales
NOTE
Remember that at each step you must validate requirements with the customer.
How to Categorize Requirements

After refining requirements, you categorize them as user, system, operations, and business requirements.

User requirements

User requirements define the non-functional aspect of the user’s interaction with the solution. They help you determine the user interface and performance expectations of the solution in terms of its reliability, availability, and accessibility. In addition, they help you identify the training that the users will need to effectively use the solution. A successful solution satisfies both the organization’s need for technology and the user’s expectations for employing that technology.

Examples of user requirements

Some of the user requirements might be:

  • Sales representatives should not need to type any name they previously typed during any single sales call.

  • A cashier should be able to complete more than one transaction per minute.

  • A customer should be able to complete the purchase of a product on the shopping Web site within five minutes.

System requirements

System requirements specify the atomic transactions and their sequence in the system, and help the project team define how the new solution will interact with the existing systems. The project team also identifies the critical dependencies with external systems that must be managed. Before developing a new solution, the project team must understand the current infrastructure in the organization. This helps the project team to design and develop a solution that can be deployed in the organization with the minimum negative impact.

Examples of system requirements

Some of the system requirements might be:

  • All enterprise line-of-business applications supporting near-real-time user notifications must either implement the approved notification component or have received a waiver during final design review.

  • The solution should not require a user credential other than the credentials passed from logging on to the corporate network.

Operations requirements

Operations requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks. It addresses the following key elements of operations:

  • Security

  • Availability and reliability

  • Manageability

  • Scalability

  • Supportability

Examples of operations requirements

Consider the example of a music store that wants to implement an e-commerce Web site. Some of the operations requirements for this site include:

  • Availability and reliability. Customers should be able to access the site and use its resources at any time within stated service levels.

  • Scalability and flexibility. The solution should be able to handle varying volumes of users and transactions. In addition, the site must be designed so that it can be modified and upgraded without affecting availability or performance. Both the infrastructure and business processes must be scalable and flexible.

  • Performance manageability. The site design should include a system for managing the total system throughput and response time within stated service levels.

  • Strong security. The data, services, and devices in the system must be protected from unauthorized access. The system should also provide authentication and secure transactions.

  • Administrative manageability. The site should allow the administrators to perform their tasks both onsite and remotely.

  • Recoverability. The site should be able to recover from critical failure without major impact, or within stated service levels.

Business requirements

Business requirements describe the organization’s needs and expectations for the solution. Business requirements define what the solution must deliver to capitalize on a business opportunity or to meet business challenges. To identify business requirements, you need to consider the organization as a valid entity with its own set of needs from the solution. These requirements exist at the managerial decision-making level and provide the context in which the solution will operate.

Examples of business requirements

Some examples of business requirements might be:

  • Call-center managers must be able to view the last, current, and average call times for each telephone operator.

  • Cashiers can override an item’s price to a specified amount without the supervisor’s code.

  • The solution must be designed, built, and deployed as quickly as possible.

  • The solution must be able to interact and communicate with other business processes, applications, and data sources.

Consider a music store that wants to increase the sales of its CDs and DVDs and sell to a larger segment of the market. The organization has decided to implement an online shopping site. Some of the business requirements of this organization are:

  • After the user submits an order, inventory must be marked “for fulfillment” and removed from “available” status.

  • The application must provide a method of applying a discount to orders over a specified amount.

How to Refine Use Cases Diagrams

During the envisioning phase, the project team creates a use cases diagram that specifies all high-level use cases in the organization. The purpose of this use cases diagram is to list the key use cases in the system, to define of the scope of solution, and to provide a basis for the solution concept. To create a conceptual model of the design, you need to refine the use cases that are within the scope of the solution by using the information gathered during the research step of conceptual design.

To refine the use cases diagram, you perform the following tasks:

  • Create subordinate use cases.

  • Create usage scenarios for each subordinate use case.

  • Validate each use case and usage scenario against the original interviews, against other documentation, and with the user.

  • Refine requirements with the validated use cases and usage scenario information.

Creating subordinate use cases

To create subordinate use cases, you revisit each use case in the use cases diagram that is within the scope of the project. You then identify each task associated with the use case, and model them as subordinate use cases for the higher-level use case. You also identify all actors that perform the tasks and the relationship between the various tasks and actors.

Figure 4.8 illustrates a refined use cases diagram. This diagram shows many subordinate use cases for the Manage Orders use case.

Figure 4-8 Refined use case diagram
Figure 4-8. Refined use case diagram
Usage scenarios for subordinate use cases

After creating subordinate use cases, you need to create usage scenarios for the new use cases. This step includes elaborating on the original usage scenario and adding a detailed scenario narrative; specifying the basic course; specifying an alternative course, if any; and describing the preconditions and postconditions.

The following is a sample usage scenario of a high-level use case included in the Adventure Works Cycles case study.

Use case title: Order Product Specifications

Abbreviated title: Order Product Specifications

Use case ID: UC 05.1

Requirements ID: 15.1

Intent: To provide full (not basic) product specification document to customer

Scenario narrative: While a customer is viewing an item in the catalog, the customer requests the product specifications.

Actors: Customer

Preconditions: Customer is browsing through the product catalog.

Customer is viewing an item in the catalog.

Basic course:

  1. Use case begins when a customer clicks Order Specifications for This Item

  2. Customer selects the format of the specification.

  3. Customer selects the shipping method.

  4. Address is confirmed.

  5. Use case ends when the order is complete, submitted, and ready to be fulfilled.

Alternative course:

Postconditions: Order is complete, submitted, and ready to be fulfilled. Customer is returned to last view in Browse Products.

Uses/extends: Customer Updates Profile, Customer Creates Profile, Submit Order

User implementation requests: None

Frequency: Occurs in 17 out of 100 sessions by Web customer.

Unresolved issues: None

Authority: Mike Danseglio

Modification history: Date: November 6, 2002

Author: Heidi Steen

Description: Initial version

One of the subordinate use cases for the Order Product Specifications use case is Order Product Specifications by Mail. The usage scenario for this subordinate use case is as follows.

Use case title: Order Product Specifications by Mail

Abbreviated title: Product Specifications by Mail

Use case ID: UC 05.1.1

Requirements ID: 15.1.1

Intent: Provide a means for a customer to receive the specification for a selected catalog item through the postal service.

Scenario narrative: A customer wants to receive a product specification through the postal service. The customer browses through the catalog (UC 05.1) and views the catalog item of interest. After choosing delivery by the postal service, the customer must specify a delivery address. If the customer has logged on with a valid account, the customer can select an address from a list of addresses on file. The customer can also specify an address in a form. After the request has been submitted, the customer receives a confirmation number for future reference.

Actors: Customer

Preconditions:

  • Customer is browsing through the product catalog.

  • Customer is viewing an item in the catalog.

Basic Course:

  1. Use case begins when a customer clicks Order Specifications for This Item

  2. Customer selects the format of the specification, such as specification sheet or brochure.

  3. Customer selects the shipping method, such as electronic, United States Postal Service, one-day delivery, or two-day delivery.

  4. Address list from profile appears.

  5. Customer chooses an address from a list of addresses.

  6. Address is confirmed.

  7. Customer submits the request.

  8. Use case ends when the customer is given a confirmation number.

Alternative course:

  1. Alternative course begins at 4.

  2. 4a. Address does not exist in profile. 4b. Go to Customer Updates Profile or Customer Creates Profile.

  3. Use case resumes at 5.

Postconditions: Order is complete, submitted, and ready to be fulfilled. User is returned to last view in Browse Products.

Uses/extends: Extends UC 05.1, Order Product Specifications

User implementation requests: None

Frequency: Occurs in 17 out of 100 sessions by Web customer

Unresolved issues: None

Authority: Mike Danseglio

Modification history:

Date: December 6, 2002

Author: Heidi Steen

Description: Initial version
Validating use cases and usage scenarios

It is essential that the team validate the candidate requirements, use cases, and usage scenarios with users and other stakeholders. This step helps determine whether any steps in the process have not been documented. The features list is then developed based on the requirements. Revisions to the feature list are identified by elaborating on the use cases, and any additions are validated by the customer.

Remember that validation is an iterative process. It helps you identify gaps in requirements in addition to use cases and usage scenarios.

How to Select an Application Architecture

The key deliverable of the conceptual design is the conceptual model of the solution. To be able to create a conceptual model, you need to understand the services that the solution must provide.

Services in a solution

A service is defined as a unit of application logic that includes methods for implementing an operation, a function, or a transformation.

Services are mapped to actions and used to implement business rules, manipulate data, and enable actions such as adding, retrieving, viewing, and modifying data. Services are accessible across a network through a published interface that contains the interface specification. Customers are not concerned about how a service is implemented; they are concerned about the ability to perform the required actions.

Services can be either simple or complex. For example, services for creating, reading, updating, and deleting information are simple. You might also develop services to implement complex mathematical calculations.

The services that a solution typically provides are:

  • User services. User services are units of application logic that provide the user interface in an application. The user services of an application manage the interaction between the application and its users. To design efficient user services, you need a thorough understanding of the users of the application, the tasks that they will perform, and the typical interactions they will have with the application to perform their activities.

  • Business services. Business services are units of application logic that enforce business rules in the correct sequence. A business service hides the logic of implementing business rules and transforming data from the user services, other business services, and data services.

  • Data services. Data services are units of application logic that provide the lowest visible level of detail for manipulating data. You use data services to implement business schema on the data store being used by the application. Data services are used to manage all kinds of data—static, structured, and dynamic. You use data services in all scenarios in which a user or business service needs to access or work with data.

  • System services. System services are the units of application logic that provide functionality outside the business logic. Common system services include:

    • Backup services

    • Error handling services

    • Security services

    • Messaging services

Examples of services

Table 4.6 lists the various services in an order processing application.

Table 4-6. Examples of Services

Services

Examples

User services

  • Displaying the order service

  • Displaying the customer account service

  • Displaying product information service

Business services

  • Order placing service

  • Updating customer account service

  • Retrieving product information service

  • Checking product inventory service

Data services

  • Order information service

  • Customer account service

  • Product information service

Remember that you classify a service according to its function and not according to its location. The classification into user, business, or data service depends on what the service actually does, as opposed to where it is located. For example, a data service on the client workstation is still a data service.

Application architecture

You also need to know how the services are organized in the solution. The services are organized according to the application architecture. Application architecture consists of definitions, rules, and relationships that form the structure of an application. It shows how an application is structured but does not include implementation details. It focuses on the solution and not the technologies that will be used to implement the solution. To be able to develop a conceptual model of the solution, you need to select the application model and candidate application architecture that the solution will use.

The project team selects the architecture based on both the services that the solution must provide and users’ expectations of the performance of the application. In addition, assumptions about the solution and constraints of the project affect the choice of the application architecture for the solution. Assumptions include the operating systems used in the system. Examples of constraints include budget, time, skills, and resources available for completing the project.

Some of the application architectures that are used are:

  • Client/server architecture

  • Layered architecture

  • Stateless architecture

  • Cache architecture

  • Layered-client-cache-stateless-cache-server architecture

Client/server architecture

The client/server architecture is a two-tier approach that is based on a request-and-provide strategy. The client initiates a session with the server and controls the session, enlisting the server on demand. The client requests the server for one of its services. Upon receiving the request, the server performs the required operation and returns the result to the client.

The benefit of implementing this application architecture is that you can divide the processing required to accomplish a task between the two devices. The client can execute specialized processes and avoid overloading the server with processing requests.

However, one of the limitations of this architecture is that the clients depend heavily on the servers. If the client fails to communicate with the server, the client cannot perform even the most basic task. This is typical in solutions that must process a large number of requests. Such an application is not highly scalable.

Layered architecture

Layered architecture is an evolved version of the client/server architecture and is composed of hierarchical layers. The various services in the application are clearly positioned in specific layers in such a way that a service cannot communicate with other services except the ones in the adjacent layer. Layers encapsulate services and protect one service from another while providing a simplified set of interfaces for shared resources. User, business, and data services are examples of a layered architecture.

Benefits of layered architecture include improved system scalability and high security. You can balance services across available resources and various layers. In addition, layers allow you to implement security on well-defined boundaries with very little negative impact on communications between services within the system.

Layering adds overhead and latency that can negatively affect performance of the system as perceived by the user. You can mitigate the impact of this problem by adding shared caches to the system. However, this approach increases the complexity of the solution, the effort required to design and develop the solution, and the resources required to operate the solution.

Stateless architecture

Stateless architecture is a version of the client/server or layered architecture in which each client request contains all the information that is required by the server to understand and process the request. No information is stored on the client.

Some of the benefits of stateless systems are:

  • Improved visibility. For example, a monitoring system does not need to read more than a single request to determine the full nature of the request

  • Reliability. For example, the solution can easily recover from a partial failure

  • Scalability. The resources used by the solution can be quickly released and easily pooled.

NOTE
A stateless environment places an additional burden on clients to manage their own state. Because a lot of information is passed to the server for every request, the load on the communication channels is also increased.
Cache architecture

Caching is another approach in which the application provides a means for processing some client requests without forwarding the request to another device. To implement this kind of application architecture, you need to identify what can and cannot be cached. You also need to define ways to manage the lifetime of items in the cache.

Because caching avoids transferring request and response data between clients and servers, the application and network performance are greatly improved. In addition, this approach provides a high degree of scalability by creating local storage for frequently requested resources that would otherwise be queued to access a shared repository.

However, caching reduces the reliability of the solution. For example, the cached data might be outdated and so might not match the information that would be received if the request were processed by the server.

Layered-client-cache-stateless-cache-server architecture

Layered-client-cache-stateless-cache-server architecture is the browser-based version of the Windows Distributed interNet Applications (DNA) architecture. It combines the layered-client-server, client-cache, and cached-stateless-server approaches by adding proxies throughout the system as necessary.

This architecture allows you to create highly flexible and scalable applications by distributing processing and remaining stateless on the server. You can scale up and scale out the solution without affecting the transactional integrity of the solution. In addition, this architecture ensures the manageability and flexibility of the solution.

The layered-client-cache-stateless-cache-server architecture is complex and precariously balanced. Any deviation from the implied implementation can quickly deteriorate its portability, network, and user perceived performance.

Example of a conceptual model

Figure 4.9 illustrates the conceptual model of the solution in the Adventure Works Cycles case study. Notice that the model has multiple layers and that the various services of the solution are located in the solution’s three layers.

Figure 4-9 Conceptual model of solution for Adventure Works Cycles
Figure 4-9. Conceptual model of solution for Adventure Works Cycles


Lesson 5: Optimizing the Conceptual Design

The final step of conceptual design is optimization. During optimization, you begin designing the solution by evolving the solution concept as it will be in the final application.

Table 4.7 lists the tasks and deliverables of optimization.

Table 4-7. Tasks and Deliverables of Conceptual Design Optimization
Task | Deliverable
Improve the process. | Description of problems addressed by solution.
Validate the design. | Validated future state of the solution.

In this lesson, you will learn how to optimize the process descriptions gathered during conceptual design. You will also learn how to evaluate the optimized processes and validate the conceptual design.

After this lesson, you will be able to

  • Optimize processes.

  • Evaluate optimized processes.

  • Validate optimized processes.

  • Validate the conceptual design.

Estimated time: 15 minutes
How to Optimize Processes

In addition to researching and analyzing current business processes, you determine which processes will be included in the solution and how the needs of those processes are met. The management or process owners, the users, and the project team must work together to arrive at a solution that focuses on both the processes and the users.

To design the future state, you examine the current state scenarios and eliminate inefficiencies, bottlenecks, and redundant effort. The future state is best designed by the project team and users together with the help of experts in business process reengineering.

NOTE
The project team and the business process reengineering team should design a target future state and redesign business processes only if these activities are included in the scope of the project.

Although many application development teams can do a great deal to design the future state, the involvement of business process reengineering experts is a best practice. To describe the future state, the team performs the following tasks:

  • Envision the target future state.

    • Improve productivity of the current state.

    • Consider needs versus wants.

    • Balance business and user requirements.

    • Balance impact and technical feasibility.

  • Redesign the current process to optimally support key business activities and processes, involving business process redesign experts as appropriate.

    • Optimize the entire process.

    • Integrate processes where possible.

    • Eliminate inefficiencies, bottlenecks, and redundancies.

  • Build target future state usage scenarios that reflect the redesigned process.

  • Validate future state scenarios with stakeholders.

  • Iterate the redesign process as needed.

Instead of designing the future state from an analyst’s perspective, redesign the solution from the users’ perspective. You might find improvement opportunities in workflow activities, outdated or unproductive business policies, unchallenged bureaucracies, missed communication, and non-value-added roles that hinder and fragment the overall effectiveness of a business process. To identify the requirements from the user’s perspective, keep in mind the following guidelines:

  • Identify undesirable sequential activities, bottlenecks, and unnecessary steps in the process.

  • Remove redundancies in the current environment.

  • Integrate individual functional information systems into consolidated process-wide systems.

  • Identify and remove all unnecessary paperwork.

  • Determine the minimum performance level that must be achieved by a process. Try to design a process that achieves the same results with less effort.

  • Reduce the wait time in a system by identifying steps that can be performed simultaneously instead of sequentially.

  • Improve the system by providing users information such as feedback about performance to ensure that problems are resolved immediately.

Redesigning processes identified during design

The key objective of the project team, along with the business process reengineering experts, is to design an elegant solution that minimizes user effort as much as possible. There is no single method for redesigning a process effectively. The team can conduct brainstorming sessions that use various creativity techniques: metaphors, word and thought variation, creativity-barrier exploration, idea-generation exercises, open forum, and non-critical discussions. These ideas represent new approaches to the problem rather than detailed blueprints.

Key questions for the business process reengineers include:

  • Where are the opportunities for user empowerment?

  • Can certain decisions be delegated? If so, what is the impact of delegation on business activities?

  • What can be done in software that is difficult to achieve in the physical world or on paper?

  • What are the opportunities for automation or applying new technologies?

During the redesign process, explore multiple alternatives. It is important to encourage the creative process. Often, a problem has more than one solution.

A key principle in redesign is that every rule or assumption can be challenged. Also, you need to consider all elements of a process during redesign—inputs, outputs, performance levels, resources, control procedures, productivity, and timing. The following summary lists the key elements to consider when optimizing a process:

  • Challenge rules and break assumptions that rules are unquestionable. For example, you can question a rule such as “In this company, all medical claim requests submitted by employees must be approved at the unit, departmental, and divisional levels.”

  • Align the process with performance goals. Think of performance in terms of meeting customer requirements and not just short-term profits.

  • Design activities around products and services. The responsibilities of a user should be designed to meet the goals and objectives of the process and not be designed around a specific task.

  • Replace bureaucracies and hierarchies with self-organized teams that work in parallel.

  • Improve productivity by moving the focus from work fragmentations and task specialization toward task compression and integration.

  • Determine where you can use technology to enable and support the redesigned process.

  • Break the process into subprocesses and deal with each subprocess one process at a time.

Once the process is optimized and targeted as the goal, the focus shifts to redesigning the work. Redesigning work is based on what is necessary from a business standpoint, not what initially seems reasonable or accomplishable. The team needs to examine the conceptual model of the solution and reorganize it to make the process more efficient.

Also, the team might discover new use cases and need to incorporate them into the conceptual model. Based on the new use cases, several alternative process designs might be generated. Validate these alternatives with end users and business process experts by using techniques such as role playing. Based on the results of testing and validation, you can select an alternative for subsequent detailed design.

The process for redesigning work can be summarized as follows:

  • Brainstorm for maximum ideas.

    • Use visualization.

    • Think creatively and break the rules.

    • Generate, evaluate, and challenge options.

  • Supplement brainstorming with other techniques.

  • Validate alternatives with end users and process experts.

How to Evaluate the Redesigned Process

You evaluate the redesigned process to determine whether there is any misunderstood or missing information about user requirements. You also confirm that no problems have occurred because of varying views of the solution among the team.

You also evaluate the cost and benefits of the solution in its current state. Many projects are canceled at this stage because evaluation indicates that the return on investment (ROI) of the new solution does not meet business criteria.

In addition, you need to determine the primary and secondary benefits. The specific benefits should be stated, and the stakeholders, including customers, should be identified.

Table 4.8 summarizes the evaluation criteria for most business solutions.

Table 4-8. Evaluating Benefits and Costs of a Redesign
Evaluating benefits | Evaluating cost
Effectiveness and efficiency of whole and parts | Resources, work effort, and time
Beneficiaries of the solution | Operational costs of technical options and emerging technology
Organizational and cultural effects | Annual and recurring life-cycle costs
Potential revenue and savings |
How to Validate the Conceptual Design Model

After creating the conceptual design, validate it with users and other stakeholders. You can integrate validation directly into the process of evaluating user input. Validation enables you to get users’ confirmation that the conceptual model and requirements represent their view of the business solution and that the solution addresses all use cases and usage scenarios.

You validate the conceptual design of the solution against the use cases, usage scenarios, business requirements, architecture, risks, available resources and time, and all other artifacts that you have developed. Users find it easier to validate a scenario because the scenario contains the context of the requirements.

The validation of the scenarios should also include a validation of the results from the prioritization activity. In other words, the priorities and volume of activity for the scenario should be verified. You get the conceptual design of the solution validated because validation:

  • Reduces risk.

  • Highlights missing information.

  • Indicates diverging views and interpretations of the solution, especially between the business and users.

  • Verifies the volume of activity.

  • Assists in prioritization.

  • Provides a baseline for proceeding to logical design.

The process for validating, testing, and redesigning can include the following steps:

  1. Redesign the work.

  2. Build a set of scenarios that support the work.

  3. Build a prototype of the system.

  4. Draw the user interface.

  5. Obtain user and business feedback.

  6. Repeat until users and the business are satisfied.

Repeat steps 5 and 6 as required.

Techniques for validating conceptual design

There are several techniques for validating scenarios. Some of those techniques include:

  • Walk through. A facilitator guides users through the scenario and asks questions along the way to determine whether the users agree with individual actions and events.

  • Role playing. A set of selected users executes multiple scenarios to evaluate the process and identify areas of refinement. This helps the team select one of the scenarios for detailed design.

  • Prototyping. A prototype provides details of the process, process flow, organizational implications, and technology possibilities. Prototyping is an effective way to communicate the gathered and synthesized requirements to the user. You can create a prototype as an electronic application or in paper form as the functional specification summary. Prototypes should be reviewed and evaluated by the team and should allow management to decide about the final process design. The team also needs to prototype multiple user interfaces. Such prototypes are used to validate that the team has included appropriate information—not whether the dialog box looks right or whether the colors are correct.


Activity: Analyzing Requirements

In this activity, you will use what you learned in the lessons to work through the process of analyzing requirements.

Exercise 1: Refining Use Cases and Requirements

Open the Microsoft Visio® diagram named C04Ex1 in the \SolutionDocuments \Chapter04 folder on the CD. Look at the second tab: AWC Use Case - Ex1ToSolve.

  1. What questions would you ask the customer’s project staff to identify the subordinate use cases contained in Manage Orders?

    Questions you would ask might include:

    • What does it mean to manage orders?

    • What does the Sales Representative role do when managing orders? Name as many specific tasks as possible.

    • What does the Customer role do when managing orders? Name as many specific tasks as possible.

    • What are the differences between the tasks that the customer performs with orders and the tasks that the sales representative performs?

  2. The customer gives you the following information:

    • Both the Customer and the Sales Representative roles need to create, print, change, and cancel orders by using the Web site and the devices the sales representative uses.

    • The Adventure Works Cycles project staff agree that a Help function is needed and that they want the user to be able to view a frequently asked questions (FAQ) section, get Help by means of a wizard, and have instant messaging (IM) sessions available.

    • The sales representative, but not the customer, can apply a discount to the order.

    Use this information and your requirements to enter the appropriate use cases on the third tab, Ch4 Manage Orders, in the Visio file. The Create Order and Revise Order use cases have been provided to give you a starting point.

To see one possible solution, see the C04Ex1_Answer document in the \Solution Documents\Chapter04 folder on the companion CD.

Exercise 2: Viewing a Conceptual Model Diagram

Open the Visio diagram named C04Ex2.vsd in the \SolutionDocuments\Chapter04 folder on the CD. Review the conceptual model. Open the requirements document C04Ex2.xls in the same folder. Review and revise the requirements statements and organize them into a loose hierarchy by using the conceptual model to guide you. For example, organize all requirements related to Revise Order together. Does the conceptual model allow the current requirements to be covered in the solution?

To see one possible solution, see the C04Ex2_Answer.xls document in the \Solution Documents\Chapter04 folder on the companion CD.


Summary

  • The planning phase results in the architecture and design of the solution, the plans to accomplish the development and deployment of the solution, and the schedules associated with tasks and resources.

  • There are three design processes in the planning phase: conceptual, logical, and physical design.

  • The program management team manages and is responsible for the planning phase.

  • The key deliverables of the planning phase are:

    • The functional specification, which represents what the product will be, based on input from the entire team

    • The master project plan, which is a collection of plans for how each of the six team roles will perform their tasks to achieve the functionality described in the functional specification

    • The master project schedule, which specifies the time frame in which the teams intend to complete their work

    • The updated master risk assessment document, which describes the risks associated with creating the product

  • A functional specification is the virtual repository of project and design-related artifacts that are created during the planning phase of the MSF Process Model.

  • The goals of a functional specification are:

    • Consolidating a common understanding of the business and user requirements

    • Breaking the problem into logical modules

    • Providing a framework for planning, scheduling, and creating the solution

    • Serving as a contract between the team and customer about what will be delivered

  • The functional specification consists of:

    • Conceptual design summary

    • Logical design summary

    • Physical design summary

    • Standards and processes used by the team

  • Conceptual design is the process of gathering, analyzing, and prioritizing business and user perspectives of the problem and the solution, and then creating a preliminary version of the solution.

  • The goals of creating a conceptual design are:

    • Determining the business problem to be solved

    • Determining the requirements of the business, the customer, and the end user

    • Describing the target future state of the business

  • The process of conceptual design consists of three steps: research, analysis, and optimization.

  • During the research step, the team gathers more information about the business requirements, the use cases, and the usage scenarios.

  • The tasks performed during the analysis step are:

    • Synthesizing information

    • Refining the use cases diagram

    • Selecting an appropriate application architecture for the solution

    • Creating a conceptual model of the solution

  • A business requirement must be:

    • Well defined

    • Concise

    • Testable

    • Grouped in a hierarchical manner

    • Written in a business language without jargon

  • Business requirements can be categorized as:

    • User

    • System

    • Operations

    • Business

  • To refine the use cases diagram, the project team:

    • Creates subordinate use cases

    • Creates usage scenarios for each subordinate use case

    • Validates each use case and usage scenario against refined requirements

  • To create the conceptual design of the solution, you need to determine the services and the architecture of the solution.

  • A solution can provide business, user, data, and system services.

  • Application architecture consists of definitions, rules, and relationships that form the structure of an application.

  • An application can be based on one of the following architectures:

    • Client/server architecture

    • Layered architecture

    • Stateless architecture

    • Cache architecture

    • Layered-client-cache-stateless-cache-server architecture

  • During the optimization step of conceptual design, the team optimizes the solution and business processes and validates them against business requirements and use cases.

  • To describe the future state of the system, the project team:

    • Envisions the target future state

    • Redesigns the current process to optimally support key business activities and processes

    • Builds target future state scenarios that reflect the redesigned process

    • Validates future state scenarios with stakeholders

    • Iterates the redesign process as needed

  • To redesign a process, the project team:

    • Brainstorms for maximum number of ideas

    • Supplements brainstorming with other techniques

    • Validates alternatives with end users and process experts

  • The project team validates the conceptual design of the solution against the use cases, usage scenarios, and business requirements.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What is the purpose of the planning phase?

  2. What is the difference between the responsibilities of the product management and project management roles during the planning phase?

  3. What are the major deliverables of the planning phase?

  4. How does a functional specification serve as a blueprint for the development team?

  5. What are the goals of a functional specification?

  6. What are the risks of not creating a functional specification?

  7. What is the difference between the business and user requirements of the solution?

  8. What are the benefits of creating a conceptual design?

  9. A company plans to increase its sales by 15 percent during the next financial year by implementing an online shopping site. The company intends to provide its users a Web site that is fast, provides secure credit card processing, and is available at all times. Also, only registered users will be able to purchase products on the site. What are the user, system, operation, and business requirements for this site?

  10. What are the goals of the analysis step of conceptual design?

  11. What is the benefit of synthesizing information?

  12. What are the tasks for creating the future state?

  13. What are the benefits of validating the conceptual design?

  14. What are the four service categories?

  15. Study and categorize the following services.

    • Displaying the employee details service

    • Updating the employee details service

    • Employee information service

    • E-mail service

  16. What are the characteristics of a refined business requirement?

  17. How do you refine use cases during the analysis step of conceptual design?

  18. What are the criteria for evaluating the cost of a solution?


Chapter 5: Creating the Logical Design

Chapter 5
Creating the Logical Design
About This Chapter

The planning phase consists of three levels of design—conceptual, logical, and physical. These design levels occur consecutively; however, they have overlapping start and end points. Therefore, the conceptual design process always starts before the logical design process, but conceptual design will be in process when the logical design process starts. Likewise, the logical design process always starts before the physical design process, but the logical design will be in process when the physical design process starts. Table 5.1 summarizes the design process in the planning phase.

Table 5-1. The Three Design Processes
Type of design | Perspective | Purpose
Conceptual | View the problem from the perspective of the user and the business | Defines the problem and solution in terms of usage scenarios
Logical | View the solution from the perspective of the project team | Defines the solution as a logical set of cooperating objects and services
Physical | View the solution from the perspective of the developers | Defines the solution’s services and technologies

In this chapter, you will learn about the logical design process of the planning phase. This chapter provides an overview of the purpose and benefits of logical design in addition to the team composition during this process. It describes how to create the logical design for a business solution and how to use tools and techniques for documenting the output. In addition, this chapter covers how to optimize the logical design.

Before You Begin

To complete the lessons in this chapter, you must

  • Understand the Microsoft® Solutions Framework (MSF) Process Model.

  • Be familiar with the outputs of the envisioning phase.

  • Be familiar with the planning phase.

  • Understand the three steps of conceptual design—research, analysis, and optimization.


Lesson 1: An Overview of Logical Design

In conceptual design, you describe the solution from the business and user perspectives. The next step is to describe the solution from the project team’s perspective. This is done in the logical design process.

In this lesson, you will learn about the goals and purpose of logical design.

After this lesson, you will be able to

  • Describe logical design.

  • Describe the benefits of logical design.

  • Describe the roles and responsibilities of team members during logical design.

Estimated lesson time: 10 minutes
What Is Logical Design?

Logical design is defined as the process of describing the solution in terms of its organization, its structure, and the interaction of its parts from the perspective of the project team. Logical design:

  • Defines the constituent parts of a solution.

  • Provides the framework that holds all parts of the solution together.

  • Illustrates how the solution is put together and how it interacts with users and other solutions.

When creating a logical design, the team takes into account all the business, user, system, and operations requirements that identify the need for security, auditing, logging, scalability, state management, error handling, licensing, globalization, application architecture, and integration with other systems.

Planning
Because the MSF design process is evolutionary as well as iterative, logical design affects the physical design.
When does logical design take place?

When the project team begins to identify significant objects and entity attributes, it can start the logical design, so logical design can begin before conceptual design ends. The decision to start logical design is made on a case-by-case basis, depending on the project and the team. Figure 5.1 illustrates where the logical design fits within the MSF Process Model.

Figure 5-1 Where are you in the MSF design process?
Figure 5-1. Where are you in the MSF design process?

When project teams proceed from conceptual to logical design, their perspectives change. During conceptual design, the project team defines the business problem based on the data it has gathered from the business and user communities. During logical design, the project team defines the solution elements from its own perspective. The members of the team identify what the solution needs to do. Based on that information, they define the behavior and organization of the solution.

NOTE
Logical design helps the team further refine the requirements that were initially created during the envisioning phase and refined during the conceptual design process.

A good logical design depends on a good conceptual design. If the project team creates a good logical design, it should be easy for a new team member to look at the design, identify important parts of the solution, and understand how the parts work together to solve the business problem. Most often, the work on the logical design overlaps the work on the physical design.

NOTE
The project team optimizes the structure of the solution during the logical design and improves its operation during the physical design, thus leading to an iterative process between logical and physical design.
Logical design tasks

At a more detailed level, the logical design phase can be broken down into the following tasks:

  • Logical design analysis, in which the team performs the following tasks:

    • Refining the list of candidate tools and technologies

    • Identifying business objects and services

    • Identifying important attributes and key relationships

  • Logical design optimization, in which the team performs the following tasks:

    • Refining the logical design

    • Validating the logical design

Figure 5.2 illustrates the analysis and optimization tasks in logical design.

Figure 5-2 Tasks in logical design process
Figure 5-2. Tasks in logical design process

During logical design, the team might encounter some new requirements or features that have not been discovered previously. At this point, the team needs to go back to the customer to verify that these requirements or features are valid, and learn what the customer wants to do with this discovery. Depending on the customer’s answer, the scope of the project might change. If the project scope changes, revise the documentation and models that have been created to incorporate the new requirements or features.

The primary purpose of logical design

The primary focus of the logical design is to identify what the system must do and explain it by using a set of elements. Logical design enables you to:

  • Specify the business needs that should be supported by technology. The logical design is not a technology solution; however, it helps the project team specify the business needs that the solution must support.

  • Identify technology constraints and opportunities. Although the logical design is independent of the physical implementation, the project team can start to identify constraints and opportunities that might affect the selection and implementation of a technology.

  • Identify the appropriate technologies to be implemented. The team must understand the solution completely before the team selects the technology for implementing the solution. The logical design is not optimized for a selected physical model, but it helps the project team identify the most appropriate technologies for implementing the solution. Candidate technologies can be identified during logical design if the logical design demonstrates a good match to the technologies.

  • Identify the areas of logical design that must be adjusted to accommodate infrastructure, operational, and deployment issues. Logical design is not affected by technologies required to develop the components. However, the logical design affects the physical design, and the physical design depends on technologies. Therefore, if the customer requires a Web-based solution for example, the project team should be aware of the deployment constraints during the logical design process.

Outputs of logical design

The outputs of the logical design process are:

  • A logical object model

  • A high-level user interface design

  • A logical data model

NOTE
The logical object model and the logical data model document similar information in different ways. For most projects, one model is sufficient to document the logical design. However some teams might want to create both models as a precursor to physical design, and then validate one model with the other.

Each type of output is described in detail in Lesson 3.

The outputs of the logical design serve as a foundation for the physical design. To understand clearly what happens in the logical design process, consider the analogy of designing a house. During conceptual design, the customer and the architect list the customer requirements, such as entertainment, sleeping, dining, storage, and utility needs. During logical design, the architect creates the floor plan and identifies structural features such as doors, windows, roof, patio, and rooms. The architect also creates a complete layout of the house. Similarly, the project team works with users and the business customer during conceptual design to determine the requirements. Based on these requirements, the project team identifies the components of the solution and devises an overall framework into which the components then fit.

What Are the Benefits of Logical Design?

Creating a logical design for a solution has several benefits, such as helping to create a strong link between the members of the team who have technical knowledge and those who do not. The following list itemizes several of the benefits of logical design.

  • Logical design helps manage the complexity of the project by defining the structure of the solution, describing the parts of the solution, and describing how the parts interact to solve the problem. Many projects fail because they are too complex and are not well designed before their implementation. Complexity can cause confusion, resulting in a poor design of the solution. Logical design helps the team understand and manage the inherent complexity of business processes.

  • Logical design reflects and supports the requirements of conceptual design by verifying that the design will address the business problem. Logical design helps the team discover errors and inconsistencies in the conceptual design, eliminate redundancy in the requirements, and identify potential reuse in the scenarios. These discoveries can be applied back into the conceptual design and measured against the requirements to ensure that the solution will solve the problem.

  • Logical design serves as a point of contact for organizing cross-functional cooperation among multiple systems in the enterprise and provides a coherent view of the entire project. The team can analyze the logical design to identify areas of reuse and make the design more efficient and maintainable.

  • Logical design is used as the starting point for the physical design. Because logical design is an object model, the project team can determine the location and attributes of the objects for their physical representation.

What Are the Responsibilities of Team Roles During Logical Design?

During logical design, each team has a different set of responsibilities. For example, the program management team is responsible for developing the functional specification, facilitating communication and negotiation with the team, and maintaining project schedule and reporting project status. This team takes the primary responsibility for completing the logical design.

Figure 5.3 highlights the responsibilities of the various roles during logical design.

Figure 5-3 Team roles and responsibilities
Figure 5-3. Team roles and responsibilities

Table 5.2 summarizes the tasks that each team role performs during the logical design process.

Table 5-2. Team Roles
Role | Primary task | Secondary task
Product management | Ensuring that the design meets the needs of the business and the customer | Managing customer expectations
Program management | Takes the primary responsibility for the logical design deliverables | Defining project plan, including resources, schedules, and risk assessments
Development | Identifying services and associated objects | Serving as technology consultants to evaluate and prototype technologies
Testing | Validating logical design models against conceptual design | Defining a high-level testing plan
User experience | Defining user performance goals and recommended solutions | Defining a high-level plan for user education
Release management | Evaluating the feasibility of implementing the solution | Defining infrastructure and deployment solutions


Lesson 2: Creating a Logical Design

During the analysis step of logical design, the team breaks the overall problem and its solution into smaller units called modules. A module is a logical unit used as an abstraction for the use cases and scenarios created in conceptual design. For each module, the team identifies objects, services, attributes, and relationships. The team also identifies candidate technologies for the solution during logical design.

In this lesson, you will learn how to identify candidate technologies for a business solution by considering the conceptual design, business objects, services, attributes of objects and services, and relationships between objects from use cases.

After this lesson, you will be able to

  • Select candidate technologies.

  • Identify candidate business objects from use cases.

  • Identify services from use cases.

  • Identify attributes from use cases.

  • Identify relationships between objects from use cases.

Estimated lesson time: 20 minutes
How to Refine the List of Candidate Technologies in Logical Design

During conceptual design, the team begins to identify possible technologies that could be used to address parts of the solution. During logical design, the team further refines the list of candidate technologies already identified, while submitting additional candidate technologies to the list. In evaluating candidate technologies, the team addresses business considerations, enterprise architecture considerations, and technology considerations.

Business considerations

Some of the business considerations include:

  • Feasibility. Determine whether the technology will actually meet the business needs and address the requirements.

  • Product cost. Understand the complete product cost, which includes developer, server, and reseller licenses, and upgrade costs. The team also needs to consider costs for initial hardware and software, support, infrastructure, and training. A new product can be a short-term or long-term investment. A short-term investment solves an immediate need temporarily, such as creating a small and simple client user interface until an intranet Web application is complete. Long-term investments are items that bring benefit for years, such as rewiring a workplace to support higher speed networks or purchasing leading-edge hardware for servers and workstations.

  • Experience. Understand that the amount of experience users have with various technologies can have a large impact. Try to collect answers to questions such as “What experience is available in terms of training, consultation, and comfort level?”

  • Return on investment. Each investment must correspond to a return on investment. Do not select a technology simply because it is new. The investment in new technologies should provide value to the business, such as an increase in revenue or a decrease in costs.

  • Maturity. A mature product is accepted in the market, is well understood, is stable, and has knowledgeable support resources available.

  • Supportability. When selecting a technology, it is important to realize that the technology will need to be supported along with the solution built. The team needs to consider the implications of providing required levels of support for the project and the enterprise.

Some other factors to consider when selecting candidate technologies are:

  • Ease of deployment

  • Competitive advantage

  • Time needed to market the candidate technology

  • Industry perception of the product

  • Ability to integrate with existing systems

Enterprise architecture considerations

The application must fit within the goals and principles outlined by the enterprise architecture. In addition to looking at the existing enterprise architecture, the project team must consider any future plans for the enterprise architecture. For example, if the business is planning to use Microsoft Windows® Server 2003, align the selection of candidate technologies with this plan.

The enterprise architecture describes the current-state and future-state plans. The solution must fit within the constraints of the enterprise architecture. For example, a new technology such as streaming video might require enhanced networking capabilities. A new imaging system might require larger screens. Such changes require not only money to purchase new equipment, but also time to learn and implement the new technologies. If two technologies have an equivalent feature set, the best choice is the one that aligns more closely to the existing enterprise architecture.

The technology must work with the other systems within an organization. In addition, a communication interface must be defined so that other applications can easily interact with the new technology.

Technology considerations

Some of the technology considerations are:

  • Security. Evaluate security considerations for a new solution in terms of authentication, access control, encryption, and auditing. Authentication and authorization are two separate steps in the process of granting users access to resources. Authentication determines whether an individual is who he or she claims to be; authorization permits the authenticated individual to perform permitted actions within the system. Security services also provide encryption to protect the information as it is transported or stored. Auditing creates a permanent record of actions that individuals are performing or attempting to perform within the system.

  • Services interaction standards. Platforms and interaction standards are related. When the team selects a service interaction standard, it needs to evaluate cross-platform integration against power and performance. For example, the Microsoft .NET Framework simplifies application development in a distributed environment. Besides providing cross-language integration features, it reduces the performance problems of scripted or interpreted environments and provides a simplified model for component interaction.

  • Data access. When selecting a data access service, consider performance, standardization, future direction, data access management, and the diversity of supported data stores. Candidate technologies for implementing a data access service might need to support industry standards. One of the requirements of data access services might be to allow the team to efficiently use the service regardless of the data store. Data access services should not force the development team to use a specific language or create a specific client interface. This independence from the requesting client allows the development team to use the most effective tools to process data, regardless of how the data is accessed.

  • Data storage. Data storage systems are responsible for storing all of a business’s information, such as employee, company, and customer information. When selecting a data store, evaluate multiple products. The decision should be based on the same structure and location of information. The location of the information is important. Data can be stored on a single computer, in a server farm, or distributed on client computers. The data storage location directly affects the performance of the application and how it is developed.

  • System services. The project team should evaluate the system services that are required and identify the technologies that will provide those services. System services can also provide many high-availability services, such as fault tolerance and load balancing. In the past, many system services were programmed into each application, but many systems now offer system services independent of a specific application.

    The following services are examples of system services:

    • Transactional services provide the mechanisms and framework for a transaction-based application. In a transactional system, a sequence of steps can be grouped together as a single transaction. If any of the steps fails, the entire transaction fails and can be reversed or rolled back.

    • Asynchronous communication services do not require immediate communication. These services provide a message-based form of execution. A requesting application can be guaranteed that a message will arrive at the remote system, but the requesting application is not dependent on a response within any given period.

    • Messaging services are more than just electronic mail. They route information and deliver information that is not time dependent to many individuals. Queuing services are used to queue messages when the destination is not available. This allows the application to submit messages to a recipient regardless of the recipient’s availability.

  • Development tools. Development tools provide the ability to develop the various parts of an application, such as services and components. They provide integrated development environments, source code control, wizards, and code libraries. These tools can help decrease the time required to create applications. While evaluating development tools, the project team should consider several factors:

    • The first consideration is the skills of the developer. New tools require additional training and learning time for the development team and can affect schedule and resource constraints.

    • Specific project requirements might suggest a tool that requires team training or outsourcing to a third-party development team. Some development tools are easier to use than others. Consider the amount of time a particular development tool will require to implement a project. There is often a tradeoff involving the complexity of the development tool and the efficiency of the developed product. For example, assembly language can be used to develop an extremely fast application, but the development team would likely take much longer using assembly language than it would using a tool such as Microsoft Visual Basic® .NET.

    • Consider different languages for different tasks in the project. When choosing a development language, evaluate whether the language supports the design and implementation of loosely coupled components that can be replaced and upgraded as necessary. However, before implementing the use of different languages for different tasks, evaluate the current skills of the development team and the maintenance issues that might need to be addressed after the solution is deployed. For example, the .NET Framework programming model supports a range of programming languages. This also accelerates developer productivity because the developer can choose to develop in the development language of choice.

    • Remember that the choice of development tools affects other technology decisions. For example, a specific operating system might be required for using the tool or for implementing solutions created by the tool. Microsoft ASP.NET provides a language-independent platform to create Web applications, but it is not platform independent. The applications must run on the Windows operating system.

  • Operating systems. When selecting the operating system, the services that are provided by the operating system can significantly reduce the coding requirements of the application. Additionally, security and scalability needs can be met by the operating system. The choice of operating system might also depend on the types of devices, such as Handheld PCs, desktop computers, servers, and specialized devices particular to a specific industry.

IMPORTANT
All technologies identified at this stage are documented in a technical specification section, which can be a part of any project document, such as a project plan or a functional specification document. This section is further refined during physical design when the team has identified the technologies that will be used to implement the solution.
How to Identify Candidate Business Objects

Objects are defined as the people or things described in the usage scenarios. Objects form the basis for services, attributes, and relationships.

Figure 5.4 shows the overall process of identifying objects, services, attributes, and relationships in the analysis step of logical design.

Figure 5-4 Logical design analysis: identifying objects, services, attributes, and relationships
Figure 5-4. Logical design analysis: identifying objects, services, attributes, and relationships
Identifying objects

You need to identify the business objects, or components, that will provide the functionality for the solution. Look at the usage scenarios you created during the conceptual design process to help you identify these objects. Figure 5.5 illustrates this process. When you have identified an object, you then need to identify the behaviors and attributes of the object in addition to its relationships with other objects.

Figure 5-5 Identifying business objects
Figure 5-5. Identifying business objects

Some usage scenarios might not explicitly contain objects, even though objects are necessary to perform the required business activities. The objects might be hidden within sentences, depending on how the usage scenario is written. Look for hidden references to structures, systems, devices, things, and events. To identify missing objects, think about the scenario in terms of required information and behavior that is not associated with an object.

Example of business objects

To clearly understand the concept of business objects, consider the following use cases:

  • Employee completes a time sheet by recording the billable hours spent at work.

  • Employee creates a contract with the customer.

  • Employee reviews prior billings to the customer.

  • Employee bills time to the customer number

After studying these use cases, you can identify the following business objects:

  • Employee. Performs actions within the system.

  • Customer. The recipient of actions performed by the employee.

  • Time sheet. The means by which the employee identifies the amount of time spent on a project.

  • Contract. The agreement between the employee and the customer.

  • Billings. Invoices that the customer has received for work performed.

  • Customer number. A means of identifying a specific customer in the system.

How to Identify Services

A service is a specific behavior that a business object must perform. It refers to an operation, a function, or a transformation that can be applied to or implemented by an object. You use services to implement business rules, manipulate data, and access information. A service can perform any activity that can be described by a set of rules.

Identifying services

To identify services for an object, examine the usage scenario again. To identify a service, determine what the object is supposed to do, the kind of data the object must maintain, and the actions that the object must perform. If an object maintains information, it also performs the operations on the information. Some examples of such actions that an object might perform include:

  • Calculate total amount

  • Determine the cost of shipping

Figure 5.6 illustrates identifying actions, and therefore services, from a usage scenario.

Figure 5-6 Identifying services
Figure 5-6. Identifying services

Assign the service that you identify to the associated object. This object is either the recipient of the action or is responsible for performing the action in the usage scenario. If it is difficult to identify the correct object for assigning a service, examine all possibilities by a walkthrough of the scenario. A walkthrough of the scenario involves working step by step through every requirement.

State the capabilities and responsibilities of a service in terms as broad as possible. In addition, you need an unambiguous name to identify the service. If you cannot assign a clear name to the service, it indicates that the purpose of the service is not clearly understood and needs more work in the conceptual design.

Examples of services

Figure 5.7 contains examples of services that can be identified from the sample usage scenario.

Figure 5-7 Identifying services from a scenario
Figure 5-7. Identifying services from a scenario

Consider the following usage scenarios:

  • Employee looks up customer name. This usage scenario corresponds to the service find customer for the Employee business object.

  • System retrieves customer name. This usage scenario corresponds to the service retrieve customer number for the Customer business object.

  • Employee records billable hours on the time sheet. This usage scenario corresponds to the service fill time sheets for the Employee business object.

  • Employee reviews prior billings to customer. This usage scenario corresponds to the service view billing history for the Employee business object.

  • Employee bills time to the customer name. This usage scenario corresponds to the service assign hours for the Employee business object.

How to Identify Attributes

Attributes of an object are the definitions of data values that the object holds. Attributes are also known as properties. Each instance of an object maintains its own set of values. For example, for the Employee business object, one of the attributes is given name. In a particular instance, the value of the attribute given name is John. In another instance, the value of given name could be Janet. The set of values of an object’s attributes at any given time is known as the state of the object.

Identifying attributes

To identify the attributes for an object, return to the usage scenario. Look for the words or phrases that further identify the object. For example, the length of a bridge, the name of a person, and the brand name and model of a computer indicate attributes.

The actual attributes of an object are often specified in greater detail than the information covered in usage scenarios. To identify the correct attributes, the project team uses its knowledge of the real world and experience in the problem domain. For example, the project team might derive the attribute name from a usage scenario. Based on their knowledge, the team members might modify this attribute to given name and family name. Often this level of detail is done during the physical design process. However, if sufficient information is available to start this process earlier, the team can start during the logical design.

NOTE
Although many attributes can be listed for an object, the project team should include only the relevant attributes. For example, the attributes given name and family name can be used for most solutions. However, attributes such as height and weight might only be relevant for, for example, a health care solution. To avoid the risk of omitting important attributes, document all the attributes at this stage of the design process. These attributes can be further refined at a later stage of analysis.

To identify the attributes of an object, the project team should consider each business object and attempt to answer the following questions:

  • How is the object described in general and as part of this solution?

  • How is the object described in the context of this solution’s responsibilities?

  • What information does the object contain?

  • What information should the object maintain over time?

  • What are the states in which the object can exist?

Each attribute is generally identified with an object. You need to clearly label each attribute to avoid confusion with other attributes. In addition, record the structure or type of the attribute, such as text or number.

TIP
In many cases, attributes are derived. The computation of such attributes should be recorded as a service of the object. After compiling the list of attributes, study all the attributes carefully. If some attributes are totally unrelated to the other attributes of a specific object, you might need to create a new business object.
Examples of attributes

Consider the following use cases in a usage scenario that describes the purchase order process.

  • Customer has an account number, name, and address

  • Customer must have an approved credit rating for work to be performed

  • Depending on history, customer can request the last consultant that was on site

Based on these use cases, Table 5.3 identifies a business object with its attributes and associated values.

Table 5-3. Example Object with Attributes and Values
Business object | Attributes | Values at one state
Customer | Account Number | 10076
 | Name | Contoso, Ltd.
 | Address | 123 East Main
 | Credit | Approved
 | Last Consultant | Greg Chapman
How to Identify Relationships

Relationships illustrate the way in which objects are linked to each other. Unified Modeling Language (UML) defines four types of relationships: dependency, generalizations, associations, and realizations.

  • Dependency. A relationship between two objects in which a change to one object (independent) can affect the behavior or service of the other object (dependent). Use dependency when you want to show one object using another. For example, a water heater depends on pipes to carry hot water throughout a building. In UML diagrams, dependency between two logical objects is represented by a directional (that is, with an arrow) dashed line.

  • Association. A structural relationship that describes a connection among objects. Aggregation is a special type of association that represents the relationship between a whole and its parts. For example, “Order contains details” is an example of an aggregation relationship. Typically in an aggregation relationship, the whole manages the lifetime of the parts. This form of relationship is called composition. Graphically, association is represented as a solid line. Aggregation is represented by a solid line with a hollow diamond on the end of the line that connects to the whole. Composition is represented in UML diagrams by a solid line with a filled-in diamond on the end of the line that connects to the whole.

  • Generalization. A relationship between a general thing (called the parent) and the specialized or specific thing (called the child). For example, the Manager class is a specific type of the Employee class. A child inherits the properties of its parents, especially their attributes and operations. Generalization means that the child can substitute the parent object anywhere, but the opposite is not true. In UML diagrams, generalization is represented as a solid line with a hollow arrowhead pointing to the parent.

  • Realization. A relationship between classes, in which one abstract class specifies a contract that another class needs to carry out. When you model, you find a lot of abstractions that represent things in the real world and things in your solution, such as a Customer class in a Web-based ordering system. Each of these abstractions can have multiple instances. In general, the modeling elements that can have instances are called classes. A class has structural and behavioral features. All instances of a class share the same behavior but can have different values for their attributes.

    Realization relationships exist between interfaces and the classes and components that realize these interfaces, and between use cases and collaborations. Graphically, generalization is represented as a cross between generalization and dependency relationship, with dashed lines and hollow arrowhead pointing to the parent.

Figure 5.8 illustrates the graphical representations of the four types of relationships.

Figure 5-8 Types of UML relationships
Figure 5-8. Types of UML relationships

Figure 5.9 illustrates the two types of associations—the aggregation and composition relationships.

Figure 5-9 Aggregation and composition relationships
Figure 5-9. Aggregation and composition relationships
Identifying relationships from use cases

To identify relationships from use cases, look at the usage scenario for information that describes physical location, directed action, communication, or ownership, or that indicates that a condition has been met. The project team reviews the scenario and determines which behaviors are associated with an object, and identifies relationships between two or more objects. Figure 5.10 illustrates how associations between objects indicate relationships.

Figure 5-10 Identifying relationships between objects
Figure 5-10. Identifying relationships between objects
Examples of relationships

Relationships represent how the actions of an object or a system affect another object or system, especially if a known state exists between the two. Figure 5.11 illustrates that relationships must exist between objects for a company to produce meaningful work and data.

Figure 5-11 Examples of relationships
Figure 5-11. Examples of relationships

Some relationships between the objects are:

  • The consultant and the customer are related because they are both people.

  • The consultant and the customer are related because they interact with each other.

  • The consultant performs services for the company, and the company requires the services of the consultant.

  • A company has one or more divisions.

Additional relationships might exist in the system. For example, the consultants bring revenue to the company, and the accountants manage the company’s money.


Lesson 3: Documenting Logical Design Output

During logical design, the team creates several outputs that will help in developing the solution design. The outputs include the logical object model, the logical data model, and a high-level user interface (UI) design. There are several tools for documenting and diagramming these outputs. This lesson discusses how to create and document the outputs of logical design.

For more information about diagramming the logical design, see Chapter 2, “Gathering and Analyzing Information.”

After this lesson, you will be able to

  • Use CRC cards to depict interactions between objects.

  • Use sequence diagrams to depict interaction between objects.

  • Create a logical object model to describe relationships between objects.

  • Create a high-level UI design.

  • Create a high-level database design.

Estimated lesson time: 20 minutes
How to Model Relationships

You can use several methods to document logical design outputs. Two such techniques are Class-Responsibility-Collaboration (CRC) cards and sequence diagrams.

NOTE
You can use CRC cards and sequence diagrams in combination to validate the objects and their relationships that you have identified during analysis.
Class-Responsibility-Collaboration cards

A CRC card helps teams focus on high-level responsibilities of a class instead of detailed methods and attributes. Project teams use the CRC card to brainstorm the responsibilities of a class; identify the responsibilities of a class to identify its services. The CRC card indicates all the classes with which a class must interact and identifies the relationships between classes. To validate CRC cards, the team recreates the usage scenarios by using the CRC cards.

Example of a CRC card
Order |
Roles: To maintain order information |
Responsibilities | Collaboration
Determine whether items are in stock | Get current stock information from Order Line
Determine price |
Check for valid payment | Get address from Customer
Dispatch to delivery address |
Issues Where do we store the price information? |
Sequence diagrams

A sequence diagram shows the actors and objects that participate in an interaction along with a chronological list of the events they generate. A vertical line in a sequence diagram represents an object’s lifetime. An arrow between the lifetimes of two objects represents a message, which is a form of communication between two objects that conveys that an activity will take place. The receipt of a message instance is normally considered an instance of an event. The order in which these messages occur is shown top to bottom on the page.

In a solution design, the overall flow of control and sequence of behavior can be difficult to understand. Sequence diagrams help you see the sequence clearly.

Figure 5.12 is a sequence diagram for the logical design of the Adventure Works Cycles scenario.

Figure 5-12 Sequence diagram
Figure 5-12. Sequence diagram
How to Create the Logical Object Model

The primary output of the logical design process in solution design is the logical object model. The logical object model is created from the objects, services, attributes, and relationships that were created earlier in the logical design process.

Considerations for the logical object model

When creating the logical object model, it is important that you consider all the business and user requirements that are applicable to your scenario, such as security, globalization, localization, auditing and logging, error handling, integration with existing systems, and state management. It is also important to consider all the business constraints when creating a logical object model for a solution design.

Example of logical object model

Figure 5.13 is an example of the logical object model for the Adventure Works Cycles scenario. The object model takes into account the security and logging requirements identified during the conceptual design process.

Figure 5-13 Logical object model
Figure 5-13. Logical object model
How to Create a Logical Data Model

You can use either a logical object model or a logical data model to represent a logical design. However, a project team can create both models to represent a logical design in different ways. Both models might be necessary if one model represents a portion of the design more clearly than the other.

The logical design is the middle stage of the natural progression from conceptual design to physical design. When creating the logical data model, you convert the conceptual data needs identified during conceptual design into actual entities and relationships that will define how the data interacts. This information is then used to help model the physical design.

Identify entities and attributes

When you proceed to the logical stage of data design, one of your first tasks is to formulate entities from data requirements and other related information. An entity can be defined as any person, place, item, or concept that defines data or about which data will be collected and stored. An attribute is a characteristic that further defines and describes the properties of an instance of an entity. An entity can have multiple attributes.

Consider the following example, in which italicized words indicate possible candidates for entities:

“Consultants enter their hours onto a time sheet on a weekly basis. The time sheet is then forwarded to the administrative assistant, who types the hours into the invoicing program. The administrative assistant then sends invoices to the customers based on the time reported.”

After identifying the entities, you must determine which of their attributes you want to gather. Attributes describe the solution’s entities. For example, the attributes of a car might be its color, brand, model, and year of production.

When the physical design is implemented, the attributes might become the columns in the database tables.

Define tables

The objects that you identify in the analysis step of logical design are strong candidates for tables and might be transformed into tables in the database during physical design. Tables are meant for those objects about which you need to store information. For example, in a simple order processing system, objects such as customers, products, and catalog might be transformed into tables. In a more complicated system, objects might map to more than one table.

Define columns

The attributes of an object form the columns of the table associated with the object. For example, given name, family name, and job title can be the attributes (and therefore column names) for the Employee table. Each row in the table stores values for various fields for a specific instance of the object.

Define relationships

After identifying tables and their columns, you need to identify any association between tables. Such associations represent the relationship between objects. For example, a relationship exists between the objects Employee and Department—every Department has Employees and every Employee belongs to a Department. You can use cardinality and multiplicity to further define relationships.

Cardinality is an identifying property of a relationship. Cardinality allows you to specify the number of instances of an entity that are allowed on each side of a relationship. For example, one consultant can be assigned more than one project at a time. Multiplicity specifies the range of cardinalities an entity can assume.

You will learn more about defining object relationships in Chapter 8, “Designing the Data Layer.”

NOTE
During logical design, if you have sufficient information to refine columns and define primary and foreign keys, you can create a logical data model that includes columns, primary keys, and foreign keys. However, this level of detail is typically recorded during the physical design process.

Figure 5.14 shows the logical database design that a team typically achieves during the logical design phase.

Figure 5-14 Logical database design
Figure 5-14. Logical database design
How to Create a High-Level User Interface Design

Using the objects, services, attributes, and relationships identified during the analysis step of logical design, the team might decide to create a high-level user interface and database design. Creating a high-level user interface and database design enables the project team to describe the flow of processing that the end user will experience when the solution is ready for customers.

The list of objects and services gives the team an idea about the kind of functionality expected by the users. The team can use this information to design user interface elements such as buttons, text fields, and menu items.

NOTE
For most projects, a major portion of the user interface design is done during the physical design process. However, if the team members believe that they have sufficient information, they can create a high-level user interface design during the logical design process.

Consider the following usage scenario:

The Customer selects a Catalog to browse. The Categories and Products in the
root of the selected catalog are displayed. The Customer can then select a
Product to view its details or select a Category to view the Products and
subcategories in the selected category.

On the basis of this scenario, the team can create the following high-level design for the user interface:

  • Products Information page that displays information about products, such as product description, pricing, and availability

  • Customer Information page that displays information about the customer, such as registration and personal details

The scenario can be expanded to provide the customer with shopping features. Therefore, the user interface can also include the following:

  • Order Information, Check Out, and Order Status pages

  • A history of the previous transactions completed by the customer

NOTE
You will learn more about user interface design in Chapter 7, “Designing the Presentation Layer.”


Lesson 4: Optimizing Logical Design

During the analysis step of logical design, the team analyzes the usage scenarios and defines the solution in terms of objects, services, attributes, and relationships between objects. After the analysis step, the team moves to the optimization step. In this step, the real challenge for the team is to refine and optimize the design by measuring it against the usage scenarios and requirements.

In this lesson, you will learn about refining the list of objects. You will also learn how to verify the business model and establish control in the logical design.

After this lesson, you will be able to

  • Refine the list of objects identified during analysis.

  • Verify the existing business model.

  • Establish control in a logical design model.

Estimated lesson time: 15 minutes
How to Refine Objects

During the analysis step of logical design, the project team identifies objects. All objects might not be completely relevant to the solution. When the team refines objects, they determine whether the objects are relevant.

When refining objects, consider the following:

  • If two objects express the same information or control the same activity, you might be able to combine them and give the combined object a more descriptive name.

  • An object should be specific. Some candidate objects might be created by evaluating additional information from the scenarios. These objects are not necessarily incorrect, but they need to be made more tangible or real. In addition, you might want to examine these objects to determine whether they are within the scope of the project.

  • If an attribute needs to exist independently in the solution, assign it as an object.

  • You might need a new object to control or coordinate a set of services.

  • You can also use services to refine the list of objects. For every service, identify the object on which the service acts.

How to Verify an Existing Logical Object Model

You can verify an existing logical object model by validating it against the set of requirements, by using individual object verification, and by the usage scenario walkthrough.

Validate against requirements

The most important task in optimizing and finalizing the logical design is to validate the logical object model against the existing set of requirements. Ensure that the logical object model documents each requirement that has been identified. If there are requirements that have not been documented, you need to fix the logical object model so that it addresses the missing requirements. After the logical object model captures all the requirements; you are ready to proceed to physical design.

IMPORTANT
If the logical data model misses even a single requirement, it is considered incomplete.
Verify individual objects

In individual object verification, you identify an object’s inputs and outputs and the capability or functionality that the object must provide. For any given input, you should be able to accurately predict the output and behavior and verify the independent parts of the object.

Individual object verification simplifies integration of systems because you can test the individual pieces of the system before integrating them into a single large product. If the constituent pieces have been verified and are correct, the project team can safely assemble the system.

Walk through the scenario

Although the individual object verification technique allows you to verify the independent aspects of a business object, the project team also needs to study how a set of objects solves the complex problems documented in the scenarios. A collection of objects that are interdependent in solving problems can be complex. You can verify the interdependence of objects by conducting a full walkthrough of the scenario, ensuring that all needs of the scenario are met by some combination of objects. Alternatively, you can implement role playing in the scenario. When using role playing, you assign individuals to represent objects and then walk through the scenarios. Role playing also exposes ambiguities that occur when various individuals have different interpretations of what a specific service must do.

By evaluating a scenario one step at a time, you can determine which services are required, and also the sequence in which the services are required in order to move the project team to a successful completion of the logical design. From the starting point of a usage scenario, determine all the objects from which the scenario needs services.

Any message sent between objects indicates a communication between those objects. To determine the type of communication, analyze the requests sent by each object and try to answer the following questions:

  • Does the object have enough information to construct the request?

  • Does the information content of the request come from either the object’s internal data or from the request that triggered the operation?

  • Does the object rely on the internal data of the supplier?

  • Is information that is being passed from the consumer to the supplier linking the object to other parts of the system in an unintended way?

In addition, the project team should examine the input parameters of each request. You need to examine the input parameters and determine whether they provide context-sensitive information that the receiving object does not need. In addition, you need to identify any reliance on information regarding external context that can reduce the reusability of the object in other contexts. You can resolve these issues by shifting responsibilities between objects or by creating new objects.

For a walkthrough of a scenario, consider the following:

  • Determine any dependencies of the operation on the existence or consistency of other business objects.

  • Determine any consistency, sequencing, or concurrency issues. Is a sequential order of operation required in all or part of the transaction?

  • Identify any critical timing. Is it critical to respond immediately, or can an activity be suspended?

  • Consider any organizational issues, such as a transaction occurring in multiple functional areas.

  • Look for business rules that are in more than one business object.

  • Identify audit and control requirements. Identify who is accountable. Verify situations in which accountability is shared by two or more people.

  • Estimate the frequency of an activity. How often does the activity occur? Is it uniform or periodic?

  • Determine locations and cross-location dependencies.

  • Determine whether the service that controls the transaction is dependent on services currently contained in other business objects.

How to Establish Control in Logical Design

Examining the object interactions for various scenarios illustrates that activities need to be performed in a specific sequence. One possible way to examine object interaction is by using state diagrams. Identifying the flow of control enables you to sequence object interactions. Control in logical design:

  • Ensures the transactional integrity of a scenario

  • Coordinates services across multiple objects

  • Identifies cross-object interdependencies

For any activity to complete, specific ordering might be required. Multiple events might occur concurrently. Wait states that must be completed before continuing processing might exist for some services. Such issues determine the issues that the project team must consider during logical design to ensure that error-free actions are carried out at the right time and in the right order, relative to other activities in the system.

Control can be synchronous or asynchronous. Synchronous control refers to the situation in which object services are invoked and the calling object waits for control to be returned. In a synchronous scenario, control is transferred from the calling object to the called object, and the operation is executed immediately. The calling object is suspended until the called object completes its task. After the operation is completed, control is returned to the calling object.

In asynchronous control, a client can submit a request and then continue performing other tasks. The service will process the request and notify the client when processing completes. In this way, the client is not blocked from performing other, unrelated activities while the service is working on the client’s request. The control of the overall process is not transferred from the calling object to the called object. This means that the called object must take responsibility for the integrity of its data resources that might be accessed simultaneously by multiple objects, and it must also maintain common resource coordination throughout the processing sequence.

TIP
In a distributed system, consider whether to create additional objects that handle the various aspects of control, sequencing, and dependency. You need to isolate dependencies and abstract those services that are likely to change frequently with changes in the business.
Control models

Figure 5.15 illustrates the two general models that are available for the control of objects.

Figure 5-15 Control models
Figure 5-15. Control models

The first model uses a high-level encapsulation of the objects to be controlled. The outer object has control and ownership of all of the logical resources required for the activity provided by the inner objects. Because the outer object contains everything that it needs to proceed with an activity, the design is simplified. This control and potential simplification results in a rigid structure for the activity.

For example, the inner objects can be used only by the other objects contained at the same level or by means of some service of the outer object. This can be thought of as a single-user model because only the single outer object can use the inner objects. The outer object is responsible for routing all incoming messages to the correct inner object.

The second model is more flexible, but it can be more difficult to design. In this model, you implement a controlling object at the same level as the resources that it needs to control. This model can be thought of as a multiple user model because the controlling object does not exclusively own the objects that it might be using. These objects can be used simultaneously by other parts of the system. The controlling object is not aware of any of these other potential interactions with the controlled objects. Maintaining the integrity of resources is more difficult in this model.

User interface in control

The two models of control—high-level encapsulation and controlling object—do not take into account the control that users have when they trigger events in objects. In interactive systems, the user interface places control with the users. In reality, however, most systems combine user control with control that is embedded in a set of controlling objects in the system.

Ultimately, joint control and dependency direct the sequence of events. Although you use objects to control transactions, users trigger the sequences of events.


Activity: Identifying Objects for the Logical Design

In this activity, you use what you learned in the lessons to identify objects for inclusion in the logical design.

Exercise 1: Identifying Objects from Use Cases

Following is a list of possible use cases for the company Web site project that Adventure Works Cycles is funding. Examine each use case and identify any objects that should be included in the logical design. You can find the answers to the questions in the appendix.

  1. The shopping cart checks inventory to determine the availability of a particular product.

  2. A new user creates an account in order to place orders.

  3. A user adds a product to the shopping cart.

  4. A user retrieves an order to check its status.

Exercise 2: Creating a Services Matrix

Open the files C05Ex2, Usage Scenario 06.1 View Catalog, Usage Scenario 06.1.1 Add Items in Catalog, and Usage Scenario 06.3.1 Edit Items in Catalog from the \SolutionDocuments\Chapter05 folder on the CD. Using the usage scenario documents, complete the service matrix in C05Ex2 for the Catalog Items business object. Be sure to identify the services, actors, responsibilities, and collaborations for each service, and to map each entry to one of the usage scenarios. To help you get started, an example of a service matrix has been provided in C05Ex2. One possible answer to this exercise can be found in C05Ex2_Answer in the \SolutionDocuments\Chapter05 folder on the CD.

Exercise 3: Creating a Sequence Diagram

Open the C05Ex3 Microsoft Visio® file from the \SolutionDocuments\Chapter05 folder on the CD, and click the Sequence Diagram tab. The page is blank. Assume that a customer has logged on to the online retail site for Adventure Works Cycles. Use the following use case to create a sequence diagram that shows the interaction between the objects. One possible answer to this exercise can be found in C05Ex3_Answer in the \SolutionDocuments\Chapter05 folder on the CD.

The customer opens a catalog, searches for items in the catalog, and adds an item to a new order.


Summary

  • Logical design is defined as the process of describing the solution in terms of the organization, structure, syntax, and interaction of its parts from the perspective of the project team.

  • The logical design phase consists of two overlapping steps:

    • Logical design analysis, during which the project team identifies business objects, services, attributes, and relationships between objects

    • Logical design optimization, during which the team verifies business objects and identifies implied business objects and scenarios

  • The outputs of the logical design process are:

    • The logical object model, which is a set of objects with corresponding services, attributes, and relationships

    • A high-level user interface design

    • The logical data model

  • Objects are the people or things described in the usage scenarios.

  • A service is the behavior that a business object performs.

  • Attributes are the definitions of data values that an object holds.

  • Relationships illustrate the links between objects.

  • A CRC card helps you focus on high-level responsibilities of a class instead of detailed methods and attributes. CRC cards also help identify relationships between different objects in the logical design.

  • A sequence diagram shows the actors and objects that participate in an interaction and a chronologically arranged list of the events they generate.

  • The list of objects and services helps the team to create a high-level user interface design of the solution.

  • To create a database design, the team performs the following tasks:

    • Identify entities, attributes, and relationships

    • Define tables

    • Define columns

    • Define relationships

  • To verify the design, validate the logical object model by comparing it to the existing requirements.

  • To verify the design by using individual object verification, you identify an object’s inputs and outputs and the capability or functionality that the object must provide.

  • To verify the design by walkthrough of the usage scenario, you evaluate a scenario one step at a time and determine which services are required and the sequence in which they are required.

  • Control enables you to sequence object interactions.

  • Synchronous control refers to the situation in which object services are invoked and the calling object waits for control to be returned.

  • Asynchronous control refers to the situation in which object services are invoked and the calling object continues to perform unrelated tasks until the service notifies the calling object of the results of the operation.

  • In the high-level encapsulation method of control, the outer object has control and ownership of all of the logical resources required for the activity provided by the inner objects.

  • In the controlling object method of control, a controlling object is defined at the same level as the resources that it needs to control.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What are the two steps of logical design?

  2. What are the outputs of the logical design?

  3. Should you focus on technological issues during logical design?

  4. What are the benefits of logical design?

  5. How do you identify services in a usage scenario?

  6. How do you identify attributes in a usage scenario?

  7. What is a sequence diagram?

  8. How do you design the tables and columns in a data store for a solution?

  9. What is the purpose of refining the list of objects?

  10. How do you verify the design by using individual object verification?

  11. What is the purpose of control in logical design?

  12. You are creating the logical design of a solution for a customer, and you discover a scenario that was not discovered in your previous analysis. What should you do with this new information?

  13. What is the responsibility of the testing role during logical design?


Chapter 6: Creating the Physical Design

Chapter 6
Creating the Physical Design
About This Chapter

Along with conceptual and logical design, the project team creates a physical design of the solution during the planning phase. In this introduction to physical design, you will learn about the purpose of physical design, and the tasks and deliverables involved in completing the physical design. You will also learn about the four steps in creating a physical design: research, analysis, rationalization, and implementation.

More Info
As with the conceptual and logical designs, the outputs of the physical design step are documented in the functional specification, which is one of the outputs of the planning phase. You can learn more about the functional specification in Chapter 4, “Creating the Conceptual Design,” and Chapter 10, “Completing the Planning Phase.”

You will learn about creating the physical design for the presentation layer in Chapter 7, “Designing the Presentation Layer,” and for the data layer in Chapter 8, “Designing the Data Layer.”

Before You Begin

To complete the lessons in this chapter, you must

  • Understand the Microsoft® Solutions Framework (MSF) Process Model.

  • Be familiar with the outputs of the envisioning phase and the three steps of conceptual design: research, analysis, and optimization.

  • Be familiar with the logical design phase in MSF.


Lesson 1: An Overview of Physical Design

Physical design is the last step in the planning phase of the MSF Process Model. The project team proceeds to physical design after all members agree that they have enough information from the logical design to begin physical design. During physical design, the team applies technology considerations and constraints to the conceptual and logical designs. Because the physical design evolves from the conceptual and logical designs, its success depends on the accuracy of the previous two designs. The reliance of physical design on the conceptual and logical designs ensures that the team will be able to complete a physical design that meets the business and user requirements.

NOTE
To review the three design processes in the planning phase, refer to Table 5.1 in Chapter 5, “Creating the Logical Design.”

In this lesson, you will learn about the purpose and goals of physical design. You will learn about the various steps that the team performs during physical design. You will also learn about the responsibilities of the various roles in physical design. In addition, this lesson covers the deliverables of physical design.

After this lesson, you will be able to

  • Describe physical design.

  • Describe the goals of physical design.

  • List the steps in physical design.

  • Describe the responsibilities of various team roles during physical design.

  • List the deliverables of physical design.

  • Describe the purpose and deliverables of the research step.

Estimated lesson time: 15 minutes
What Is Physical Design?

Physical design is the third design activity in the planning phase of the MSF Process Model. Physical design is the process of describing components, services, and technologies of the solution from the perspective of development requirements. Physical design defines the parts of the solution that will be developed, how they will be developed, and how they will interact with each other. Figure 6.1 illustrates where the physical design fits within the MSF Process Model.

Figure 6-1 Where are you in the MSF design process?
Figure 6-1. Where are you in the MSF design process?

While working on the physical design, the team creates designs based on prior designs and refines the architecture of the solution that has been created up to this time. These designs apply real-world technology constraints to the logical model, including development tools and the deployment environment of the solution. In addition, the team tries to develop a solution that addresses design considerations such as security, availability, scalability, manageability, and performance. The team tries to achieve these goals in a manner that is appropriate to the project and its requirements.

The inputs to the physical design are all of the artifacts that have been created up to this time. This includes the logical object model, a high-level user interface design, and a logical data model generated during logical design. Artifacts such as the project plan might get minor updates and are referred to in setting the deadlines for the milestones of physical design.

During the physical design, the project team reduces the gap between the logical design of the solution and the implementation by defining the solution in terms of implementation details. The purposes of the conceptual design and logical design processes are to understand the business and its requirements and to design a solution that meets those requirements. The physical design process primarily addresses how to implement this design.

At the end of the physical design, the team delivers specifications for a set of components, Microsoft .NET assemblies, binaries, and link libraries; details of the user interface for the solution; the database schema; database objects such as triggers, indexes, and stored procedures; and details of any reports that will be used by the solution.

Figure 6.2 shows the purpose of the physical design process.

Figure 6-2 What is physical design?
Figure 6-2. What is physical design?

Consider the analogy of designing and building a house. In logical design, you determine requirements such as overall electrical capacity, levels of light, and plumbing fixtures required by the house. In physical design, you select the appliances that you will use, the electrical requirements for each device and the corresponding wiring, and circuit specifications.

To proceed from logical design to physical design, the team uses the layered services-based architecture.

NOTE
You can learn more about application architectures in Chapter 4, “Creating the Conceptual Design.”
Scope of the physical design

Table 6.1 explains the scope of physical design.

Table 6-1. Scope of the Physical Design

Physical design is not

But enables you to

Coding

  • Create detailed component specifications for development

  • Determine where components should be located

Technology deployment

Identify technologies that can be used for developing the solution

During physical design, the project team develops the component specifications and deployment topology with which the development team will work to create the solution. The development team takes the target topology into consideration while building the solution.

Remember that in physical design you are still designing the solution and not developing a version of the solution that can be released and deployed.

Difference between logical and physical designs

Whereas during logical design the team views the problem from the perspective of the project team, during physical design the team views the problem from the perspective of the development team. During the logical design, the team documents the activities, constraints, and assumptions of the business. During the physical design, the team defines a solution addressing the constraints of the selected development technologies and deployment environment. In this sense, physical design views the design from a more technical viewpoint.

Basically, physical design is a refinement of the logical design that leads to the implementation of the design to create the solution.

What Are the Goals of Physical Design?

The project team creates the physical design with the following goals:

  • Identifying appropriate technologies for development. During physical design, the project team evaluates technologies and determines the technologies that can be best used to develop the solution.

  • Transforming the logical design into physical design models. During physical design, the team uses the outputs of logical design to produce a flexible specification based on components. This specification describes the application from the development team’s perspective. The team describes the solution in just enough detail to allow the development team to begin creating the solution according to the requirements.

  • Providing a baseline for the development process. In addition to creating models and strategies, the team defines the development roles, responsibilities, and processes.

  • Defining when the project plan approved milestone has been achieved. The team reaches this milestone when the baseline physical design is complete. At the project plan approved milestone, the team re-assesses risk, updates priorities, and finishes estimates for resources and schedule.

What Are the Responsibilities of Team Roles During Physical Design?

During physical design, each team role has a different set of responsibilities. Table 6.2 summarizes the tasks for each team role during physical design.

Table 6-2. Roles and Responsibilities in Physical Design
Role | Primary task | Secondary task
Product management | Managing customer expectations and creating the communications plan | Preparing for solution deployment
Program management | Managing the physical design process and creating the functional specification | Defining project plan, including resources, schedules, and risk assessments
Development | Creating the physical design deliverables: design models, development plans and schedules, and development estimates | Evaluating technologies, building prototypes if necessary, and preparing for the development environment
Testing | Evaluating and validating the functionality and consistency of the physical design against the usage scenarios | Defining detailed testing plans and preparing the testing and quality assurance (QA) environment
User experience | Evaluating physical design against user requirements and designing help solutions | Defining user education plan
Release management | Evaluating the infrastructure implications of the physical design | Defining infrastructure and operations requirements and deployment solutions
What Are the Deliverables of Physical Design?

At the end of the physical design phase, the project team has enough completed design documentation for the development team to begin creating the solution. Specific documentation can vary from solution to solution. Some of the deliverables at the end of physical design include:

  • Class diagrams of the solution.

  • Component models, sequence diagrams, or activity diagrams of the solution.

  • Database schema of the solution.

  • Baseline deployment model that provides:

    • The network topology, which indicates hardware locations and interconnections.

    • The data and component topology, which indicates the locations of solution components, services, and data storage in relation to the network topology.

  • Component specifications that include the internal structure of components and component interfaces.

  • Packaging and distribution strategy that identifies the services to be packaged together in a component and specifies how the components will be distributed across the network topology. It might also include a preliminary deployment plan.

  • Programming model that identifies implementation choices; choices in object state and connection modes; and guidelines for threading, error handling, security choices, and code documentation.

What Are the Steps in Physical Design?

Physical design is the last stage of the planning phase. The planning phase ends when the team reaches the project plan approved milestone. The project team completes the physical design before reaching this milestone.

Figure 6.3 shows the physical design in relationship to the conceptual and logical designs in the planning phase.

Figure 6-3 When does physical design take place?
Figure 6-3. When does physical design take place?

Figure 6.4 shows the four steps of physical design and their associated baselines.

Figure 6-4 Steps in physical design
Figure 6-4. Steps in physical design

The four steps in physical design are:

  • Research, during which the team performs the following tasks:

    • Determining physical constraints and requirements

    • Identifying any infrastructure changes or concerns

  • Analysis, during which the team performs the following tasks:

    • Developing a preliminary deployment model

    • Selecting technologies that will be used to develop the solution

  • Rationalization, during which the team performs the following tasks:

    • Determining a packaging and deployment strategy

    • Packaging components and services

    • Distributing components across the network topology

  • Implementation, during which the team performs the following tasks:

    • Determining a programming model

    • Specifying component interfaces, attributes, and services

NOTE
The implementation baseline leads into the baseline of the physical design.
What Is the Research Step in Physical Design?

During the physical design phase, the team focuses on creating technical solutions based on the logical design. To derive these technical solutions, the team must consider constraints such as the enterprise architecture, the business process, and the infrastructure. In addition, the team needs to consider the architectural and performance requirements of the solution, such as security, availability, scalability, and manageability. For example, perhaps the solution must be able to handle a specified number of transactions per second. During the research step of physical design, the team identifies these constraints and requirements.

Deliverables of the research step

The deliverables of the research step of physical design describe the current infrastructure of the business and provide the foundation for the analysis, rationalization, and specification steps of physical design. The deliverables of the research baseline include:

  • Current network topology

  • Current data topology

  • Current component topology

  • Physical application requirements

  • Updated risk assessment and mitigation plans

Identifying physical requirements and constraints

Throughout the design process, you gather and analyze information about the requirements and constraints of the business. During physical design, you focus on the physical requirements and constraints that affect the development of the solution.

You gather physical requirements from sources such as the current business environment and the enterprise architecture. Some typical physical requirements of a solution are:

  • Performance

  • Cost and benefit

  • Ease of use

  • Deployability

  • Supportability

  • Reliability

  • Reusability

Some typical physical constraints of a solution are:

  • Budget

  • Schedule

  • Network topology

  • Data topology

  • Component topology

  • Technology guidelines

  • Security

Resolving conflicts between requirements and constraints

Often the requirements and constraints conflict with each other. By identifying these conflicts early in the design and addressing them, you can reduce potential problems early. If a problem occurs, you have a plan for mitigating it. For example, an application might require 100 megabits per second (Mbps) of bandwidth on the network, whereas the existing network infrastructure can support only 10 Mbps.

To resolve the conflict, you typically perform the following tasks:

  • Identify the requirements that are absolutely necessary for the project. Identify conflicts among requirements and also analyze the impact of any constraints. Make as many tradeoff choices as possible before development begins.

  • Identify the areas in the infrastructure where the requirements might conflict with the constraints.

  • Analyze the gaps between the requirements and constraints and determine whether you need to make some kind of choice to resolve the conflict. For example, you might choose to upgrade the network to support 100-Mbps speeds. You must make these choices early in the design phase to avoid creating a solution that cannot be implemented.

  • Brainstorm solutions with all groups associated with the project—business, users, project team, and development team.

You can address the gaps between requirements and constraints in the following ways:

  • Accept the gap without doing anything. This implies that the gap is acceptable for the initial release of the solution. Clearly describe the consequences of accepting the gap. In addition, all stakeholders must reach a consensus that this is the appropriate choice.

  • Identify a way to work around the gap. Working around the gap might not be the optimal solution in the long term. However, it may be necessary because of constraints such as limited project resources.

  • Defer addressing the requirement until later stages of the project. The project team can decide to address a requirement in later stages of the project. The team can modify constraints by providing a business case for the change and identifying the impact of the change.


Lesson 2: Physical Design Analysis

During the analysis step of physical design, the team creates and refines the physical design models by using the logical design documentation. In addition, as in each phase, the team refines artifacts that are related both to the design and specifications (UML models, requirements, and use cases) in addition to those related to the project (risk documents, project plans and schedules, and the actors catalog). Physical design involves selecting candidate technologies for the implementation, based on the application requirements. After selecting the probable technologies, the team creates a preliminary deployment model.

In this lesson, you will learn how to refine Unified Modeling Language (UML) models. You will also learn how to select candidate technologies and create a preliminary deployment model.

After this lesson, you will be able to

  • Refine logical design UML models.

  • Create a preliminary deployment model.

Estimated lesson time: 10 minutes
How to Refine UML Models

At the end of the logical design, the team has UML models for objects, services, attributes, and relationships in the solution. Typically, the team uses the artifacts that best capture their intent and decisions to manage the complex parts of the project. This includes the following set of deliverables:

  • Objects and services inventory

  • Class diagrams

  • Sequence diagrams

  • Activity diagrams

  • Component diagrams

During physical design, the team refines these models.

Objects and services inventory

In the analysis step of the physical design, examine the services inventory for the following tasks:

  • Categorizing services based on the MSF services-based application model:

    • User services

    • Business services

    • Data services

    • System services

  • Identifying hidden services

    The team tries to identify services that were not apparent during the logical design, such as system services or specific technical services for transforming data. Remember that each hidden service must be synchronized with development goals by validating it against requirements.

Class diagrams

Class diagrams are used in logical design to represent the static structure of the application object model. During physical design, the team performs the following tasks to refine UML class diagrams:

  • Transforming logical objects into class definitions, including their interfaces.

  • Identifying objects that were not apparent during logical design, such as services-based objects (also known as common services).

  • Consolidating logical objects if necessary.

  • Categorizing objects into a services-based model:

    • The logical boundary objects are potential user services.

    • The logical control objects are potential business services.

    • The logical entity objects are potential data services.

    There might be exceptions for these recommendations. Therefore, the team must carefully examine all relevant factors before making decisions.

  • Refining the methods by focusing on parameters, considering the use of overloads, combining or dividing methods, and identifying how to handle passing values.

  • Refining the attributes. Minimize the public attributes as much as possible for applications based on stateless server architecture. During physical design, the team focuses on internal protected attributes, which will be used by derived objects.

Figure 6.5 shows the class diagram for the Order components.

Figure 6-5 Class diagram
Figure 6-5. Class diagram
Sequence diagrams

Sequence diagrams represent the interaction between objects and the dynamic aspect of the object model. They are usually used to clarify complex class relationships that might not be easily understood by reviewing the static methods and attributes of a group of classes. In the physical design, the team performs the following tasks:

  • Updating classes based on the refined physical design classes

  • Refining the sequence diagram to include interactions between the classes or services based on physical constraints or technology requirements

  • Identifying additional messages (methods) that are triggered by the new physical classes

Figure 6.6 shows the sequence diagram for the Product and Catalog objects.

Figure 6-6 Sequence diagram
Figure 6-6. Sequence diagram
Activity diagrams

Activity diagrams are used to represent the state transition and flow of an application. You can use activity diagrams instead of sequence diagrams and vice versa. In the physical design, the project refines activity diagrams to:

  • Include physical platform and technology requirements.

  • Identify potential workflow processes.

Component diagrams

Component diagrams are used to represent the dependencies between components or component packages. As with sequence and activity diagrams, they are typically used in more complex situations. In the physical design, the project team might create component diagrams to:

  • Clarify dependencies between components.

  • Further define packaging decisions.

Figure 6.7 illustrates the component diagram for the Order process.

Figure 6-7 Component diagram
Figure 6-7. Component diagram
How to Create a Preliminary Deployment Model

Taking artifacts such as the application architecture, the team structure, the project schedule, the requirements, the risks assessment document, and candidate technologies into consideration, the team can draft a preliminary deployment model. The preliminary deployment model includes network, data, and component topologies. This model enables the project team and other stakeholders to review the design. Remember that during physical design the team proposes topologies for solutions that have not been selected yet.

Network topology

The network topology is an infrastructure map that indicates hardware locations and interconnections. The map shows workstations and servers and describes their functions. Additionally, the topology shows the network infrastructure that connects the computers.

Figure 6.8 illustrates a sample network topology for a solution.

Figure 6-8 Network topology
Figure 6-8. Network topology
ON THE CD
The figure shows a sample network topology. For the complete network topology for the Adventure Works Cycles case study, refer to AWC - Network in the \SolutionDocuments\Chapter06 folder on the companion CD.
Component and Data Topology

The component and data topology is a map that indicates the locations of packages, components, and their services in relation to the network topology, in addition to data store locations. The map shows the physical distribution of the components and their locations across the various service layers. The current-state version should already exist if the team is not working on a completely new solution. You can add any new components and services required by the application at this time.

Figure 6.9 illustrates a sample component and data topology for Adventure Works Cycles.

Figure 6-9 Component and data topology
Figure 6-9. Component and data topology
ON THE CD
The figure shows a sample component and data topology. For the complete component and data topology for the Adventure Works Cycles case study, refer to AWC Component Topology in the \SolutionDocuments\Chapter06 folder on the companion CD.


Lesson 3: Physical Design Rationalization

After selecting candidate technologies, the project team proceeds to the rationalization step of physical design. In this step, the project team designs services-based components for services-based applications and develops a distribution strategy for those components.

In this lesson, you will learn about the deliverables of the rationalization step. You will also learn how to develop strategies for distributing and packaging the services that have been designed. In addition, you will learn the effect of coupling and cohesion on the packaging strategy. You will also create a component topology and validate and refine the topology.

After this lesson, you will be able to

  • Identify the deliverables of the rationalization baseline.

  • Create distribution and packaging strategies.

  • Describe cohesion and coupling.

  • Transform services into components.

  • Distribute preliminary components into layers.

  • Create a deployment model.

  • Validate and refine distribution and packaging.

Estimated lesson time: 10 minutes
What Are the Deliverables of Rationalization?

The rationalization step results in several deliverables. These deliverables describe the technologies, strategies, and topologies that you have designed for the solution.

The deliverables of the rationalization baseline include:

  • A distribution and packaging strategy

  • Services-based preliminary components

  • Deployment models:

    • Future network topology

    • Future data topology

    • Future component topology

  • A baseline deployment model

How to Create Distribution and Packaging Strategies

The rationalization step is an iterative process during which the project team tries to design an optimal solution. One of the goals of the rationalization step is the distribution of services and the packaging of those services into components.

The distribution strategy is a rationale for determining where the services will be located in the solution architecture. Distribution is services-based and not component-based.

The packaging strategy is a rationale for determining which services go into each component. You might have multiple strategies in a single solution. For example, a common practice is to divide the business services into business objects (commonly called a business facade layer) without incorporating the business rules directly in the class interfaces. This practice allows the team to create a business rules layer that incorporates most of the business rules (limiting discounts by authorization, for example). The business rules layer can then be changed and redeployed without modifying the business objects. Creating this layer limits the changes to interfaces that communicate with these objects. This strategy can be decided in advance.

To determine an appropriate overall distribution and packaging strategy, you must consider state management and performance of the solution.

State management

State management is the process by which the solution maintains state and page information over multiple requests for the same or different pages. Some methods of managing state in a Web-based solution are:

  • Hold state on client. You can hold state on the client by using objects that retain values between multiple requests for the same information.

  • Structured Query Language (SQL) query strings. A query string is information appended to the end of a page’s URL, such as product number and its category ID.

  • Cookies. A cookie is a small amount of data stored either in a text file on the client’s file system or in memory in the client browser session.

  • Application state. Application state is a global storage mechanism accessible from all pages in the Web application. You use it to store information that is required between server round trips and between pages.

  • Session state. Session state is similar to application state but is limited to the current browser session. If different users are using the solution, each user has a different session state. In addition, if a user leaves the solution and returns later, the user will have a different session state.

Design considerations

Some of the design considerations include:

  • Scalability. Scalability involves the ability to quickly and easily extend the solution to handle more transactions or more users.

  • Performance. Performance of a system includes the response time of the system and the speed with which a system performs application tasks.

  • Manageability. Manageability of a system includes the ease with which the system can be managed on all levels.

  • Reuse. Reuse addresses the ease with which components can be reused by other applications.

  • Business context. Business context involves separate business functions such as accounting or sales.

  • Granularity. Granularity involves the number of services and objects packaged in a single component.

While defining a strategy for distributing and packaging the services of the business solution, the team must consider the solution and its physical requirements and constraints.

When using multiple strategies, the team should strive for a balance between the various requirements and constraints of the solution. For example, the team might decide to choose a strategy focusing primarily on the performance needs of the application. This might affect the scalability of the solution. In such a scenario, the team must decide how to handle this tradeoff.

What Are Cohesion and Coupling?

One of the features of a good component plan is high cohesion and loose coupling. Cohesion is the relationship among different internal elements of a component. Coupling is the relationship of a component with other components.

Cohesion

A component whose services are closely related is said to have high cohesion. The reliability of a component is directly dependent on the close relation between its services. Cohesion can be both beneficial and detrimental, depending on the cause of the cohesion. Cohesion can be:

  • Functional. A unit performs only one task. This is the strongest type of cohesion.

  • Sequential. A unit contains operations that must be performed in a specific order and that must share the same data.

  • Communicational. Operations in a unit use the same data but are not related in any other way. This type of cohesion minimizes communication overhead in the application.

  • Temporal. Operations are combined because they are all performed simultaneously.

Not all cohesion is beneficial. Other types of cohesion can result in a solution that is poorly organized and difficult to understand, debug, and modify. Ineffective types of cohesion include the following:

  • Procedural. Operations are grouped together because they are executed in a specific order. Unlike sequential cohesion, the operations do not share data.

  • Coincidental. Operations are grouped without any apparent interrelationship.

Coupling

Coupling can be tight or loose. When a component is tightly coupled, the component depends heavily on external components to accomplish its function. When a component is loosely coupled, the component is not dependent or is less dependent on external components.

Typically, the looser the link that binds components to each other, the easier it is for the developer to use individual components without causing problems. A component should depend as little as possible on other components. If a dependency exists, the connection between the dependent components must be as clear as possible so that you can easily define interfaces. Another reason to represent the dependencies clearly in design is to ensure that future decisions do not cause a series of failures in the design.

How to Package Components

The primary focus of the physical design rationalization is distributing and packaging services. In the first step of this process, you package the services into layers: user, business, and data.

To begin the process of distribution, identify the high-level services in the physical object model and break them into their individual, layer-based services.

For each business object, group the resulting low-level services into three layers: the user services layer, the business services layer, and the data services layer.

Figure 6.10 illustrates the three service layers.

Figure 6-10 The three service layers
Figure 6-10. The three service layers
How to Distribute Preliminary Components

After packaging services into components, you distribute the components across the network topology and create a component topology. To start the distribution process, the team identifies categories of services—user, business, and data—for each node in the network topology. These categories serve as the baseline for distribution. The distribution strategy evolves as the design is validated against the solution requirements.

Figure 6.11 illustrates the three layers of services and the corresponding components in a sample application.

Figure 6-11 Distributing preliminary components
Figure 6-11. Distributing preliminary components

To help with the distribution of layers, use the following guidelines:

  • Distribute user services to the Web servers or to the client computers.

  • Distribute business services to application servers or Web servers.

  • Distribute data services to the data locations identified in the data topology, including database servers or other locations where the data services will reside.

  • After identifying where service layers will reside, distribute the preliminary components into their indicated service layers. This represents the initial component topology that will evolve throughout the rationalization process.

Figure 6.12 illustrates the logical partitioning of the three service layers in the component model of a generic order processing system.

Figure 6-12 Example of a component model
Figure 6-12. Example of a component model
NOTE
The illustration shows a sample logical partitioning of the three service layers.
How to Create a Deployment Model

The deployment model shows the mapping of the application and its services to the actual server topology. The purpose of the deployment model is to allow the development team and the release management team to design and plan the server topology and configuration.

Figure 6.13 shows an example of a deployment model.

Figure 6-13 Example of a deployment model
Figure 6-13. Example of a deployment model

There are five sets of servers:

  • Application servers that host Web applications and components

  • Database servers that host business databases

  • Portal servers that handle all portal functionality, including all HTTP requests from the application servers

  • Directory or security servers that manage security data, such as enhanced employee data

  • Application and data integration servers that support the optional Microsoft BizTalk Server and the Microsoft Host Integration Server

How to Validate and Refine Distribution and Packaging

After creating the component and deployment models, the project team validates and refines these models.

Validating component and deployment models

During the physical design, the team should validate the component topology against the strategies and requirements of the solution. Validation occurs on an ongoing basis. This enables the team to iterate the design as required.

The project team arrives at an optimal solution by iterating through the process of validation and testing, and by using prototypes to test and tune the packaging and distribution of the components. The team should stop iterating through the solution when only marginal improvements can be made to the solution.

Refining component and deployment models

The key to refining the component topology is to work with services, not components. To evolve the component topology, undo the preliminary component packaging and redistribute the services to meet the needs of the solution.

For example, a requirement states that users must be able to scroll through an entire list without interruption. For best performance, the project team might choose to distribute some of the data services on the client.

After the services have been redistributed, you need to repackage the services. At each location, package the services according to the strategies identified earlier. For example, if ease of deployment is the main goal, the project team might choose to have only one component on the client computer rather than many small components.

TIP
Always take the concepts of cohesion and coupling into consideration when repackaging and redistributing. High cohesion and loose coupling are the ideal, but that ideal might not be practical given the requirements of the solution.


Lesson 4: Physical Design Implementation

During the implementation step of physical design, the team specifies the programming model that the development team will use, the interfaces for each component, and the internal structure of each component. The deliverables of physical design implementation include a programming model; component specifications for interfaces, attributes, and services; and a baseline component specification. The level of detail for each of these deliverables depends on the level of interaction between project management and the development team.

In this lesson, you will learn about the implementation step of physical design. You will learn about the programming model. You will also learn how to specify component interfaces and define the internal structure of components. In addition, you will learn about designing the user interface (UI) and database models.

After this lesson, you will be able to

  • Describe the programming model.

  • List the guidelines for designing component interfaces.

  • Create the internal structure of a component.

  • Describe the physical UI model.

  • Describe the database model.

Estimated lesson time: 10 minutes
What Is the Programming Model?

Because physical design presents the solution from the developer’s perspective, the project team should provide the developers with specifications for component design and technology selection. Component specification provides the development team with enough detail to develop the components of the solution. The specification includes interfaces and the scope of various services and attributes of components. The specification is directly related to the programming model selected for implementation.

A programming model describes how components will be structured. It is based on the goals of the solution and the technologies being implemented.

Purpose of the programming model

The programming model describes how the development team can use the selected technologies. It consists of the programming specifications or standards that will be followed during implementation of the project. The programming model sets specific guidelines to provide consistent component implementation and to increase the maintainability of the components.

The standards prescribed by a programming model might vary for different aspects and service layers of an application. Physical design standards reflect the implementation of the guidelines prescribed by the architecture. If the team decides to implement a stateless server and a stateful client, all attributes are eliminated from class definitions in the physical design. The stateful client might use disconnected .NET datasets as the preferred means of transferring subsets of information to the client.

Design considerations for the programming model

There are several aspects of the programming model that you should consider, including the following:

  • Implementation technologies. Implementation technologies consist of the programming languages, application programming interfaces (APIs), servers and server technologies, and other technologies that are required for implementing a solution. To efficiently use these technologies, you must use a specific programming model. For example, COM+ 2.0 requires single-entrant, single-threaded, in-process components.

  • Stateful versus stateless objects. The state that an object maintains can directly affect its performance, scalability, and implementation complexity. Stateful objects retain information that was used in one or more client calls; stateless objects do not maintain transaction-related information. When creating stateful objects, especially in Web-based solutions, the team must determine where and how the state will be maintained; in contrast, stateless objects typically send and receive all necessary information when the objects are invoked or when objects complete the transaction.

  • In-process versus out-of-process function calls. In-process components perform all execution within a single process, thus eliminating marshalling overhead and increasing performance. Out-of-process components perform their tasks in a process that is separate from that of the invoking client, thus incurring marshalling overhead and degrading performance.

  • Cohesion and coupling. Cohesive components are closely related to other objects with regards to their functionality. Coupling refers to the strength of component interconnections and interactions. In determining how to apply these principles to a programming model, you should design highly cohesive components and loosely coupled objects. If an object is highly cohesive, its methods and properties are tightly related, and the objects within a component are related. Loosely coupled objects are not highly dependent on the interface, state, or the status of other objects. The communication between loosely coupled objects is implemented by means of messages.

  • Connected versus connectionless modes. In distributed component environments, various components participating in the service must have real-time, live connections to each other to function properly. If these real-time connections are severed, the components involved in the interaction fail. Because real-time components must typically be run in connected mode, components written to run in a connectionless environment must be able to reestablish connections as required.

  • Synchronous versus asynchronous programming models. A synchronous programming model blocks the calling component from proceeding with other work until the called interface has completed the requested service and returned control to the calling component. An asynchronous programming model allows components to send messages to other components and then continue functioning without waiting for an immediate reply. A component designed to use an asynchronous programming model is more difficult to program, although technologies such as COM+ Queued Components greatly simplify asynchronous programming. A component that uses an asynchronous programming model lends itself to more scalability because individual components are not blocked and do not need to wait for another process to complete before proceeding.

  • Threading model. Choosing the threading model for a component is a difficult task because the appropriate model depends on the function of the component. A component that performs extensive input and output (I/O) processing might support free threading to provide maximum response to clients by allowing interface calls during I/O latency. In addition, an object that interacts with the user might support apartment threading to synchronize incoming Component Object Model (COM) calls with its window operations.

  • Error handling. Because no component performs perfectly or within a perfect environment, components need an error-handling strategy. Certain programming and deployment model decisions constrain the number of error-handling options available. For example, an error message written to a log file on the client might be difficult to retrieve and pass to someone trying to identify system-wide problems.

  • Security. Security for components and services can be addressed in four basic ways:

    • Component-based security is at the method level, interface level, or component level.

    • Database-based security is handled after data is involved.

    • User context–based security is an interactive method, using system security, or a fixed security within the application.

    • Role-based security involves groups, such as a general manager group.

  • Distribution. Carefully consider the method for distributing the application. Remember that three logical layers do not necessarily translate into three physically distributed tiers. For example, some business services tend to reside on the client, so you should use as many physical tiers as are required to meet the needs of your application and the enterprise’s business goals, possibly even distributing all components to a single location.

Although not a part of the programming model itself, the skills and experience of the technical people who will implement the programming model are an important consideration.

NOTE
Typically, there is not just one programming model for all components. An application might use many programming models, depending on the requirements of the various components.
How to Specify Component Interfaces

After describing the programming model, the project team defines how the components will interact. This interaction is documented by the component’s interfaces, which describe how to access their services and attributes. An interface can represent one or more services. The interface provides a means for requesting a service to perform an operation and a means for receiving information about the resulting attributes. The external structures of the component are outlined in the component interfaces. A component interface:

  • Represents the supplier and consumer relationship between components

  • Is a means to access the underlying services

  • Represents a set of related methods that are a part of a service

  • Includes underlying object attributes for a stateful component

The specification of a component interface typically includes all of the ways a component can be accessed and examples of how the component can be used for each means of access. This specification is complete only when the development team finishes creating the component.

When you create component interfaces, remember that:

  • A published interface is considered as permanent as possible.

  • A modification of an existing interface should be published either as a new component or as a new interface.

  • The data types of published attributes must be supported by the service interface consumer.

The only way to access the underlying services within a component is to use the component’s published interface. A poorly defined interface can negatively affect other parts of the solution.

Most programming languages allow developers to use Interface Definition Language (IDL) interface definitions when coding components. These definitions help to ensure consistency and change control when multiple developers are coding components.

Each implementation language varies in the syntax and complexity required to define a component’s interface. Languages such as Microsoft Visual Basic® often hide much of the interface complexities from developers, whereas languages such as Microsoft Visual C++® provide more control and access to the interfaces. This added control increases coding complexity. Remember that the physical design remains the same, regardless of the implementation language. During physical design, the team can provide a fully-qualified method signature in pseudocode, IDL, or the selected programming language. However, the development team will convert these specifications to a concrete implementation with the selected tools, languages, and technologies during the developing phase.

The Physical Design UI Model

The presentation layer enables users to interact with a system. It provides a communication mechanism between the user and the business services layer of the system. There are two types of users: human users who require an interface through which they can interact with the system, and other computer systems. Although other computer systems do not require a user interface, they require an intermediary to the system with which they will interact. Typically, this intermediary is the user services layer or a Web services interface that facilitates communication between the two layers.

NOTE
A user interface provides a visual means for humans to interact with systems. User services provide the navigation, validation, and error-processing logic.

To design the user interface and user services layer, the project team uses the outputs of the conceptual design. These outputs include:

  • Solution requirements and constraints

  • Future-state usage scenarios

  • Workflow models

  • User profiles

  • Task descriptions

  • User terminology and concepts

More Info
You will learn more about user interface design in Chapter 7, “Designing the Presentation Layer.”
The Physical Design Database Model

During logical design, the database team explores different ways in which the information needs of the conceptual design can be structured in a logical model for a database. The primitive definition for a database is simply an organized collection of data values.

During physical design, the database team must consider:

  • Physical database constraints, such as memory and disk size

  • Performance tuning considerations, such as deadlock detection, indexing, and hot spots

  • Primary keys and foreign keys

  • Trigger design

  • Stored procedure guidelines

  • Application object model considerations

  • Indexing specifications

  • Partitioning data

  • Data migration from the previous database systems

  • Operational considerations, such as cluster failover, backup process, and update process

More Info
You will learn more about database design in Chapter 8, “Designing the Data Layer.”


Activity: Working on the Physical Design

In this activity, you use what you learned in the lessons to create a class model and then create a component model diagram.

Exercise 1: Creating a Class Model

Open the C06Ex1 Microsoft Visio® file from the \SolutionDocuments\Chapter06\ folder on the compact disc, and examine the logical design. Using these diagrams, design a physical class model that is derived from the Catalog, CatalogItem, ManageCatalogItems, and Search objects. You might need to delete or add objects or their attributes and operations. You can see one possible answer to this exercise in C06Ex1_Answer, which is located in the \SolutionDocuments\Chapter06 folder on the CD.

Following are some of the possible discoveries and decisions that have been made in C06Ex1_Answer.

The ManageCatalogItems logical object functionality can best be handled by the Catalog object’s operations: addCatalogItem, removeCatalogItem, countSelectedItems, and so on, so it has been deleted from the diagram.

The customer needs to be able to select items for purchase from the catalog while still browsing the catalog. The group of selected items might change in many ways before it is submitted as an order. To meet these needs, a new object is added to the design: the ShoppingCart object.

Exercise 2: Creating a Component Model Diagram

Open the C06Ex2 Visio file from the \SolutionDocuments\Chapter06\ folder on the CD, and then click the Component Model tab. The page is blank. Create a component model for the objects identified in Exercise 1, “Creating a Class Model.” Assume the following:

  • Sales representatives maintain customer contact information in Microsoft Outlook®.

  • Information about Web customers are maintained in a Microsoft SQL Server™ database and managed by using an authorization component.

You can see one possible answer to this exercise in C06Ex2_Answer, which is located in the \SolutionDocuments\Chapter06 folder on the CD.


Summary

  • During physical design, the project team defines the services and technologies that will be provided by the solution.

  • Physical design is defined as the process of describing the components, services, and technologies of the solution from the perspective of the development team.

  • The goals of physical design are:

    • Transforming the logical design into specifications for a set of components

    • Providing a baseline for implementing the design

    • Identifying appropriate technologies for development

    • Creating a structural view of the solution from the perspective of the development team

  • There are four steps in physical design: research, analysis, rationalization, and implementation.

  • The new deliverables of physical design include:

    • Class diagrams

    • Sequence diagrams

    • Baseline deployment model

    • Programming model

    • Component specifications

  • The deliverables of the research baseline include:

    • Current network topology

    • Current data topology

    • Current component topology

    • Physical application requirements

    • Risk assessment and mitigation plan

  • During the research step of physical design, the project team identifies the requirements and constraints of the solution and tries to reduce the gap between the two.

  • During the analysis step of physical design, the project team refines the UML model created during the logical design, which includes an objects and services inventory, class diagrams, sequence diagrams, and activity diagrams.

  • During the analysis step of physical design, the project team creates a preliminary deployment model that includes network, data, and component topologies.

  • The network topology is an infrastructure map that indicates hardware locations and interconnections.

  • The data topology is a map that indicates data store locations in relation to the network topology.

  • The component topology is a map that indicates the locations of components and their services in relation to the network topology.

  • The deliverables of the rationalization step include:

    • Distribution and packaging strategy

    • Services-based preliminary components

    • Deployment models

    • Baseline deployment model

  • The distribution strategy is a rationale for determining where services will be located in the solution architecture. Distribution is services-based, not component-based.

  • The packaging strategy is a rationale for determining which services will go into each component. You might have multiple strategies in a single solution.

  • Cohesion is the relationship among various internal elements of a component.

  • Coupling is the relationship of a component with other components.

  • To distribute services, identify the high-level services in the business object model, and break them into their individual, layer-based services.

  • To package services, group the low-level services into three components: the user services component, the business services component, and the data services component.

  • The deployment model links the application and its services to the actual server topology.

  • The team must validate the component topology against the strategies and requirements of the solution.

  • To refine the component and deployment model, the team must undo the preliminary component packaging and redistribute the services to meet the needs of the solution.

  • During the implementation step of physical design, the team specifies the programming model that the development team will use, the interfaces for each component, and the internal structure of each component.

  • A programming model describes how components will be structured based on the goals of the solution and the technologies being implemented.

  • A component’s interface describes how to access its services and attributes.

  • The presentation layer enables users to interact with a business system and provides a communication mechanism between the user and the business services layer of the system.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What are the goals of physical design?

  2. What is the difference between conceptual, logical, and physical designs?

  3. What does the development team do during physical design?

  4. What does the deployment model include?

  5. What does the project team do during the research step of physical design?

  6. How does the project team handle the gap between requirements and constraints?

  7. During the analysis step of physical design, how does the project team use the list of objects and services created during logical design?

  8. How does the project team refine the class diagrams during the analysis step of physical design?

  9. How do you select the candidate technologies for the solution?

  10. What is the difference between the network topology and the data topology of the deployment model?

  11. What is the difference between the distribution strategy and the packaging strategy?

  12. What is the difference between cohesion and coupling?

  13. What is the purpose of a programming model?

  14. What is a component interface?

  15. What are the various types of users of the user services layer of an application?


Chapter 7: Designing the Presentation Layer

Chapter 7
Designing the Presentation Layer
About This Chapter

You have learned the process of designing a business solution, focusing on the envisioning phase and planning phase, which includes the conceptual, logical, and physical design processes. However, the design of any system that will be used by users is not complete without a way for users to interact with that system. User interaction takes place by means of the application’s presentation layer. You design the user interface of an application during the physical design process.

Figure 7.1 illustrates where the design of the presentation layer fits into the MSF Process Model.

Figure 7-1 Where are you in the process?
Figure 7-1. Where are you in the process?

In this chapter, you will learn about designing the presentation layer of an application. You will also learn about the two pieces of the presentation layer—the user interface (UI) components and the user process components—and how to design them.

Before You Begin

To complete the lessons in this chapter, you must

  • Understand the MSF Process Model.

  • Be familiar with the MSF design process.


Lesson 1: Basics of User Interface Design

In this lesson, you will learn about the basics of user interface design, including the various types of user interfaces, the goals of the user interface design process, and the characteristics of a good user interface design.

After this lesson, you will be able to

  • Explain the functions of user interface components.

  • Determine the guidelines for user interface design.

  • Identify some metaphors and elements that can be used in user interface design.

  • Distinguish between a well-designed and poorly designed user interface.

Estimated lesson time: 20 minutes
What Is the Presentation Layer?

The presentation layer is the part of the business application that provides a communication mechanism between the user and the business service layer of the system.

Elements of the presentation layer

Simple presentation layers contain user interface components that are hosted in a graphical user interface (GUI) such as Microsoft Windows® Forms or Microsoft ASP.NET Web Forms. For more complex user interactions, you can design user process components to orchestrate the UI elements and control the user interaction, as shown in Figure 7.2.

User process components are especially useful when there is a specific process that must be followed and access to that process varies depending on the user. For example, a retail application might require two user interfaces: one for the e-commerce Web site that customers use, and another for the Windows Forms–based applications that the sales representatives use. Both types of users perform similar tasks by using these user interfaces. Both user interfaces must provide the ability to view the available products, add products to a shopping cart, and specify payment details as part of a checkout process. This process can be abstracted in a separate user process component to make the application easier to maintain.

Figure 7-2 Presentation layer
Figure 7-2. Presentation layer
Inputs to the presentation layer design

The information that you researched, analyzed, and optimized during the envisioning and planning phases is the input for the design of the presentation layer. This information includes:

  • Solution requirements and constraints

  • Usage scenarios

  • Workflow models

  • User profiles

  • Task descriptions

What Is a User Interface Component?

The first area of the presentation layer that you will learn about is the user interface. In some ways, this interface could be considered the most important part of the business application because, to most users, it is the application. A well-designed user interface helps to ensure the success and acceptance of a business application.

User interface components manage interaction with the user. They display data to the user, acquire data from the user, interpret events that are caused by user actions, change the state of the user interface, and help users view progress in their tasks.

User interface components perform view or control roles, or both, in the Model-View-Controller (MVC) pattern. The MVC pattern divides an application, or even an application’s interface, into three parts: the model (application object), the view (representation to the user), and the controller (user control).

TIP
Separation of model, view, and controller provides greater flexibility and possibility for reuse.

A component plays a view role when it displays data to users. Control functions are called when the user performs an action that changes the state of the related business data in the user interface process. A control function is a method that performs an action based on the user interface component that the user acted on, and the data that was provided at the time the action was initiated.

What Are the Functions of the User Interface Components?

User interface components display data to users, acquire and validate data from user input, and interpret user actions that indicate the user wants to perform an operation on the data. Additionally, the user interface should filter the available actions to let users perform only the operations that are appropriate at a certain point in time.

User interface components perform the following functions:

  • Acquire data from users and assist in its entry by providing visual cues (such as ToolTips), validation, and the appropriate controls for the task.

  • Capture events from the user and call controller functions to notify the user interface components to change the way they display data, either by initiating an action on the current user process or by changing the data of the current user process.

  • Restrict the types of input a user can enter. For example, the Age field might limit user entries to whole numeric values.

  • Perform data entry validation, for example, by restricting the range of values that can be entered in a particular field, or by ensuring that mandatory data is entered.

  • Perform simple mapping and transformations of the information provided by the user controls to values needed by the underlying components to do their work. For example, a user interface component might display a product name but pass the product ID to underlying components.

  • Perform formatting of values (such as formatting dates appropriately).

  • Perform any localization work on the rendered data, for example, using resource strings to display column headers in a grid in the appropriate language for the user’s locale.

  • Provide the user with status information, for example, by indicating when an application is working in disconnected or connected mode.

  • Customize the appearance of an application based on user preferences or the kind of client device used.

NOTE
In addition to the listed functions, user interface components also help manage the flow of actions needed to perform a task, control resource usage, group information to aid user understanding, convert tabular data into graphical form to help users interpret it, and support local caching for performance improvements.
Guidelines for User Interface Design

Designing a user interface that provides a good user experience requires knowledge and understanding of the users’ needs and workflow. You accumulate this information during the envisioning and planning phases.

Guidelines

The design of the interface must implement the users’ tasks in a way that is intuitive to the user. This goal is accomplished by including users in all stages of the design of the user interface. Prototyping, beta testing, and early adoption programs are methods for involving the user during the design and implementation of the UI.

The success or failure of an application might depend on the user interface. If users have difficulty using the interface, they see their difficulties as a failure of the application. Designing and developing a user interface that truly meets the needs of users involves asking user-focused questions and incorporating the answers in your design.

Designer’s questions

Some design questions to consider include:

  • How are users going to interact with the system?

  • Does the interface represent the concepts and terminologies of the users?

  • Are appropriate metaphors used in the design of the user interface?

  • Do the users have the control that they require to override automated processes when needed?

  • Can users easily find the features required to complete common tasks?

  • Is the workflow correct and complete?

  • Does the interface optimize the workflow of the users?

  • Can users easily access help for specific problems?

  • Are users able to customize the UI to meet their particular needs?

  • Are there alternative ways to perform a specific task in case a problem arises, for example, if a mouse gets disconnected from the computer?

What Features Does a Well-Designed Interface Include?

Users judge an application by its interface. If the interface fails to provide a good experience to the users, the overall effort of application development is wasted. However, do not compromise functionality to make the application interface user-friendly. Getting users to accept an interface requires that the users’ needs and workflow be taken as a primary consideration during its design and development. You want to ensure that the UI is accessible by all users, including users with physical, visual, or auditory disabilities.

The following features help make an interface effective.

  • Intuitive design. Design the interface so that a user can intuitively understand how to use it. An intuitive design helps a user become familiar with the interface more quickly. The interface should guide the user’s interactions with the application. To make an effective interface, label controls appropriately and make Help context-sensitive.

  • Optimum screen space utilization. Determine the content of the interface by planning the amount of information that is displayed and the amount of input required from the user. When possible, place all related information and input controls on the same screen. Sometimes, there is too much information for one screen. In such cases, provide tabbed panes or child windows. You could also provide a wizard that guides a user through the data input process.

  • Appearance. You can use factors, such as the frequency and length of time that a user will interact with a specific piece of the interface, to determine the appearance of the interface.

    For example, when you design Windows-based applications for data entry, do not use bright colors because bright colors strain the eyes. Also, refrain from using colors to indicate specific things, such as red for error messages, because the user might change the color settings because of accessibility or cultural requirements.

    You can, however, use bright colors for Web-based interfaces to make them attractive. For example, when designing confirmation and status pages, you might use bright colors to attract the user’s attention to the information. Users tend to spend more time on data input screens than they do on confirmation and status screens. Following accepted guidelines and standards, such as those in the article Official Guidelines for User Interface Developers and Designers on MSDN® (http://msdn.microsoft.com/library/en-us/dnwue/html/welcome.asp), will help you succeed in designing a usable user interface.

    More Info
    For more information about designing user interfaces for applications that run on the Windows operating system, see Microsoft Windows User Experience (Microsoft Press, 1999).

  • Ease of navigation. Because different users prefer different ways of accessing components on an interface, design the components so they are easily accessible by using the Tab key, the arrow keys, and other keyboard shortcuts, in addition to the mouse. Sometimes, as in the preceding data entry example, faster navigation is more important than guided navigation. When designing keyboard shortcuts into the UI, associate the shortcut keys with the action being performed. For example, if you are creating a shortcut that will fill in default data for a product description, a shortcut such as Ctrl+Alt+D might be more intuitive than Ctrl+Alt+P.

  • Controlled navigation. Although it is important for an interface to provide easy navigation, it is also important to maintain the order in which the components can be accessed. For example, in interfaces that are designed for the purpose of data entry and modifications, you might require that the values be entered in a specific order. However, be wary of taking away the user’s feeling of control over the input process.

    One of the key benefits of Windows-based applications is that they typically do not constrain a user to an input sequence, so users have more control. You should also consider adding breadcrumb trail navigation functionality to the interface. This type of navigation shows the path the user has navigated to get to the current position. To see an example of a Web site that uses the breadcrumb trail navigation functionality, see the article The Developing Phase, on MSDN, at http://msdn.microsoft.com/library/en-us/dnsolac/html/m05_develphase1.asp.

  • Populating default value. If the interface includes fields that always take default values, it is better to provide the default values automatically, therefore avoiding the user having to enter anything whenever possible.

  • Input validation. It is important to validate the user input before the application processes the input. You need to determine when validation should occur. For example, determine whether validation should occur every time the user moves the focus from one input field to another, or whether it should occur when the user submits the inputs. Sometimes both approaches can be required if there are data dependencies between fields.

  • Menus, toolbars, and Help. Design the interface to provide access to all of the application’s functionality by means of menus and toolbars. In addition, a Help feature should provide complete information about what a user can do with the application.

    NOTE
    Although menus and toolbars are the primary methods for input, most frequently used features of an application should also have alternative methods of access, such as keyboard shortcuts, in case the primary input device becomes unusable.

  • Efficient event handling. The event-handling code that you write for the components of the interface controls the interaction of the user with the interface. It is important that the execution of such code does not cause the user to wait a long time for the application to respond.


Lesson 2: Designing the User Interface

Now that you have learned the basics of designing a user interface, the next step is to learn about the process. In this lesson, you will learn about the process of designing a user interface, and about the deliverables of this process.

After this lesson, you will be able to

  • Create an initial user interface design.

  • Distinguish between a high-fidelity and a low-fidelity design.

  • Design user assistance for an application.

  • Select an appropriate user interface model for an application.

  • Identify the technology options and considerations for a client environment.

  • Validate a user interface design.

  • Identify the deliverables of the user interface design process.

Estimated lesson time: 35 minutes
How to Create an Initial User Interface Design

The first part of designing a user interface is creating an initial design that the users can review. This initial design can be either low fidelity (for example, created with a pencil on paper) or high fidelity (for example, a prototype created with a tool such as Microsoft Visual Basic®), as shown in Figure 7.3.

Figure 7-3 Difference between high fidelity and low fidelity
Figure 7-3. Difference between high fidelity and low fidelity

A low-fidelity design shows the main structure and features of the UI and illustrates the navigation path. This type of design is useful for brainstorming sessions where you will receive immediate feedback. It provides one way to quickly identify design problems and explore alternative designs.

A high-fidelity design provides detailed information about screen layout and interface elements. This type of design is often based on a low-fidelity design. Compared to a low-fidelity design, a high-fidelity design is relatively quick to implement and adjust.

In addition, you can create a navigation map for the user interface. A navigation map shows which component is called for each UI event. To keep the focus on the workflow, do not yet include field validation or error processing.

By involving the users early in the design process and keeping them involved throughout the design process, you mitigate the risk of design flaws and increase the likelihood of designing an interface that the users will find acceptable.

Planning
Consider providing a low-fidelity representation, rather than a prototype, to the users. When the initial design is being created, it is better to create a low-fidelity design. Later, when the design is more complete, you can create prototypes to give a detailed representation of the design to the customers. This approach reinforces that what they are reviewing is truly a design and that they can have an influence on the final version.

These initial designs should use the elements that were agreed upon with the users. They should also incorporate the terminology and concepts of the users. The glossary that you create during the envisioning and planning phases serves as a good starting point for the terminology. However, for a better understanding of the terminologies and concepts, you need to talk to the users.

How to Provide User Assistance

User assistance is frequently neglected, or poorly implemented, in computer applications. There are several options available for providing user assistance in applications.

Online Help

Online Help refers to any help that is immediately available upon user request while the user is interacting with the system. This assistance can be installed with the application, located on a CD, or located on an intranet or the Internet. Online Help is an important part of all applications and provides an effective way to answer user queries.

Online Help can be either context-sensitive or in a reference format. Context-sensitive Help provides information about a specific field or area of the UI. Other Help formats allow the user to read the Help contents in a specific order (by topic or an alphabetized list) or to search for information.

TIP
When designing your Help system, try to include topics that provide answers to task-oriented questions. Task-oriented Help is most useful for less-experienced users.
ToolTips

A ToolTip is a small label that is displayed when a user moves the mouse over a control or an option in the user interface. The label provides a description of the function of the control. ToolTips are normally used in conjunction with toolbars, but they also work well in many other parts of the interface.

TIP
As with other parts of the interface, ensure that the text clearly conveys the intended message to the user.
Status displays

Status displays are a useful way to provide instructions or messages that might not fit easily into a ToolTip. To provide status displays, you can use a status bar control or a label control.

Wizards

A wizard is a user assistance device that guides the user step-by-step through a procedure. Wizards are mostly used to provide task-specific assistance. They help a user complete a difficult task that would otherwise require a lot of time to learn and accomplish. Wizards are also used to provide advanced information to a user who has enough experience with basic steps but wants additional or advanced information.

Accessibility aids

Accessibility aids are specialized programs and devices that help people with disabilities use applications more effectively. There are many types of aids. Some examples include:

  • Screen enlargers that enlarge portions of the screen

  • Screen-reading software that presents graphics and text as speech

  • Speech recognition systems that provide input by using your voice instead of the keyboard or mouse

When designing accessible applications, you should follow certain guidelines. Some examples of accessibility guidelines include:

  • Applications must be compatible with specific system color, size, font, sound, and input settings.

    This guideline provides a consistent user interface across all applications on the user’s system.

  • Applications must provide keyboard access to all features.

    This guideline allows the user to interact with the application without requiring a pointing device, such as a mouse.

  • Applications must not convey information by sound alone.

    This guideline requires that applications that convey information by sound must provide additional means of expressing this information, such as on-screen messages.

More Info
For more information about the guidelines for designing accessible applications, see the MSDN Library (http://msdn.microsoft.com), and the Microsoft Accessibility Web site at http://www.microsoft.com/enable.
How to Select a User Interface Model

When designing an application, it is important to select the best user interface model because the user interface can affect deployment, how users interact and relate to the data, and how the state is maintained while the application is interacting with the user. Some of the common user interface implementation models and technologies include:

  • Windows-based user interfaces

  • Web-based user interfaces

  • Mobile device user interfaces

  • Document-based user interfaces

Windows desktop user interfaces

Windows-based user interfaces are used when you need to provide users with disconnected or offline capabilities and rich user interactions. Windows user interfaces provide a wide range of state management and persistence options, and local processing power. There are three main categories of standalone user interfaces:

  • Full-featured workstation/Tablet PC user interfaces created with Windows Forms. These UIs involve creating an application with Windows Forms and Windows controls. In these applications, the application provides all or most of the data rendering functionality. These UIs give the developer total control over the user experience and the appearance and functionality of the application.

  • Embedded HTML. You can implement the entire user interface by using Windows Forms, or you can use additional embedded Hypertext Markup Language (HTML) in your Windows-based applications. Embedded HTML provides greater run-time flexibility (because the HTML can be loaded from external resources or even a database in connected scenarios) and user customization. Extra coding is necessary to load the HTML, display it, and connect the events from the control with your application functions.

    IMPORTANT
    Careful planning is needed to ensure that malicious scripts cannot be introduced through the embedded HTML.

  • Application add-ins. For some applications, the use cases developed during the planning phases might suggest that the user interface of the application could be better implemented as an add-in for other applications, such as Microsoft Office, AutoDesk AutoCAD software, customer relationship management (CRM) solutions, engineering tools, and so on. In such cases, the developers can use all the data access and display logic of the host application and just provide their business-specific code to gather the data and work with their business logic.

  • Remote access. By using programs such as Windows XP Remote Desktop Connection and Windows Terminal Services, remote users can access remote computers and run applications on them remotely. The only information passed between the client computer and the remote user is the user interface. All other functionality, such as data validation and computations done by the CPU, is performed on the remote computer.

Web-based user interfaces

In Microsoft .NET, you develop Web-based user interfaces with ASP.NET. ASP.NET provides a rich environment in which you can create complex Web-based interfaces that support the following features:

  • Consistent development environment

  • User interface data binding

  • Component-based UIs with controls

  • Integrated .NET security model

  • Rich caching and state management options

  • Availability, performance, and scalability of Web processing

Mobile device user interfaces

Mobile devices such as handheld computers, Wireless Application Protocol (WAP) phones, and Handheld PCs are becoming increasingly popular, and building user interfaces for a mobile device has several challenges.

A user interface for a mobile device needs to be able to display information on a much smaller screen than other common applications, and must offer acceptable usability for the devices being targeted. Because user interaction can be difficult on mobile devices, design your mobile user interfaces with minimal data input requirements. A common strategy is to allow users to pre-register data by means of a workstation-based client, and then select the data when using a mobile client. For example, an e-commerce application might allow users to register credit card details by means of a Web site so that a pre-registered credit card can be selected from a list when orders are placed from a mobile device, thus avoiding the requirement to enter full credit card details by using a mobile phone keypad.

Document-based user interfaces

In some applications, you might benefit from having users enter or view data in document form. Document-based user interfaces include:

  • Showing data. The application allows users to view their data in a document, such as showing customer data as a Microsoft Word form, a sales report as a Microsoft Excel worksheet, or a project timeline as a Microsoft Project Gantt chart.

  • Gathering data. You can allow sales representatives to complete Word forms with customer information, allow accountants to enter data into Excel worksheets, or let designers enter design data with Microsoft Visio®.

How to Select the Client Environment

The selection of a client environment for the user interface of a business application is determined by how the user will be using the application, in addition to how the user will be connected to the systems that support the application.

When users are on a local area network (LAN) or a high-speed wide area network (WAN), the main choice of client is a feature-rich environment known as a rich client. For these users, the communication speed between their computers and the system they are accessing is not a primary issue. This type of client also has the greatest number of options for development and implementation. Additionally, the processing of the application can easily be distributed between the servers and the clients.

Another choice of clients is the thin client. However, thin clients, such as Web browsers and remote desktop connections, are most frequently used for remote or distributed users, or users with slower connections such as a dial-up modem. These users are frequently concerned with communication speed and require a user interface that sends the minimum amount of information possible over their connections. These users might benefit from a rich client if the business requires functionality that is not available otherwise.

You should take the following factors into account when deciding whether to create a thin-client or a rich-client application.

NOTE
This choice between thin and rich clients is also known as the choice between reach clients and rich clients.

  • Client devices. An application that must be used on a wide variety of client devices is ideally suited to being a thin-client application. If the application must run on Windows-based computers but must also run on computers and are not running Windows, or on PDAs, telephones, or interactive televisions, the application will typically be a thin client.

    You must use special care in these situations when using heterogeneous systems because the client might have limitations. For example, a browser might be unable to host ActiveX® controls, or it might not have a Java Virtual Machine. When an application can be hosted in an unknown browser, the ASP.NET server controls can be used because the server will determine the browser’s capabilities and render the controls accordingly. If mobile devices are to be targeted, Mobile Internet Controls must be used for the same reason.

  • Graphics. If an application makes heavy use of highly dynamic graphics, such as computer-aided design (CAD) or video applications, then you need to use a rich client.

    If an application is not heavily graphical and it can avoid using animations and other cosmetic graphical effects, it can work well as a thin client. Dynamic HTML can be used to provide some localized effects, but doing so increases the size of each page. The features that you use depend on the capabilities of the browser that you are targeting.

  • Interaction. If an application is highly interactive and provides the user with a rich experience, it is best suited to being a rich client. Highly interactive applications are those that present a dynamic user interface that changes frequently based on user input (for example, a word processor, a game, or a CAD application), allows drag-and-drop operations, performs immediate inter-control validations, and so on.

  • Network bandwidth. A thin-client application generally uses much more network bandwidth than a locally hosted rich client. This is especially true if the interface uses Web server controls because many mouse clicks result in a round trip to the Web server. This is also true for Terminal Services clients and remote desktop connections because, in the case of remote clients, user interface rendering and responses need to travel across the network. Therefore, if network bandwidth is an issue, a rich client is the preferred choice.

  • Disconnected client. If the client must be able to operate while disconnected from the corporate network, then you use a rich client. This would include applications used by mobile personnel, or by personnel working from customer locations.

  • CPU-intensive operations. If users need to perform operations that require a lot of CPU-intensive work (for example, CAD and graphics applications), these operations should occur on the end-user’s computer; otherwise the operations could quickly overload the server. CPU-intensive applications are best suited to a rich-client environment.

  • Database locking. If the application requires a high degree of concurrency control, a rich client is essential. For example, if an application must use pessimistic locking, it cannot be a thin client because the locks are released after each page has been processed.

  • Local resources. If an application needs access to local resources, such as files (storage), the registry (configuration), databases (storage), or any other local devices, a rich client might be more suitable.

  • Security. In a highly secure environment, a thin-client application has the following benefits:

    • Privileged operations can be confined to the server.

    • Code that could be misused by a malicious user is kept away from workstation computers (as long as active content is avoided).

    • The workstation can be locked down.

    • Sensitive data is not stored outside the data center.

    The following advantages apply to rich-client applications hosted by Terminal Services:

    • Authorization: user-based and code access security-based

    • Authentication

    • Secure communication and state management

    • Auditing

How to Create a User Interface Prototype

After you have made the design decisions for the user interface, you are ready to create a user interface prototype from the gathered interviews, requirements document, use cases, usage scenarios, and activity diagrams created during the planning phase.

Example usage scenario

To learn how to create a user interface prototype, consider the example of the Adventure Works Cycles scenario. The following is a usage scenario that was created based on the use cases defined during early stages of planning for sales representatives and sales managers.

Table 7-1. Adventure Works Cycles Usage Scenario

Use case title: UC 05.5.1 Apply Discount to Product

Abbreviated title: Apply Discount to Product

Use case ID: UC 05.5.1

Requirements ID: 2.1.1, 2.1.2, 2.1.3

Description: A sales representative is creating an order for a specific customer. The representative wants to offer the customer a discount on one or more products in the order. This affects the total order price, and it is the recalculated price that the customer will then pay. Sales managers can also apply discounts to orders.

Sales representatives are currently authorized to apply a discount of up to 15 percent without approval. Sales managers can apply a discount of up to 20 percent.

Actors: Sales Representative, Sales Manager

Preconditions:

  • Actor has access rights to view customer and sales data

  • An order is in the process of being created

Task sequence

Exceptions

1. Actor chooses to apply a discount to an order

Product is not in current view

2. Application requests which order is to be discounted

3. Actor selects the order to be discounted

Any piece of data is not available

4. Application presents order information (including any existing discounts) and requests discount amount

5. Actor enters discount amount

6. Application validates discount amount and presents order information with updated total price

  • If discount amount is over a certain threshold, system reports this fact

  • Use case continues at Step 5 of main path to enable actor to re-enter discount amount

7. Information is passed to a method of delivery

Postconditions :

Uses/Extends:

1. EXTENDS UC 05.5 Apply Discount to Order

Unresolved issues:

Sales Managers have authority to supply a higher level of discount than sales representatives. This is captured in extended use case UC 5.5.1.1.

Authority: Mike Danseglio

Modification history:

Date: December 19, 2002

Author: Yan Li

Description: Initial version

TIP
When designing the user interface, keep in mind the preconditions, the basic course, the alternative courses, and the extensions specified in the usage scenarios. All these factors need to be addressed by the UI.
Example requirements

Following are some of the requirements that were identified and refined during the planning phase for Adventure Works Cycles:

  • Sales representative should be allowed to search the site for information across all products or within a specific catalog.

  • Sales representative should be allowed to view the categories of the product.

  • Sales representative should be allowed to view product details such as pricing and information about promotions.

  • Sales representative should be allowed to view product specifications.

  • Additional navigation links should appear on the page. These links include Home, About Adventure Works Cycles, Track Orders, Shipping Rates and Policies, Contact Us, and a copyright notice.

  • Sales representative should be allowed to view the customer reviews about the product.

  • Sales representative should be allowed to provide discounts of up to 15 percent to the customers.

  • Sales representative can provide discounts from 16 through 20 percent to the customers with prior approval from a sales manager.

  • Sales manager should be allowed to search the site for information across all products or within a specific catalog.

  • Sales manager should be able to view the categories of the product.

  • Sales manager should be able to view product details such as pricing and information about promotions.

  • Sales manager should be able to view product specifications.

  • Sales manager should be able to view the customer reviews about the product.

  • Sales manager should be able to provide discounts of up to 20 percent to the customers.

  • Sales manager can approve discounts of up to 20 percent to the customers.

You need to address the above requirements when you design the user interface for Adventure Works Cycles Web site.

Example UI prototypes

Figure 7.4 is an example of a UI prototype that was created to address the requirements derived from use cases and usage scenarios. This prototype shows the information that a sales representative needs on the product information page.

Figure 7-4 A prototype of the product information page for sales representatives
Figure 7-4. A prototype of the product information page for sales representatives

Figure 7.5 is another example of a UI prototype. This prototype shows the information that a sales manager needs on the product information page.

Figure 7-5 A prototype of the product information page for sales managers
Figure 7-5. A prototype of the product information page for sales managers
How to Validate User Interface Design

As part of the design process, validate that the user interface is addressing the requirements of the users.

After you create the UI prototypes, you need to map the UI back to the requirements, use cases, usage scenarios, and logical design. Ensure that all the requirements are addressed by the user interface. If a requirement has not been addressed in the user interface, you need to address it and incorporate that in the design before you present the prototypes to the customers.

The navigation and flow are validated to ensure that the flow is as expected. The maps should be compared to the future-state usage scenarios to confirm that the user interface is able to handle the scenarios.

The final step of the validation process is to review the design with the users and obtain their agreement that it satisfies their requirements.

The next step is to create prototypes of limited functionality so that the user interface can be validated in usability tests.

What Are the Deliverables of the UI Design Process?

Like all the other processes of designing a business solution, the UI design process has deliverables:

  • The project team, customer, and users should have an agreement on the guidelines for the design, including the elements that are being used in the application. The guidelines, and an identification of common interface elements, should be documented for the development team.

  • The design should include descriptions of how the interface will provide appropriate feedback (such as progress bars) and user assistance (such as ToolTips) to the user.

  • The design produced should be testable by storyboarding and by comparing it against the future-state usage scenarios.


Lesson 3: Designing User Process Components

User interaction with your application might follow a predictable process. For example, the Adventure Works Cycles Web site might require users to enter product details, view the total price, enter payment details, and finally enter delivery address information. This process involves displaying and accepting input from a number of user interface elements, and the state for the process (the products that have been ordered, the credit card details, and so on) must be maintained between each transition from one step in the process to another. To help coordinate the user process and handle the state management required when displaying multiple user interface pages or forms, you can create user process components.

In this lesson, you will learn about the functions of user process components and how to design them.

After this lesson, you will be able to

  • Explain the function of user process components.

  • Separate the user interface from user processes.

  • Design user processes.

Estimated lesson time: 20 minutes
Functions of User Process Components

Separating the user interaction functionality into user interface and user process components provides the following advantages:

  • Long-running user interaction state is more easily persisted, allowing a user session to be abandoned and resumed, possibly even using a different user interface. For example, a customer could add some items to a shopping cart by using the Web-based user interface, and then later call a sales representative to complete the order.

  • The same user process can be reused by multiple user interfaces. For example, in the retail application, the same user process could be used to add a product to a shopping cart from both the Web-based user interface and the Windows Forms–based application.

Figure 7.6 shows how the user interface and user process can be abstracted from one another.

Figure 7-6 User interfaces and user process components
Figure 7-6. User interfaces and user process components

User process components are typically implemented as classes that expose methods that can be called by user interfaces. Each method encapsulates the logic necessary to perform a specific action in the user process. The user interface creates an instance of the user process component and uses it to transition through the steps of the process.

User process components coordinate the display of user interface elements. They are abstracted from the data rendering and acquisition functionality provided in the user interface components. You should design them with globalization in mind, to allow for localization to be implemented in the user interface. For example, you should endeavor to use culture-neutral data formats and use Unicode string formats internally to make it easier to consume the user process components from a localized user interface.

User process components:

  • Provide a simple way to combine user interface elements into user interaction flows without requiring you to redevelop data flow and control logic.

  • Separate the conceptual user interaction flow from the implementation or device in which it occurs.

  • Encapsulate how exceptions can affect the user process flow.

  • Keep track of the current state of the user interaction.

  • Keep internal data related to application business logic and their internal state, persisting the data as required.

How to Separate a User Process from the User Interface

Before you design a user process component, separate user process components from user interface components. It is important to determine what functions can be done by the user interface and what needs to be handled by the user process components.

To separate a user process from the user interface, perform the following tasks:

  1. Identify the business process or processes that the user process will help to accomplish. Identify how the user sees this as a task. You can usually do this by consulting the sequence diagrams, use cases, and usage scenarios that you created as part of your requirements analysis.

  2. Identify the data needed by the business processes. The user process will need to be able to work with this data when necessary.

  3. Identify additional state you will need to maintain throughout the user activity to assist rendering and data capture in the user interface.

  4. Design the visual flow of the user process and the way that each user interface element receives or gives control flow.

NOTE
Implementing a user interaction with user process components is not a trivial task. Before committing to this approach, you should carefully evaluate whether your application requires the level of orchestration and abstraction provided by user process components.
What Are the Guidelines for Designing User Processes?

Use the following guidelines when designing user processes for an application:

  • Decide whether you need to manage user processes as separate components from the user interface components. Separate user processes are generally only needed in applications with a high number of user interface dialog boxes, or in applications in which the user processes might be subject to customization and might benefit from a add-in approach.

  • Choose where to store the state of the user process:

    • If the process is running in a connected fashion, store interim state for long-running processes in a central Microsoft SQL Server™ database; in disconnected scenarios, store it in local XML files, isolated storage, or local Microsoft SQL Server 2000 Desktop Engine (MSDE) databases. On Handheld PC devices, you can store state in a Microsoft SQL Server CE database.

    • If the process is not long-running and does not need to be recovered in case of a problem, you should persist the state in memory. For user interfaces created for rich clients, you might want to keep the state in memory. For Web applications, you can choose to store the user process state in the Session object of ASP.NET. If you are running in a server farm, you should store the session in a central state server or a SQL Server database. A server farm is a grouping of several Web servers used for load balancing. When you implement a Web site on a server farm, the processing load is distributed across different Web servers. ASP.NET will remove unnecessary SQL Server–stored session to prevent the buildup of unwanted data.

  • Design your user process components so that they are serializable. This will help you implement any persistence scheme.

  • Include exception handling in user process components, and propagate exceptions to the user interface. Exceptions that are thrown by the user process components should be caught by user interface components.


Activity: Creating the User Interface

In this activity, you use what you learned in the lessons to work through the process of creating a user interface.

You have been assigned the task of creating a prototype of the product information management tool. The product clerks will use this tool to manage products for the online shopping application. The prototype should be designed in Microsoft PowerPoint®. The requirements for the management tool are as follows:

  • The tool should allow the clerk to look up products by supplying a product identification number or by searching the product database. For searching, clerks should be allowed to specify the catalog in which they want to search, or search for the product across all catalogs.

  • The information for each product should be broken down into separate sections, such as name, description, part number, catalog, pricing, entry date, expiration data, last modified date, pictures, specifications, promotions, and discount. Rather than displaying all this information on a single screen, the clerk should be allowed to select the type of information and work with that specific data.

  • When the clerk wants to add a new product, a new product record must be created and a new product ID must be supplied. The clerk fills in each section of information for the product. Some sections might be optional while others are mandatory. After all the information has been entered, the clerk must explicitly save the new information to the database.

  • When the clerk wants to edit an existing product, the clerk must look up the product in the database, explicitly indicate that changes will be made to the information, select each section of information to change, and make the changes. After all the changes have been made, the clerk must explicitly save the changes to the database.

  • For each section of information, the clerk should be allowed to cancel edits. This should cancel the edits on only that section of data. For example, if the clerk makes changes to the description of a product and then makes changes to the promotional information for the product, the clerk can cancel the changes to the promotional information without affecting the changes made to the description of the product.

  • For each product record that has been added or changed, the user should be allowed to cancel all the entries and changes made since the user last saved the product record.

  • When clerks want to delete an existing product, they must look up the product in the database, explicitly indicate that the record will be deleted, and confirm that the record should be deleted. The record is deleted from the database by changing its expiration date to a date that occurred in the past.

Be sure to point out the functionality that can be accessed on the page and what each area of the user interface provides to the user. After you have designed the user interface, compare it to the preceding requirements. To see one possible solution to this exercise, open C07Ex1_Answer.ppt, which is located in the \SolutionDocuments\Chapter07\ folder on the CD.


Summary

  • Design of any application is not complete without a way for users to interact with the system. User interaction takes place through the application’s presentation layer. The presentation layer is the part of the application that provides a communication mechanism between the user and the business service layer of the system.

  • The most simple presentation layers contain user interface components, such as Windows Forms or ASP.NET Web Forms. For more complex user interactions, you can design user process components to orchestrate the user interface elements and control the user interaction.

  • User interface components display data to users, acquire and validate data from user input, and interpret user gestures that indicate the user wants to perform an operation on the data. Additionally, the user interface should filter the available actions to let users perform only the operations that are appropriate at a certain point in time.

  • The features of a good user interface include:

    • Intuitive design

    • Optimum screen space utilization

    • Ease of navigation

    • Controlled navigation

    • Input validation

    • Menus, toolbars, and Help

    • Efficient event handling

  • There are several types of user interface models:

    • Windows desktop user interfaces

    • Web-based user interfaces

    • Mobile device user interfaces

    • Document-based user interfaces

  • User assistance in an application can be provided by using any or all of the following options:

    • Online Help

    • ToolTips

    • Status displays

    • Wizards

    • Accessibility aids

  • User process components are typically implemented as .NET classes that expose methods that can be called by user interfaces. User process components coordinate the display of user interface elements. They are abstracted from the data rendering and acquisition functionality provided in the user interface components.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What is the function of the presentation layer in the business application architecture?

  2. What are the features of a good user interface?

  3. What are the differences between a high-fidelity and low-fidelity design?

  4. What are some of the options that application developers can use to design user assistance for an application?

  5. What are the various types of user interface models, and when should you use them?

  6. Describe the difference between a user interface component and a user process component. Describe a situation in which you would use a user process component.

  7. How do you separate user interface from user process?

  8. Your design calls for the use of Windows Terminal Services. What kind of user interface will you create to implement this design?

  9. During the envisioning and planning phases, you determined that the users of the solution will be using a wide variety of hardware, will be located at various remote locations, and will not all have access to the company’s intranet. What type of client lends itself to these constraints?

  10. After your design of the user interface is complete, what are some of the ways you can validate the design before implementing it?


Chapter 8: Designing the Data Layer

Chapter 8
Designing the Data Layer
About This Chapter

During the planning phase of the Microsoft® Solutions Framework (MSF) Process Model, the project team designs the data layer of the solution, along with the presentation and business layers. In this chapter, you will learn about designing the data layer for a solution. You will also learn about optimizing data access and implementing data validation in the solution.

Before You Begin

To complete the lessons in this chapter, you must

  • Be familiar with the various phases of the MSF Process Model.

  • Understand the envisioning phase of the MSF Process Model.

  • Understand the tasks and deliverables of the conceptual and logical design processes of the planning phase.

  • Understand how to design the presentation layer and business layer of a solution in the physical design process.


Lesson 1: Designing the Data Store

The data layer of a solution consists of a data store and data services. The data store is typically a database in which data is organized and stored. In this lesson, you will learn about data models and how data is structured in various data models. You will learn how to identify entities and attributes in a data model. You will also learn how to derive tables and columns for a data store and implement relationships among various entities.

After this lesson, you will be able to

  • Describe a database schema.

  • Identify entities and attributes.

  • Identify tables and columns for a data store.

  • Implement relationships.

Estimated lesson time: 20 minutes
What Is a Database Schema?

Throughout the planning phase, the project team focuses on analyzing requirements and designing the solution that meets those requirements. Therefore, in addition to identifying the features of the solution, the project team analyzes the data requirements of the solution and specifies how data will be structured, stored, accessed, and validated in the solution.

Research and analysis of data requirements begins during the conceptual design process. These requirements help determine what actually needs to be stored and processed by the business solution. During logical design, the project team derives a set of data entities from sources that include the logical object model, usage scenarios, and data artifacts such as data schema, triggers, constraints, and topology from any existing data store. During physical design, the team defines tables, relationships, field data types, indexes, and procedures to create a database schema, and finalizes data services. In addition, the team plans how to provide for data migration, backup and recovery, and failover support.

Definition of database schema

A database is defined as a collection of data values that are organized in a specific manner. A database schema specifies how data is organized in a database. During the physical design process, the members of the project team create a database schema so that they can focus on what must be built before they focus on how to build it.

During the logical design process, the team describes the entities and attributes that will be stored in the database, and how the users will access, manipulate, and browse through the data. During the physical design, the team creates the database schema that provides specifications for creating, reading, updating, and deleting data that is used in a solution.

When the team begins to design the database schema, the schema has a close relationship with the logical object model. The schema defines the main entities of interest to the problem, the attributes of those entities, and the relationships between entities. Most data modeling techniques define an entity as an abstraction of something in the real world. You learned to derive entities and attributes of those entities while defining the object model for a solution.

NOTE
The final production schema might not resemble the logical object model.

Figure 8.1 shows part of the database schema for the Adventure Works Cycles system.

Typically, database objects are modeled in an entity relationship (ER) diagram. The ER diagram consists of entities, attributes, and relationships. It provides a high-level logical view of the data. In an ER model, all data is viewed as stating facts about entities and relationships.

NOTE
You will learn more about entities, attributes, and relationships in the subsequent topics in this chapter.
Figure 8-1 Partial database schema for the Adventure Works Cycles system
Figure 8-1. Partial database schema for the Adventure Works Cycles system
Types of physical data models

In addition to defining the logical database design, you must select a technology for physically storing data. The physical data model of a database management system (DBMS) defines the internal structure that the DBMS uses to keep track of data. The structure reflects the types of database tables that you can create, as well as the speed of access and versatility of the database. The various types of physical data models that commonly exist are:

  • Flat-file. A flat-file database stores all data in a single file as a set of rows and columns. There is no relationship between multiple flat-file databases because each database exists without knowledge of any other database. They can provide fast updates and retrieval because they support an indexing method called the indexed sequential access method (ISAM). Legacy mainframe databases, as well as smaller PC-based databases, implement ISAM storage technology.

  • Hierarchical. Hierarchical databases store a wide range of information in a variety of formats. Therefore, they are extensible and flexible. You use this type of database when information storage requirements vary greatly. An example of a hierarchical database is Microsoft Exchange, which can store varying types of information in a format that facilitates messaging and collaboration applications that require many types of information to be encapsulated in messages.

  • Relational. In a relational model database, data is stored in multiple tables and columns. Relational databases combine the advantages of both flat-file and hierarchical databases by providing good performance and flexibility of storage. The relational model tends to be the most popular because tables can be linked together with unique values. It is important to understand, however, that the other models are still in use and that developers who are working in enterprise environments will likely need to interface with one of these other types of databases at some time. The relational model focuses on storing data, retrieving data, and maintaining data integrity. Related items of data can be retrieved efficiently by using Structured Query Language (SQL), regardless of whether the items are stored in one table or in many tables. Data integrity is maintained by applying rules and constraints.

  • Object-oriented. In an object-oriented database, database objects appear as programming language objects, in one or more existing programming languages. The object-oriented database management system (ODBMS) extends the language with transparently persistent data, concurrency control, data recovery, associative queries, and other database capabilities. You use an ODBMS if you need to store complex data and require high performance. Complex data is characterized by lack of natural, unique identification, many-to-many relationships, and frequent use of type codes as used in relational models.

At Adventure Works Cycles, the data storage technology currently being used is Microsoft SQL Server 7.0. After looking at the long-term requirements for data storage, the project team chose Microsoft SQL Server 9.0 for this solution. The completed application will convert the existing data store to allow for several improvements. Therefore, the physical model selected for the Adventure Works Cycles system is the relational model. The physical model reflects the target implementation environment.

How to Identify Entities and Attributes

In the logical design process, the project team analyzes use cases and usage scenarios to identify entities and attributes. These entities and attributes form the basis for logical design and are used in the physical design process to model the physical design of the solution. The logical design helps ensure that the data design for the solution represents and maps to the conceptual requirements. However, the actual structures that are used to store the data are optimized for the environment in which the physical data model will be implemented.

Guidelines for deriving entities

When identifying entities for the purpose of logical data design, keep in mind that entities are:

  • Objects about which information will be stored. Some examples of entities are Product, Order, and Customer.

  • The starting point for the logical data design. The identification of these entities is the first step in the design of a database.

  • The equivalent of rows in one or more database tables. An instance of an entity corresponds to a row of a table.

Consider the following use cases:

Employee creates a contract with the client.
Employee reviews prior billings to the client.

Based on these use cases, you identify the following objects:

  • Employee. The employee performs actions within the system.

  • Client. Client is the recipient of actions that are performed by the employee.

  • Contract. The agreement between the employee and the client.

  • Billings. Invoices that the client has received for work performed.

In addition to being objects in the object model of the solution, the preceding entities are used in the logical data design. The database for the solution must store information for every instance of the Employee, Client, Contract, and Billings entities that are within the scope of the solution. Remember that the entity description helps determine relationships between the entities.

Characteristics of attributes

After identifying the entities, you must determine the attributes that you want to capture in the database. Attributes have the following characteristics:

  • Attributes describe a solution entity. For example, the attributes of a car can include its color, make, model, and year of production. Although size is a characteristic of a car, it is not related to the solution and is not included as an attribute.

  • Attributes exist only when attached to an entity. For example, the attribute of color does not describe anything tangible unless the color is applied to an object.

  • Attributes define the columns in database tables. When the physical design is implemented, the attributes become the columns in the database tables. They are fully described by type, length, and any applicable relationships.

For example, the entity Client has the attributes account number, name, and address. You must store this information for each instance of the Client entity.

How to Identify Tables and Columns

During physical design, the outputs of logical design are used to produce components, user interface specifications, and physical database design. The entities, attributes, and constraints derived during logical design are mapped to tables, fields, relationships, and constraints in a database. This database physically represents the logical model.

Definition of tables

Tables are the physical representation of entities in a relational database. Tables can store a wide variety of data. A table can contain names, addresses, pictures, audio files, video files, Microsoft Word documents, and so on. Because of this flexibility, a database can be used to store not only simple text data, but also the knowledge base of a business, no matter what form that knowledge takes. A database represents the relationships between various data items.

The data in a table is stored in rows, or records. Each record must be unique. Records in a relational database can be manipulated by using Extensible Markup Language (XML). XML can be used to transmit data between databases, and different enterprises, without aligning the table structures of the two communicating databases.

A traditional method of manipulating relational data is by using the American National Standards Institute (ANSI) standard relational database language, which is referred to as SQL. SQL is an English-like language that abstracts the operations that are performed on a database into easily readable statements, such as Insert, Update, and Delete. Most databases adhere to the ANSI SQL standard, although the version and enhancements that are used vary from product to product.

TIP
Tables can be linked to other tables within the same database file. This capability allows one type of data to be joined to another type and allows data normalization.
Definition of columns

The data in each record is stored in columns, or fields, that are specified from the attributes of the table’s defining entity. Each field contains one distinct item of data, such as a customer name.

Example of tables and columns

Consider the Adventure Works Cycles system. One of the entities in the system, SalesOrderDetail, maintains details about an order placed by a customer. The attributes of this entity include SalesOrderID, ProductID, AddressID, UnitPrice, and DueDate. Corresponding to this entity and its attributes, the Adventure Works Cycles database includes a table named SalesOrderDetail that contains the following columns: SalesOrderID, ProductID, AddressID, UnitPrice, and DueDate.

Purpose of data types

Data types specify the kind of data that is stored in a field. Every field within a database must have a data type. The data type allows you, and the database engine itself, to verify that a value entered in a field is valid for the information that the field represents. Remember that a valid data type does not ensure valid data. For example, an integer data type field can store numeric data. According to the business rules, the field values can range from 1 through 20. If a user inputs 25, the value is a valid entry by type but it is not valid data.

The data types that are allowed for a given field depend on the data types that are supported by the hosting DBMS. When defining your tables, choose data types that will optimize performance, conserve disk space, and allow for growth. Most DBMSs support two major classifications of data types:

  • System-supplied data types. Every DBMS contains its own data types. Examples of system-supplied types are Integer, Character, and Binary. Some DBMSs contain variations of these types as well as additional types.

  • User-defined data types. Some DBMSs allow you to define your own data types based on the system-supplied types. For example, in Microsoft SQL Server, you can define a state data type with a length of 2 that is based on the character data type. Defining this data type helps maintain conformity across all tables that include a state field. In every table, any field of state data type would be consistent and identical.

Table 8.1 shows a set of common data types, each of which is a variation on a generic character, number, or binary data type.

Table 8-1. Common Data Types
Data type | Description
Binary | Fixed or variable length binary data
String | Fixed or variable length character data
Date | Date and time data
Float | Floating point numeric data (from -1.79E+308 through 1.79E+308 in Microsoft SQL Server 2000)
Decimal | Fixed precision and scale numeric data (from -10^38 + 1 through 10^38 - 1 in SQL Server 2000)
Integer | Integer (whole number) data. Different DBMSs have different variations with upper limits at 255, 32,767, or 2,147,483,647
(Long) Integer | Integer value of longer ranges than the Integer type listed above
Monetary | Currency values with fixed scale
(Double) Float | Float value with double-precision data range over regular Float data type

Data types also specify how data is displayed. For example, fields of the Float, Money, and Integer data types all store numeric data. However, each type of data is stored, calculated, and displayed in a different format. Because their data is stored in different formats, different data types consume different amounts of storage space.

NOTE
The double variants of a data type can store a number that is twice as large or store a fraction to more decimal places, but they typically use twice as much storage space.

During physical design, you must consider the requirements of each data object and choose the smallest possible data type that will accommodate every possible value for that object or attribute. Each data storage technology—including Microsoft SQL Server, Oracle Database, Sybase Adaptive Server Enterprise, IBM DB2 and Informix, and the NCR Teradata Warehouse—defines its own data types.

Table 8.2 illustrates the columns and their data types, using SQL data types, of the ProductMaster table in the Adventure Works Cycles database.

Table 8-2. ProductMaster Table
Columns | Data type | Allow nulls
ProductID | uniqueidentifier | Not allowed
Name | text | Not allowed
ProductNumber | text(25) | Allowed
DiscontinuedFlag | bit | Allowed
MakeFlag | bit | Not Allowed
StandardCost | money | Allowed
FinishedGoodsFlag | bit | Not Allowed
Color | text(15) | Allowed
CreatedDate | datetime | Not Allowed
ModifiedDate | datetime | Allowed
SafetyStockLevel | smallint | Allowed
ReorderPoint | smallint | Allowed
ListPrice | money | Allowed
Size | text(50) | Allowed
SizeUnitMeasureCode | char(3) | Allowed
ProductPhotoID | int | Allowed
rowguid | LongBinary | Allowed
WeightUnitMeasureCode | char(3) | Allowed
Weight | float | Allowed
DaysToManufacture | int | Allowed
ProductLine | char(2) | Allowed
DealerPrice | money | Allowed
Class | char(2) | Allowed
Style | char(2) | Allowed
ProductDescriptionID | int | Allowed
ProductSubCategoryID | smallint | Allowed
ProductModelID | int | Allowed
Types of keys

Keys are an important part of a relational database. Keys uniquely identify each instance of an entity within the data model. Keys also provide the mechanism for tying entities together.

A relational database might use several types of keys:

  • Primary keys that uniquely identify each row of data in a table. To assign the primary key of a table, identify the attribute that is unique for each instance of the entity. For example, SalesOrderID is unique for each order and is the primary key for the SalesOrderHeader table. In some cases, you might need to create a new attribute to accomplish this. Most DBMSs provide several mechanisms for creating primary keys, including auto-generation of unique identifiers and the ability to create composite keys, which enforces uniqueness across two columns, such as SalesOrderID and LineNumber in the SalesOrderDetail table).

    NOTE
    Another frequent practice is to use smart keys, in which the key has some relation to the domain data—for example, using BLDG001 to identify records in a table storing building information.

  • Foreign keys that link two tables. For example, ProductID is a foreign key in the SalesOrderDetail table. The attribute ProductID is the primary key in the ProductMaster table and links the SalesOrderDetail and ProductMaster tables. This allows the SalesOrderDetail table to refer to a product by its unique ID, thereby avoiding redundant product data such as name and description in the two tables.

ON THE CD
For the complete database schema of the Adventure Works Cycles database, refer to Adventure Works Cycles Data Schema.vsd in the \SolutionDocuments\Chapter08 folder on the CD.
How to Implement Relationships

Various relationships can exist between database tables. Just as the entities and attributes that are identified during logical design are represented as tables and columns in physical design, the relationships that are identified during logical design must be represented in the database during physical design.

In the physical database design, you represent relationships between entities by adding the keys from one entity table to other entity tables so that the entities are bound together by the common key value.

A relationship can represent one of the following multiplicities:

  • One-to-one relationship

  • One-to-many relationship

  • Many-to-many relationship

One-to-one relationship

In a one-to-one relationship, an instance of one entity is directly related to the corresponding instance of the other entity. For example, every department can have only one faculty member as the head of the department. In addition, a faculty member can be the head of only one department. If both entities are required for the relationship, the entities and their relationship can be represented in one of three ways:

  • As one table. You can combine two entities into one table and use the primary keys as a composite key of the combined tables. The advantage of combining the entities into one table is that you do not need to maintain separate tables. This technique eliminates the need for query parsers to deal with a join condition. It also uses space storage more efficiently. The disadvantage is that if the relationship changes some time in the future, reversing this design decision might be costly.

  • As two tables. You can keep each entity in its own table and add the primary key of one entity as a foreign key of the other entity. Often, there is an implied parent-child relationship between entities. In such situations, you should add the primary key of the parent entity as a foreign key in the child entity because the child entity needs the parent entity to exist. This arrangement forces the database to allow only unique entries in each key field and helps to ensure that each instance of one entity can relate to only one instance of the other entity.

  • As multiple tables. If the relationship between the entities is optional and the parent entity can exist without a related instance of the child entity, you should create a separate table for each entity and use foreign keys to implement the relationship. For example, consider an organization that assigns cars to employees and provides insurance policies for both the driver and the car. There might be a situation when no car is assigned to an employee or a car has no assigned driver. In addition, the insurance policy might not exist as yet. Therefore, the relationship between the three entities is optional. You can use three tables and create a join table containing all three keys or implement two foreign keys in each table.

Figure 8.2 illustrates the one-to-one relationship between two tables.

Figure 8-2 One-to-one relationship
Figure 8-2. One-to-one relationship
One-to-many relationship

The physical design of a one-to-many relationship requires that you define tables for a parent entity such as Customer and a child entity such as Order, where many child entities can exist for each parent entity. It requires the use of foreign keys in the child entity that determines the existence of the relationship. Enforcing the relationship involves confirming that the foreign key is a valid parent entity.

NOTE
A one-to-many relationship is used frequently in data design because it tends to use storage space efficiently.

Figure 8.3 illustrates the one-to-many relationship between two tables.

Figure 8-3 One-to-many relationship
Figure 8-3. One-to-many relationship
Many-to-many relationships

Most relational database systems, including SQL Server, cannot directly represent a many-to-many relationship, except by using denormalization. (You will learn more about normalization in Lesson 2.) Many DBMSs work around this problem by using a new table, called a join table, to hold information that maintains the relationship between the entities.

In Figure 8.4, the Employee and Client entities have a many-to-many relationship. A single Employee can contract with many Clients, and a single Client can have contracts with many Employees. Because this relationship cannot be expressed directly, each entity’s primary key is used as a foreign key in a separate Contracts table. This foreign key pair uniquely identifies the relationship between the Employee table and the Client table.

Figure 8-4 Many-to-many relationship
Figure 8-4. Many-to-many relationship


Lesson 2: Optimizing Data Access

The goal of optimization is to minimize the response time for each query and to maximize the throughput of the entire database server by minimizing network traffic, disk I/O, and processor time. This goal is achieved by understanding the application’s requirements, the logical and physical structure of the data, and the trade-offs between conflicting uses of the database, such as a large number of write-intensive insertions and heavy read-intensive queries.

In this lesson, you will learn about the guidelines for optimizing data access. You will also learn about optimizing data access by indexing, partitioning, normalizing, and denormalizing data.

After this lesson, you will be able to

  • List the best practices for optimizing data access.

  • Describe the impact of indexing data.

  • Describe the purpose of partitioning data.

  • Describe the purpose of normalizing data.

Estimated lesson time: 10 minutes
What Are the Best Practices for Optimizing Data Access?

Performance issues should be considered throughout the development cycle and not at the end when the system is implemented. Data access performance affects the overall performance of the application. You can achieve significant performance improvements by optimizing both application and database design from the beginning.

Optimize the application

When you design an application that accesses a database, consider the following coding guidelines:

  • Minimize roundtrip requests for result sets.

  • Minimize the amount of data involved in a result set.

  • Reduce concurrency (multiple users editing the same record) and resolve conflicts efficiently.

  • Carefully evaluate the tradeoffs between managing data results on the client or on the server, especially for Web-based applications.

Stress test the application

The only way you can understand the behavior of your application is to run it under a moderate load with a test tool such as the Microsoft Web Application Stress tool, and then execute the application. You cannot adequately determine where bottlenecks exist in your application unless you test it under load. It is usually a better practice to stress test your application than it is to stress test your users.

Use transactions wisely

Transactions should be short-lived and incorporate only what is required. Distributed transactions require significant overhead that can adversely impact application performance. As such, they should be used only when necessary.

Communicate effectively across boundaries

Any cross-boundary communication that occurs between applications or processes adversely impacts performance. You can minimize this impact by minimizing the number of transitions that occur. For example, it is more efficient to call a method requiring six input parameters than it is to set six properties and then call the method. This design pattern promotes the use of a stateless business logic layer.

Optimize the database

The most commonly used techniques to optimize data access include:

  • Indexing data

  • Partitioning data

  • Normalizing data

NOTE
You will learn about these techniques in detail in the next few topics in this lesson.

To remove bottlenecks while accessing and writing to the database, you can perform the following steps:

  • Identify potential indexes, but do not index excessively.

  • If using Microsoft SQL Server, use SQL Server Profiler and Index Tuning Wizard.

  • Monitor total processor usage; desired range is 75 to 80 percent processor time.

  • Analyze query plans by using Query Analyzer to optimize queries.

  • Use stored procedures to maximize performance.

  • Normalize data that is written frequently.

  • Denormalize data that is read frequently.

How to Index Data

You need to optimize a system for both accessing and updating data. Indexing is one of the most commonly used techniques for optimizing data access. An index is an ordered list of rows in a table that a DBMS can use to accelerate lookup operations.

Purpose of an index

An index is structured like a tree and maintains a sorted list of a specific set of data. Queries performed on indexed data are much faster and more efficient than queries on data that is not indexed. Rather than scanning an entire table each time a value is needed, the DBMS can use the index to quickly lead the query to the direct location of the required data because the index records the location of the data in the table.

Benefits of indexing

Some of the benefits of indexing include:

  • Faster data access. Indexes in databases are similar to indexes in books. In a book, an index allows you to find information quickly without reading the entire book. In a database, an index allows the DBMS to find data in a table without scanning the entire table.

  • Data integrity. Some DBMSs allow indexes to ensure the uniqueness of each record of a table.

Types of indexes

To optimize retrieval of data, you can use two types of indexes:

  • Clustered. A clustered index physically reorders the rows of data in the table to match the order of the index. It is a very high-performance index for read operations. A clustered index is usually defined as a table’s primary index. (Most DBMSs allow only one clustered index per table.) For example, the SalesOrderDetail table uses the columns SalesOrderID and LineNumber as the clustered index. One limitation of clustered indexes is that they can slow down writes because rows might be physically rearranged frequently.

  • Nonclustered. A nonclustered index simply maintains a small table of index information about a column or group of columns. A table can have many nonclustered indexes.

How to Partition Data

Often, the number of records stored in a table increases to a level at which data optimization techniques can no longer help improve data access speed. In such a situation, you must partition the tables. You can implement horizontal or vertical partitioning of large data tables to increase processing speed.

Horizontal partitioning

In horizontal partitioning, you divide a table containing many rows into multiple tables containing the same columns. However, each table contains a subset of the data. For example, one table might contain all customer names with last names beginning with the letters A through M, and another table contains all customer names with last names beginning with the letters N through Z.

Vertical partitioning

In vertical partitioning, you divide a table containing many columns into multiple tables containing rows with equivalent unique identifiers. For example, one table might contain read-only data, whereas the other table contains updateable data. In a large data environment, partitioning can extend across several database servers to further distribute the workload.

How to Normalize Data

Normalization is the process of progressively refining a logical model to eliminate duplicate data from a database. Normalization usually involves dividing a database into two or more tables and defining relationships among these tables.

Database theorists have evolved standards of increasingly restrictive constraints, or normal forms, on the layout of databases. Applying these normal forms results in a normalized database. These standards have generated at least five commonly accepted normal form levels, each progressively more restrictive on data duplication than the preceding one.

TIP
Typically, you work toward achieving the third normal form because it is a compromise between too little normalization and too much.
Benefits of normalization

Normalized databases typically include more tables with fewer columns than non-normalized databases. Normalizing a database accomplishes the following:

  • Minimized duplication of information

    A normalized database contains less duplicate information than a non-normalized database. For example, you need to store timesheet and invoice information in a database. Storing timesheet information in the Invoice table would eventually cause this table to include a large amount of redundant data, such as employee, job, task, and client information. Normalizing the database results in separate, related tables for timesheets and invoices, thus avoiding duplication.

  • Reduced data inconsistencies

    Normalization reduces data inconsistencies by maintaining table relationships. For example, if a client’s telephone number is stored in multiple tables or in multiple records within the same table, and the number changes, the telephone number might not be changed in all locations. If a client’s telephone number is stored only once in one table, there is minimal chance of data inconsistency.

  • Faster data modification, including insertions, updates, and deletions

    Normalization speeds up the data modification process in a database. For example, removing client names and address information from the Invoice table results in less data to track and manipulate when working with an invoice. The removed data is not lost because it still exists in the Client table. Additionally, reducing duplicated information improves performance during updates because fewer values must be modified in the tables.

NOTE
Normalization can reduce performance for write operations due to locking conflicts and the potential of increased row sizes after the write.
The first normal form

The first step in normalizing a database is to ensure that the tables are in first normal form. To accomplish this step, the tables must adhere to the following criteria:

  • Tables must be two-dimensional and have data organized as columns and rows. Entities specified in the logical data model are transformed into database tables represented in a two-dimensional table, similar to a spreadsheet.

  • Each cell must contain one value.

  • Each column must have a single meaning. For example, you cannot have a dual-purpose column such as Order Date/Delivery Date.

Figure 8.5 shows the Timesheet table, which was not originally in first normal form. The original Timesheet table had no unique identifier and not all of its attributes were singularly tied to one piece of information. Also, each column in the Timesheet table could have multiple meanings. In the first normal form, the Employee attribute can be divided into two distinct attributes: EmployeeFirstName and EmployeeLastName.

Figure 8-5 First normal form of the Timesheet table
Figure 8-5. First normal form of the Timesheet table
The second normal form

The second normal form is a bridge process that eventually leads to the third normal form. To move a data design to second normal form, you must look at several instances of an entity and move any redundant data within an entity’s attributes to a separate table.

  • Eliminate redundant data within an entity.

  • Move attributes that depend on only part of a multivalue key to a separate table.

  • Consolidate information when possible.

Figure 8.6 shows the Timesheet table. If a client moves to a different city, the client database must be updated, as well as every timesheet that references that client. The solution is to remove the client information from the Timesheet table and replace the information in the Timesheet table with a ClientID foreign key that corresponds to the ClientID primary key of the Clients table. The Timesheet table can then find the client’s name and address by means of the foreign key relationship. When the address of a client changes, the change is recorded in the Client table only. Similarly, the second normal form replaces the employee information with an EmployeeID foreign key that links the timesheet to the individual employee who enters information into the timesheet. The second normal form also eliminates any other duplicate information. The JobName and JobDesc attributes have been replaced with a single attribute, JobDesc, because the job description would likely contain the job name. This logic also applies to the TaskName and TaskDesc attributes.

Figure 8-6 Second normal form of the Timesheet table
Figure 8-6. Second normal form of the Timesheet table
The third normal form

Third normal form is the level to which most design teams strive to normalize their data designs. Third normal form eliminates any columns that do not depend on a key value for their existence. Any data not directly related to the entity is generally moved to another table. Third normal form is generally the final form that you should implement.

  • Eliminate any columns that do not depend on a key value for their existence.

  • Generally, move any data not directly related to the entity to another table.

  • Reduce or eliminate update and deletion anomalies.

  • Verify that no redundant data remains.

Third normal form helps to avoid update and deletion anomalies because all data can be reached by means of foreign key values, and redundant data within each table no longer exists. This level of normalization greatly increases database robustness and generates a more optimized design.

Figure 8.7 shows the Timesheet entity that has been normalized to third normal form. All attributes that do not depend on the primary key have been moved into separate tables, and foreign keys now take the place of unrelated data. This form, like second normal form, further eliminates update and deletion anomalies because all data can be directly referenced from one point, instead of residing in multiple tables within the database.

Figure 8-7 Third normal form of the Timesheet table
Figure 8-7. Third normal form of the Timesheet table
Denormalization of Tables

Optimizing the physical data design for updates is a common practice. In many systems, data changes frequently, and having a system optimized for this activity is important.

A database design that is based solely on normalization rules produces a large number of narrow tables. This design technique reduces data redundancy and decreases the number of pages on disk that are required to store the data. However, complex joins are required to retrieve data.

Denormalization is the process of reversing normalization to generate tables with more fields that require fewer joins. Depending on the type of queries and updates that are being performed on the database, denormalization can dramatically increase its overall performance. For this reason, denormalization is a common optimization technique even though some DBMS systems include an optimizer that enables joins to be performed efficiently.

When deciding whether to use denormalization as an optimization technique, keep the following issues in mind:

  • The data becomes more redundant. Related data is moved into one table to increase query performance and reduce disk access times.

  • The number of tables is reduced, which makes query programming and administration easier. The disadvantage is that the data is located in fewer places, thus creating tables with more fields and possibly duplicating data across tables.

  • Data that appears in more than one place can get out of synchronization if it is updated in one table and not others.

Although there are tradeoffs between a highly normalized physical data design and an intelligently denormalized design, a strategy of selective and intelligent denormalization most often results in the greatest performance gains.

Data that is over-normalized can cause performance issues in certain types of applications and can adversely affect read and write operations. Normalizing the ER model is a major step in creating the logical database design. The goal of normalization is to ensure that there is only one way to know a fact. It eliminates redundancy in the data and ensures that the correct business rules are recorded. The logical database design is implementation-independent—without details of a specific DBMS. However, for this discussion, a relational model is assumed.

During physical design, the database team must consider the following:

  • Physical database constraints, such as memory and disk size.

  • Performance tuning considerations, such as deadlock detection, indexing, and hot spots.

  • Primary keys and foreign keys.

  • Design of triggers.

  • Stored procedures guidelines.

  • Normalization. Although the third normal form is often appropriate, evaluate fourth and fifth normal forms if justified by the target data.

  • Application object model considerations. Some tables that do not appear in the logical data model might be required to support the application.

  • Data migration from any legacy database systems.

  • Quality of existing data.

  • Operational considerations, such as cluster/failover, backup process, and update/deployment process.


Lesson 3: Implementing Data Validation

In addition to the performance of the database, you need to ensure the quality of the data stored by the database. This means that the database implements data integrity and stores valid data that conforms to the business rules.

In this lesson, you will learn about data integrity requirements of the solution. You will also learn how to identify business rules and implement them in the database and the business layer.

After this lesson, you will be able to

  • Define data integrity.

  • Identify data integrity requirements.

  • Identify business rules.

  • Implement business rules in a database.

  • Implement business rules as components.

Estimated lesson time: 15 minutes
What Is Data Integrity?

Data integrity refers to the consistency and accuracy of data. An important step in database planning is deciding how to ensure this integrity. You can implement three types of data integrity in a database: domain, entity, and referential.

Domain integrity

Domain integrity specifies a set of valid data values for a column and determines whether null values are to be allowed. You can enforce domain integrity by implementing validity checking and restricting the data type, format, or range of possible values that are allowed in a column. For example, you must store discount rates. According to business rules, the discount rate must be between 2 percent and 18 percent. In addition, the discount rate cannot be zero because it causes errors in calculations.

Entity integrity

Entity integrity requires that each row in a table has a unique identifier, known as the primary key value. Whether the primary key value can be changed, or whether an entire row can be deleted, depends on the level of referential integrity that is required between the primary key of the table and the foreign keys of any other tables. For example, a customer record must have a primary key. If there is a business need for the key to be changed, such as a merger, or for the record to be inactivated but not deleted, the business rules determine your choices in entity and referential integrity.

When used together, domain and entity integrity help to ensure that each entity in a physical design maintains consistency. When planning for databases in your design, you must consider consistency among entities and data validity within the entities as important additional aspects of data integrity.

Referential integrity

The domain and entity integrity categories suffice for enforcing data integrity in a single table. However, many databases contain multiple tables with parent and child entities and are related. When both entities in a relationship must exist and must have a valid link with one another, referential integrity ensures that these conditions are met. Referential integrity ensures that the relationships between the primary keys (in the parent entity’s table) and foreign keys (in the child entity’s table) are always maintained.

As a result of the restrictions that referential integrity imposes on tables, it is important that you consider what to do when a primary key must be updated or deleted. If the primary key value in the parent entity is changed or deleted, the instance of that entity is modified. Consequently, all child entities that referenced the parent entity must be modified as appropriate. By cascading through all related child tables and updating or deleting data as necessary, the database can maintain referential integrity.

Data validation

It is important to have valid data. Domain, entity, and referential integrity ensure that data exists where necessary and that entities follow a basic set of rules for existence. None of these data integrity categories, however, can determine whether the data is valid. You can ensure that the data is correct by checking it using the following methods:

  • Range checking involves making sure that the data’s value is within a set of limits determined by the functional specification.

  • Data format checking involves making sure that the data conforms to a set of format specifications, such as currency formatting, telephone number formatting, or length-of-character strings.

  • Data type checking involves making sure that the data belongs to the proper data type and that an invalid data type is not used to represent the data when it is written to the database.

To ensure that queries return correct information, you must make sure that the information being stored is valid. You can validate data in two ways:

  • Client-side checks can ensure that invalid data is not posted to a database. These checks can be coded in many ways, including in scripts, in the user interface controls, as part of an executable program, or as part of a Web page. For example, if a field on a Web page denotes a monetary value, validation controls on the page can ensure that the information in that field is the proper data type and format.

  • Server-side checks, which are executed by the DBMS engine, can be implemented with field data types, default values, and constraints. These checks can also ensure that invalid data is not stored in the database.

The methods or combination of methods that you use depends on the objectives and requirements of the solution. Although more difficult to maintain than server-side checks, client-side checks can help decrease the processing load on the DBMS server. Server-side checks might present a bottleneck if the server has to validate many client requests. Remember that a strong test process is needed to verify that the business rules have been correctly implemented while maintaining a high quality of user experience.

How to Identify Data Integrity Requirements

Identifying data integrity requirements helps ensure that all logical and physical requirements for a solution are met and that the physical design supports the full intent of your specification.

When attempting to identify the data integrity requirements of a solution, you must start with the data requirements specified during the solution’s design. When you examine the data requirements, identify areas within the requirements in which uniqueness, or limits and constraints, has been specified or deemed necessary to help ensure that entities can exist and be implemented correctly.

If limits and constraints are specified, you must determine whether the limits and constraints are bound to an entity or to a relationship between entities. Consider the following examples:

  • You need to determine whether a particular task can exist without a related job number. If it cannot exist without a job number, you must implement a data integrity requirement to ensure that no instance of that task is created without a corresponding job number.

  • A consultant must submit a weekly timesheet for a client. No timesheet can duplicate another timesheet, and no two timesheets can represent the same time or work performed by a consultant. Therefore, a data integrity requirement exists for guaranteeing the uniqueness of timesheet information. Each timesheet within the database must be represented by a unique attribute or a combination of unique attributes.

Finally, you must implement referential integrity requirements to ensure that all relationships are maintained. For example, if a customer wants to be removed from the database, a referential integrity requirement must ensure that the customer cannot be deleted as long as payment has not been received for any outstanding invoices.

How to Identify Business Rules

Business rules form a foundation for encapsulating logic from the data requirements into the solution. Business rules represent logic specified within a solution.

The data development team already identified many of the business rules for the solution while identifying requirements. The team must reexamine the solution’s data requirements for the criteria that the data integrity rules must satisfy. The team should also review any existing process documentation, use cases, and usage scenarios to identify the data-centric processes that are currently being executed and the processes that must be executed in the future.

While identifying business rules, consider the following criteria:

  • Conditions that must be satisfied for data to be considered valid. For example, issues that you might consider when determining applicable business rules include whether a product can be shipped to a customer if no payment has been received.

  • Conditions that must be avoided. For example, issues you might consider include whether product pricing can drop below certain levels or whether inventory levels for products can drop below zero.

  • Sequences in which events must occur. For example, you must determine what to do when an inventory product drops below zero or when payment for an order is received.

You can implement business rules and data integrity requirements by using the following methods:

  • Directly in the database. Most DBMSs provide automated processes that can be bound to tables and columns to enforce business rules and data integrity requirements.

  • Programmatically within or outside the database. You can code business rules and data integrity requirements into client applications, create components that can be deployed on application servers, or use programming logic and languages that are part of the database engine.

The primary distinction between these two methods is that the former involves rules that are automatically processed by the database engine, whereas the latter involves rules that must be called or invoked by an application’s logic.

Determining where to implement rules is often based on the nature of the required programming logic. Most relational database engines now execute automatic methods that incorporate simple and commonly required application logic. This logic applies to specific business rule tasks and resides in a single location. It is also easily updated and efficient to execute. If more complex logic is required, it can be implemented as application code that can reside in any of the three service layers: user, business, or data.

How to Implement Business Rules in a Database

If you choose to implement business rules directly in the database, the DBMS performs much of the work for you by using its automatic and built-in checks.

Within the database engine, business rules and data integrity requirements can be enforced through a set of criteria that data must either meet or not meet. Usually, most of the data integrity requirements are implemented by using the automatic controls and properties of the database engine. This automatic control involves the specification, or declaration, of the criteria at the time an object (such as a field, table, index, or key) is created.

Database features for implementing business rules

Enforcing data integrity through built-in database features has some distinct benefits: integrity is enforced automatically, and the criteria do not have to be maintained or updated unless they change. You can use the following database features to enforce data integrity:

  • Data types. Setting appropriate data types for the fields in a database ensures that incorrect types of data cannot be added to the table. For example, if a data type of Date is specified, the database rejects any string or numeric value that is not in a date format. Data types ensure that the format of the data is valid, but it cannot ensure that the value is valid.

  • Default values. Default values specify the values to be used for a field when the values have not been explicitly supplied in INSERT statements. By using default values in your table definitions, you can ensure that a field value is valid even when a user does not explicitly supply it.

  • Data validation rules. Data validation rules encapsulate logic for specifying data values that are acceptable in a table’s fields. They can specify the length of a field, an input mask, or a range of valid values. For example, you can use data validation rules for making simple comparisons.

  • Keys. Most database engines can automatically monitor referential integrity between tables. The primary and foreign key relationships from the physical model directly correspond to the database engine’s key settings. These key settings automatically enforce referential integrity between linked tables.

  • Triggers. Triggers are sets of programmatic statements that are explicitly defined for a particular table. When a specific action (such as an insert, update, or delete) occurs in that table, the trigger causes the statements to automatically run. For example, a trigger can verify data in other tables or perform an automatic update to a different table.

Programmatic implementation of business rules

The team’s analysis will determine that certain business rules are best implemented in the business layer and others in the data layer. You can implement business rules programmatically in the data layer by using the following methods:

  • Stored procedures. Stored procedures are named collections of SQL statements that are stored on the DBMS. They are precompiled, eliminating the need for the query analyzer to parse the statement every time the stored procedure is called. By using stored procedures, you can write one piece of code that performs an action, store it, and call it repeatedly as necessary.

    Stored procedures are useful for controlling changes to a table. For example, instead of granting a user update rights to a specific table, you can allow updates to the table only through stored procedures. You can then determine whether the modifications are valid and then either disregard or apply the change.

    The flow of a process can also be handled through the use of stored procedures. For example, you can change or reorder several tables by using a stored procedure. You can also use stored procedures to perform administrative tasks.

  • Scripts. Typically, you write a script in a database to automate a process that is either impractical or inefficiently handled by the DBMS engine. For example, you might write a script that maintains a database by importing a series of mainframe downloads, re-indexing the database, and then copying a report file to another file server.

    The script logic can be written in any of several languages. Each script executes outside the memory space of the DBMS and might perform more tasks than simply manipulating data. Scripts are generally used in a command-line environment or as part of a batch process that performs other tasks.

How to Implement Data Validation in Components

In a multitier application, a data service acts as an intermediary between the application’s business services and its data store. Therefore, if there are any changes to the data store, the application’s business services do not need to be changed. Data services perform basic tasks such as creating, retrieving, updating, and deleting data. Data services are also used to manipulate data within the database and to implement data integrity. You can design and develop components to implement data services in an application.

Components are executable collections of code that reside on a server or within another program. Components are similar to scripts, but allow for tighter integration with development environments, database engines, and custom code.

You can enforce data integrity through logic that is encapsulated in a component and is called or invoked as needed. The criteria for the logic are determined by the business rules, including any additional data integrity requirements that have been identified for the solution.

Typically, components are deployed on application servers, on a separate computer. Some of the benefits of deploying components on application servers include:

  • Easier maintenance. Because the code is stored in only one or a few locations, it is much easier to maintain than if it were included in the application itself. The increased cost of an application server might be offset by the maintainability of the system. Any necessary changes can be made on only one or a few computers, as opposed to possibly thousands of clients.

  • Scalability. As the load on the system increases, additional application servers can be added to distribute the load.

Implementing business rules by using components can increase the overall cost of the solution. The added cost is associated not only with the hardware and software of the computers serving as the application server, but also in the development costs of creating and maintaining the code that will serve the data access requests.


Activity: Creating a Data Schema

In this activity, you use what you learned in the lesson to create a data schema.

Exercise 1: Creating a Data Schema

This exercise builds on the Adventure Works Cycles scenario. Customers of Adventure Works Cycles use the Sales Order form to order products. Some of the considerations for order processing are:

  • The customer provides a purchase order number to start an order.

  • An order can be revised.

  • Discounts are applied per item in an order.

You need to design a data schema for capturing all information in the Sales Order form. The data schema should include:

  • One or more tables that store order-related data

  • Primary and foreign keys

  • Data types for all columns

  • Indexes

  • Fields needed for data or business requirements

To get started with this exercise, use the data schema that is provided on the P08 Schema Starter tab in the file C08Ex1.vsd in the \SolutionDocuments\Chapter08 folder on the CD. To view the Sales Order form, open the file C08Ex1.doc in the \SolutionDocuments\Chapter08 folder on the CD.

You can view one of the probable solutions to this exercise in the file C08Ex1_ShortAnswer.vsd in the \SolutionDocuments\Chapter08 folder on the CD. You can also design a detailed data schema as illustrated in the file C08Ex1_LongAnswer.vsd in the \SolutionDocuments\Chapter08 folder on the CD. To view the data schema for the complete Adventure Works Cycles system, open the file Adventure Works Cycles Data Schema.vsd in the \SolutionDocs\Chapter08 folder on the CD.


Summary

  • In the planning phase, the project team analyzes the data requirements of the solution and specifies how data will be structured, stored, accessed, and validated in the solution.

  • A database schema reflects the entities of the problem, attributes of the entities, and the relationships between entities.

  • The physical data model of a DBMS defines the internal structure that the DBMS uses to keep track of data.

  • The three physical data models that are typically used are flat files, the hierarchical model, and the relational model.

  • The entities and attributes that are derived during logical design are mapped to tables, fields, and relationships in a database.

  • Tables are the physical representation of entities in a relational database.

  • Columns are the physical representation of attributes in a relational database.

  • Data types specify the kind of data that is stored in a field and how the data is displayed.

  • Keys uniquely identify each instance of an entity within the data model.

  • Primary keys uniquely identify each row of data in a table.

  • Foreign keys link two tables in a database.

  • Relationships between entities are represented by adding the keys of one entity table to other entity tables.

  • To optimize the performance of a database, you need to:

    • Optimize your database.

    • Stress test the application.

    • Use transactions wisely.

    • Communicate effectively across borders.

  • An index is an ordered list of rows in a table that a DBMS can use to accelerate lookup operations.

  • You can optimize processing speed of huge tables by partitioning data, either vertically or horizontally.

  • In horizontal partitioning, you segment a table containing a large number of rows into multiple tables containing the same columns.

  • In vertical partitioning, you segment a table containing a large number of columns into multiple tables containing rows with equivalent unique identifiers.

  • Normalization is the process of progressively refining a logical model to eliminate duplicate data and wasted space from a database.

  • Normalization results in reduced data inconsistencies and faster data modification.

  • Denormalization is the process of reversing normalization to generate tables with more fields that require fewer joins, which can improve query processing.

  • Data integrity refers to the consistency and accuracy of data.

  • Domain integrity specifies a set of legitimate data values for a column and determines whether null values are to be allowed.

  • Entity integrity requires that each row in a table has a unique identifier, known as the primary key value.

  • Referential integrity ensures that the relationships between the primary keys (in the parent entity’s table) and foreign keys (in the child entity’s table) are always maintained.

  • Identifying data integrity requirements helps ensure that all logical and physical requirements for a solution are met and that the physical design supports the full intent of your specification.

  • Identifying business rules includes identifying conditions that must be met, conditions that must be avoided, and sequences in which events must occur.

  • You can implement business rules in a database by using the built-in checks of the DBMS engine, such as data types, data validation rules, default values, keys, and triggers.

  • You can implement business rules in a database programmatically by using stored procedures and scripts.

  • You can implement business rules by using components that are deployed on application servers.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. How is the data model designed during the planning phase?

  2. What is the purpose of the database schema?

  3. What are the characteristics of attributes?

  4. What is the purpose of specifying data types in a database?

  5. How do most DBMSs support a many-to-many relationship?

  6. How do you optimize transactions for good system performance?

  7. What is the impact of indexing on data access?

  8. What is the difference between horizontal and vertical partitioning?

  9. What are the benefits of normalization?

  10. What is denormalization?

  11. What are the three types of data integrity that can be enforced in a database?

  12. How do you identify data integrity requirements?

  13. What are the criteria for identifying business rules?

  14. How do keys implement referential integrity?

  15. What are the benefits of using components to implement business rules?


Chapter 9: Designing Security Specifications

Chapter 9
Designing Security Specifications
About This Chapter

In this chapter, you will learn how to design security in an application. Designing security features and policies is one of the most important aspects of application development. As the amount of money that is spent on securing corporate networks increases, so do the losses that are accrued by businesses in terms of stolen intellectual property, system downtime, lost productivity, damage to reputation, and lost consumer confidence. It is possible, however, to defend your business applications in this hostile environment by adding the appropriate authentication and authorization schemes, ensuring data integrity with encryption, and performing data validation.

Before You Begin

To complete the lessons in this chapter, you must have

  • A general understanding of Microsoft® technologies.

  • Familiarity with security concepts.


Lesson 1: Overview of Security in Application Development

You can secure your application by employing several security mechanisms, such as firewalls, proxies, secure channels, and authentication schemes. However, all it takes for a security breach to occur is for an attacker to find one weakness in your system. In this lesson, you will learn about some common security weaknesses in applications and how some malicious users exploit these security weaknesses. You will also learn about some drawbacks of the traditional security models. You will then learn about some important principles of secure coding.

After this lesson, you will be able to

  • Identify some of the common security vulnerabilities of applications.

  • Identify some of the drawbacks of traditional security models.

  • Explain some of the security principles for designing secure applications.

  • Define some security terms.

Estimated lesson time: 15 minutes
Common Types of Security Vulnerabilities

Malicious attackers use various methods to exploit system vulnerabilities to achieve their goals. Vulnerabilities are weak points or loopholes in security that an attacker exploits to gain access to an organization’s network or to resources on the network. Some vulnerabilities, such as weak passwords, are not the result of application or software development design decisions. However, it is important for an organization to be aware of such security weaknesses to better protect its systems. Common vulnerabilities of applications include:

  • Weak passwords. A weak password might give an attacker access not only to a computer, but to the entire network to which the computer is connected.

  • Misconfigured software. Often the manner in which software is configured makes the system vulnerable. If services are configured to use the local system account or are given more permissions than required, attackers can exploit the services to gain access to the system and perform malicious actions on the system.

  • Social engineering, A common form of discovering passwords that generally occurs when users are not aware of security issues and can be deceived into revealing their passwords. For example, an attacker posing as a help desk administrator might persuade a user to reveal his or her password under the pretext of performing an administrative task.

  • Internet connections. The default installation of Internet Information Services (IIS) version 5.0 often enables more services and ports than are necessary for the operation of a specific application. These additional services and ports provide more opportunities for potential attacks. For example, modem connections bypass firewalls that protect networks from outside intruders. If an intruder can identify the modem telephone number and password, the intruder can connect to any computer on the network.

  • Unencrypted data transfer. If the data sent between a server and the users is in clear text, there is a possibility that the data can be intercepted, read, and altered during transmission by an attacker.

  • Buffer overrun. Malicious users probe applications looking for ways to trigger a buffer overrun because they can use a buffer overrun to cause an application or an operating system to crash. They can then find more security weaknesses by reading error messages.

  • SQL injection. SQL injection occurs when developers dynamically build SQL statements by using user input. The attacker can modify the SQL statement and make it perform operations that were not intended.

  • Secrets in code. Many security problems are created when a malicious user is able to find secrets that are embedded in code, such as passwords and encryption keys.

More Info
For more information about security issues, refer to the Microsoft Windows Security Resource Kit (Microsoft Press, 2003).
Drawbacks of Traditional Security Models

Traditional security models do not adequately meet the security challenges presented by the networked computing environment. Most traditional security models restrict access to resources based on the identity of the user who is running the code. There is no specific mechanism in this model to restrict resources based on the identity of the code.

Security that is based on user identity is circumvented if a trusted user unknowingly runs malicious code. A trusted user can inadvertently launch malicious code by:

  • Opening an e-mail attachment.

  • Running a script that is embedded on a Web page.

  • Opening a file that was downloaded from the Internet.

Principles for Creating Security Strategies

To design a secure application, you should be familiar with the following principles of security and employ them when creating security strategies:

  • Rely on tested and proven security systems. Whenever possible, you should rely on tested and proven security systems rather than creating your own custom solution. Use industry-proven algorithms, techniques, platform-supplied infrastructure, and vendor-tested and supported technologies. If you decide to develop a custom security infrastructure, validate your approach and techniques with expert auditing and security review organizations before and after implementing them.

  • Never trust external input. You should validate all data that is entered by users or submitted by other services.

  • Assume that external systems are not secure. If your application receives unencrypted sensitive data from an external system, assume that the information is compromised.

  • Apply the principle of least privilege. Do not enable more attributes on service accounts than those minimally needed by the application. Access resources with accounts that have the minimal permissions required.

  • Reduce available components and data. Risk will increase with the number of components and amount of data you have made available through the application, so you should make available only the functionality that you expect others to use.

  • Default to a secure mode. Do not enable services, account rights, and technologies that you do not explicitly need. When you deploy the application on client or server computers, its default configuration should be secure.

  • Do not rely on security by obscurity. Encrypting data implies having keys and a proven encryption algorithm. Secure data storage will prevent access under all circumstances. Mixing up strings, storing information in unexpected file paths, and so on, is not security.

  • Follow STRIDE principles. Each letter in the STRIDE acronym specifies a different category of security threat: spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. These are classes of security vulnerabilities a system needs to protect itself against.

More Info
For more information about security practices, see Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, 2002).


Lesson 2: Planning for Application Security

Before you start planning for security features in an application, you must understand the kinds of threats an application is likely to encounter so that you can specify and develop the appropriate security features. Planning for security in applications involves the following tasks:

  • Identify the threats to the application (Threat modeling). This is the most important task in planning for security. Without first identifying the threats, the security policies cannot be determined. When assessing threats to your application, gather the following information:

    • What are the assets of the organization that need to be protected?

    • What are the threats to each of the assets?

  • Create a security policy to prevent or minimize the threat. After most of the threats are identified, you need to categorize these threats and define a strategy for each type of threat. You will learn more about mitigation techniques later in this lesson.

    You can use various techniques to identify and categorize threats. One commonly used technique of identifying threats is STRIDE. In this lesson, you will learn about threat modeling with STRIDE.

After this lesson, you will be able to

  • Identify the security tasks performed during various stages of the Microsoft Solutions Framework (MSF) design process.

  • Explain threat modeling.

  • Create a threat model.

  • Use the threat model to respond to a threat.

Estimated lesson time: 15 minutes
Security in the Application Development Process

Application security fails most often because security is not planned from the very beginning of product design. If you wait to think about security until the late phases of development, security will be less effective and development and maintenance costs will be higher.

The planning and implementation of security features should persist throughout product development. Table 9.1 shows each phase in the MSF Process Model and the corresponding security initiative.

Table 9-1. Security Initiatives and the MSF Process Model
Phase | Security initiative
Envisioning | Gather security requirements. The team talks to the customers and stakeholders to learn about sensitive data and operations, privileges each user needs, and how the application currently manages these security requirements. From this information, security requirements are established and listed in the requirements document.
Planning | Create a threat model, discussed in the What Is the STRIDE Threat Model? section, to anticipate security threats. In the functional specification, propose security features that mitigate each identified risk.
Developing | Implement security features as identified in the functional specification.
Stabilizing | Conduct security testing. Revise the threat model if new information about threats is uncovered by research, testing, and customer feedback.
Deploying | Monitor security threats to an application.

After the solution is released to the customer, security and any attacks to the solution are monitored to ensure that the product remains secure. If any breaches occur, the problem is resolved and the circumstances are noted for the next version of the product.

What Is the STRIDE Threat Model?

The STRIDE threat model is a technique used for identifying and categorizing threats to an application. Each letter in the STRIDE acronym specifies a different category of security threat: spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Most security threats combine more than one element of the STRIDE model:

  • Spoofing identity

    A malicious user poses as a trusted entity. For example, a malicious user might obtain the password of a trusted user to gain access to restricted materials or to send an e-mail message that appears to come from a trusted source.

    NOTE
    IP spoofing is a special case of spoofing identity. It happens when a malicious user inserts a false Internet Protocol (IP) address into an Internet transmission so that the transmission appears to originate from a trusted source. In this way, the malicious user can gain unauthorized access to a computer system.
  • Tampering

    A user gains unauthorized access to a computer and then changes its operation, configuration, or data. Tampering can be either malicious or accidental. For example, accidental tampering can occur when users inadvertently delete files on a network or change a database that they should not have permission to change.

  • Repudiation

    A system administrator or security agent is unable to prove that a user—malicious or otherwise—has performed some action. For example, a malicious user can repudiate having attacked a system because the system did not adequately log events leading to the attack.

  • Information disclosure

    An unauthorized user views private data, such as a file that contains a credit card number and expiration date.

  • Denial of service

    Any attack that attempts to shut down or prevent access to a computing resource. Denial-of-service (DoS) attacks can cause:

    • An application or the operating system to stop functioning

    • The CPU to engage in long, pointless calculations

    • System memory to be consumed so that the functioning of applications and the operating system is impaired

    • Network bandwidth reduction

  • Elevation of privilege

    A user gains access to greater privileges than the administrator intended, creating the opportunity for a malicious user to launch attacks of every other category of security threat.

How to Create a Threat Model

Creating a threat model is a first step in building a secure application. This process involves the following tasks:

  1. Arrange for a brainstorming meeting.

    Invite experienced developers and members of every MSF role to the brainstorming session to identify potential threats.

  2. List all the possible threats.

    During the brainstorming meeting, provide participants with a proposed list of features and describe the architecture of the product. Instruct the participants to think of threats that might occur between application components and to connections between your application and other systems.

  3. Apply the STRIDE security categories.

    After you create an initial listing of possible security threats, use the STRIDE threat model to categorize the threats.

  4. Create notes.

    For each security threat, your group should create a note that includes the following information:

    • Type of threat

    • Impact of the attack to the organization in terms of cost and effort

    • The technique that will be used by the attacker to carry out the threat

    • The likelihood of the attack taking place

    • Possible techniques to mitigate this attack

  5. Conduct research.

    Inevitably, factual and technical questions will be raised during the brainstorming process. If you conduct your meeting in a facility that can access the Internet, you might be able to resolve research questions during the meeting.

  6. Rank the risk of each threat.

    Assign each threat a risk rank by dividing the criticality of the threat by its chance of occurrence.

Example

Figure 9.1 depicts a Web-based expense report application. You will create a threat model for this application.

Figure 9-1 Employee expense report application
Figure 9-1. Employee expense report application
Threats and their categories

Table 9.2 lists possible threats to the expense report application that were identified during a brainstorming meeting. It also lists their categorization based on the STRIDE model.

Table 9-2. Threats to the Expense Report Application.
Threat | Category
The time reporting and employee information databases are vulnerable to direct access, which could allow unauthorized users to view and modify confidential data such as historical data. | T, I
The database server can become unavailable if it is flooded with Transmission Control Protocol/Internet Protocol (TCP/IP) packets. | D
Audit logs can be viewed, modified, and deleted by unauthorized users or applications. | T, R
Lightweight Directory Access Protocol (LDAP) authentication packets can be intercepted and viewed. Based on the information in each packet, the perpetrator might be able to figure out how to impersonate another user on the system. For example, the perpetrator might be a computer operator but might be able to act as the chief financial officer. | S, I, E
The data that is exchanged between the Web browser and the Web server is vulnerable to being viewed by an unauthorized user. This might compromise sensitive information such as passwords, employee IDs, employee information, salary information, and time reporting information. | T, I
The Web server can be become unavailable. If the Web server is shut down, an unauthorized server can be installed in its place, therefore compromising information that is sent from the browser. | S, T, I, D, E
The Web pages that are rendered to the browser might be altered to include viruses and worms. If the browser displays the Web page, the virus or worm can be invoked and possibly damage the user’s machine. | T, D
How to Use a Threat Model

After you have identified the threats, you must decide how to respond to each threat identified in the threat modeling exercise. You can respond to a threat in several ways:

  • Inform users about the threat. If a security weakness is created when the user performs some action, it can be appropriate to warn the user. For example, in Microsoft Windows XP, users who choose the option that displays protected operating system files are warned that doing so poses a risk to those files. In this case, the threat of tampering results primarily from enabling the user to access and potentially damage operating system files.

  • Remove features. If you know of a feature that will introduce a significant security risk, and the risk cannot be mitigated effectively, consider whether the feature is worth including in the final version of the product.

  • Identify a mitigation technique. If you must include a feature that introduces a security risk, you must choose a technique that mitigates the risk. There are several techniques for mitigating threats.

Incorporating Mitigation Techniques

Mitigation techniques can be divided into two categories, general techniques and techniques for the STRIDE model. Table 9.3 describes some of the general mitigation techniques used for resolving threats.

Table 9-3. Mitigation Techniques

Technique

Description

Authentication and authorization

Authentication is the process by which an entity verifies that another entity is who or what it claims to be. Authorization is the process of determining access to resources.

Secure communication

You must ensure that communication between the tiers of your application is secure to avoid attacks in which data is tampered with while it is being transmitted or is being stored in a queue. For secure communication use:

Secure Sockets Layer (SSL). SSL is used to establish an encrypted communication channel between client and server.

IPSec. IPSec can be used to secure the data sent between two computers; for example, an application server and a database server.

Virtual private networks (VPNs). A VPN lets you establish a point-to-point IP transport over the Internet (or other networks).

Quality of service(QoS)

Implements profiling on the messages that are sent to your system.

Throttling

Limits the number of messages sent to your system. If there is no control over the rate at which messages are sent, a target can be inundated with more messages than it can handle.

Auditing

The process of collecting information about user activities and important events and storing the information for analysis at a later stage. Auditing is also commonly known as logging. Windows event logs allow your applications to record information about important events. You can use these records to audit access to your system and troubleshoot problems.

Filtering

The process of intercepting and evaluating messages sent to your system.

Least privilege

Provides users with the minimum level of privilege that will allow their work to be completed, and no more.

Table 9.4 includes a partial list of threat mitigation techniques as applied to various STRIDE threats.

Table 9-4. Mitigation Techniques for STRIDE Threats
Mitigation technique | Type of threat
Authentication | S, D
Protect secrets | S, I
Audit trails | R
Do not store secrets | S, I
Privacy protocols | I
Authorization | T, I, D
Hashes | T
Message authentication codes | T
Digital signatures | T, R
Tamper-resistant protocols | T, R
Time stamps | R
Filtering | D
Throttling | D
Quality of service | D
Run with least privilege | E
More Info
For more information about threat modeling and mitigation technologies for some common threats, see Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, 2002).


Lesson 3: Using .NET Framework Security Features

This lesson describes the important security features in the .NET Framework.

More Info
For more information about creating secure Microsoft ASP.NET applications, see the article “Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication” under .NET Security on the MSDN® Web site (http://msdn.microsoft.com).
After this lesson, you will be able to

  • Define type safety verification.

  • Define code signing.

  • Define encryption and data signing.

  • Define code-access security.

  • Define role-based security.

  • Define isolated storage.

  • Explain the security features of .NET Web technologies.

Estimated lesson time: 20 minutes
What Is Type Safety Verification?

Type safety verification plays a crucial role in assembly isolation and security enforcement.

Definition of type-safe code

Any code that accesses only the memory it is authorized to access is called type-safe code. For example, type-safe code does not access values from the private fields of another object.

Code that is not type-safe can cause security threats to an application. For example, unsafe code might access and alter native (unmanaged) code and perform malicious operations. Because the code is unsafe, the runtime is unable to prevent the code from accessing the native code. However, when code is type-safe, the security enforcement mechanism of the runtime ensures that it does not access native code unless it has permission to do so. Before it can run, all code that is not type-safe must have been granted a security permission with the SkipVerification member. This permission is granted only to code that is trusted at a very high level.

Definition of type safety verification

During just-in-time (JIT) compilation, Microsoft intermediate language (MSIL) code is compiled into native machine code. As this process occurs, a default verification process examines the metadata and MSIL code of a method to verify that they are well formed and type-safe.

Type-safe components can run in the same process even if they are trusted at different levels. For code that is verifiably type-safe, the runtime can rely on the following statements being true:

  • A reference to a type is compatible with the type being referenced.

  • Only appropriately defined operations are invoked on an object.

  • Methods are called by means of defined interfaces so that security checks cannot be bypassed.

These restrictions provide assurances that security restrictions on code can be enforced reliably. Also, multiple instances of different type-safe assemblies can run safely in the same process, because they are guaranteed not to interfere with each other’s memory.

What Is Code Signing?

To make any source reliable for software download, you need to consider the following:

  • Ensure authenticity. Ensures that users know the origin of the code and helps to prevent malicious users from impersonating the identity of a publisher.

  • Ensure integrity. Verifies that the code has not been changed by unauthorized sources since it was published.

Definition of code signing

Signing code with a strong name defines the unique identity of code and guarantees that code has not been compromised. Code signing is the process of providing a set of code with credentials that authenticate the publisher of the code. The credentials of the code can be verified prior to installing and running the code.

Code signing in the .NET Framework

.NET Framework code signing relies on strong name signatures. The .NET Framework also supports Authenticode® digital certificates and signatures.

What Is Encryption and Data Signing?

Data signing and encryption are processes that are used to protect data contents from being discovered and to verify that data has not been compromised.

Definition of encryption and decryption

Encryption is the process of disguising data before it is sent or stored. Before it is encrypted, the content is referred to as plaintext. Data that has undergone encryption is called ciphertext. A plaintext message that is converted to ciphertext is completely unreadable. Decryption is the process of unscrambling ciphertext into readable plaintext. The processes of encrypting and decrypting data rely on the techniques of hashing and signing data.

Definition of cryptographic hashing

Hashing is the process of matching data of any length to a fixed-length byte sequence. The fixed-length byte sequence is called a hash. A hash is obtained by applying a mathematical function, called a hashing algorithm, to an arbitrary amount of data. Cryptographic hashes that are created with the cryptography functions of the .NET Framework approach statistical uniqueness; a different two-byte sequence does not hash to the same value.

Definition of signed data

Signed data is a standards-based data type. Signed data consists of any type of content plus encrypted hashes of the content for zero or more signers. The hashes are used to confirm the identity of a data signer and to confirm that the message has not been modified since it was signed.

What Is Code-Access Security?

Windows operating system security ensures that unauthorized users are not allowed access to the computer system. However, Windows operating systems security alone cannot ensure against the possibility of authorized users downloading and running malicious code.

Definition of code-access security

The .NET Framework provides code-access security to help protect computer systems from malicious or faulty code and to provide a way to allow mobile code to run safely.

Code-access security allows code to be trusted to varying degrees, depending on the code’s origin, code’s evidence (such as its strong name signature), and on other aspects of the code’s identity. For example, code that is downloaded from your organization’s intranet and published by your organization might be trusted to a greater degree than code that is downloaded from the Internet and published by an unknown entity.

Requesting level of privilege required

The .NET Framework allows you to include features in your application that request a specific level of security privilege from the operating system. This request specifies the level of privilege your application:

  • Requires to run

  • Can make use of but is not required for the application to run

  • Does not need and should be expressly excluded from ever being granted permission to access

What Is Role-Based Security?

Role-based security relates mostly to the spoofing identity security threat by preventing unauthorized users from performing operations that they are not authorized to perform. Role-based security allows code to verify the identity and role membership of the user.

TIP
The .NET Framework includes classes to identify Windows users and groups, in addition to classes to help implement role-based security for other authentication schemes.

Figure 9.2 depicts the role-based security model.

Figure 9-2 Role-based security
Figure 9-2. Role-based security
Authentication

Authentication is the process of discovering and verifying the identity of a user by examining the user’s credentials and then validating those credentials against some authority. A variety of authentication mechanisms are used, some of which can be used with .NET Framework role-based security.

Examples of commonly used authentication mechanisms include the operating system, Passport, and application-defined mechanisms, such as NTLM and Kerberos version 5 authentication.

Authorization

Authorization is the process of determining whether a user is allowed to perform a requested action. Authorization occurs after authentication and uses information about a user’s identity and roles to determine what resources that user can access. You can use .NET Framework role-based security to implement authorization.

What Is Isolated Storage?

A common requirement of applications is to store data, such as user preference information or application state, on the client.

One challenge to storing data successfully is the possibility that the storage location will be accessed or corrupted, either intentionally or unintentionally. Without a standard system in place to manage these problems, developing improvised techniques that minimize storage conflicts can be complex and the results can be unreliable. Therefore, it is important to protect your data by providing isolated storage.

Isolated storage allows developers to use an isolated virtual file system on the client to save data. When using isolated storage, applications save data to a unique data compartment that is associated with some aspect of the code’s identity, such as its Web site, publisher, or signature.

The data compartment is an abstraction, not a specific storage location. It consists of one or more isolated storage files, called stores. The actual directory location of the data is contained in a store. To the developer, the location of the actual data is transparent. A quota can be used to limit the amount of isolated storage that an assembly uses.

Access permission to a store can be based on identity of:

  • User

  • Assembly

  • Application

Security Features of .NET Technologies

.NET Web applications implement one or more of the logical services by using technologies such as Microsoft ASP.NET, Enterprise Services, XML Web services, remoting, Microsoft ADO.NET, and Microsoft SQL Server. To create effective security strategies, you need to understand how to fine-tune the various security features within each product and technology area, and how to make them work together.

ASP.NET security

ASP.NET provides a useful tool for application developers to use to create Web pages. When a Web site records a user’s credit card information, the file or database that stores such information must be secured from public access. ASP.NET, in conjunction with IIS, can authenticate user credentials such as names and passwords by using any of the following means of authentication:

  • Windows: basic, digest, or integrated Windows authentication (NTLM or Kerberos)

  • Passport authentication

  • Forms

  • Client certificates

ASP.NET implements authentication by means of authentication providers. ASP.NET supports the following authentication providers:

  • Forms authentication. A system by which unauthenticated requests are redirected to a Hypertext Markup Language (HTML) form by using HTTP client-side redirection. The user provides credentials and submits the form. If the application authenticates the request, the system issues a cookie that contains the credentials, or a key for reacquiring the identity.

  • Passport authentication. A centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites.

  • Windows authentication. A system used by ASP.NET in conjunction with IIS authentication. Authentication is performed by IIS in one of three ways: basic, digest, or integrated Windows authentication. When IIS authentication is complete, ASP.NET uses the authenticated identity to authorize access.

More Info
For more information about ASP.NET security, see “ASP.NET Security” under the section “Building Secure ASP.NET Applications” on the MSDN Web site (http://msdn.microsoft.com).
Enterprises Services security

Traditional COM+ services such as distributed transactions, just-in-time activation, object pooling, and concurrency management are available to .NET components. In the .NET environment, such services are referred to as Enterprise Services.

The authentication, authorization, and secure communication features supported by Enterprise Services applications are shown in Figure 9.3. The client application shown in Figure 9.3 is an ASP.NET Web application.

Figure 9-3 Enterprise Services role-based security architecture
Figure 9-3. Enterprise Services role-based security architecture
More Info
For more information about Enterprise Services security, see “Enterprise Services Security” under the section “Building Secure ASP.NET Applications” on the MSDN Web site (http://msdn.microsoft.com).
Web services security

Web services enable the exchange of data and the remote invocation of application logic by using SOAP-based message exchanges to move data through firewalls and between heterogeneous systems. Web service security can be used at three levels:

  • Platform/transport-level (point-to-point) security

  • Application-level (custom) security

  • Message-level (end-to-end) security

More Info
For more information about Web services security, see “Web Services Security” under the section “Building Secure ASP.NET Applications” on the MSDN Web site (http://msdn.microsoft.com).
.NET remoting security

.NET remoting allows you to access remote and distributed objects across process and machine boundaries. Remoting does not have its own security model. Authentication and authorization between the client and server is performed by the channel and host process.

ADO.NET and SQL Server

ADO.NET provides data access services. It is designed for distributed Web applications, and supports disconnected scenarios. When you build Web-based applications, it is essential that you use a secure approach to accessing and storing data. ADO.NET and SQL Server provide several security features that can be used to ensure secure data access.

Figure 9.4 shows the remote application tier model together with the set of security services provided by the various technologies.

Figure 9-4 Security architecture
Figure 9-4. Security architecture

Table 9.5 summarizes the authentication, authorization, and secure communications features provided by .NET technologies.

Table 9-5. Security Features and .NET Technologies

Technology

Authentication

Authorization

Secure communication

ASP.NET

  • None (custom)

  • Windows

  • Forms

  • Passport

  • File authorization

  • URL authorization

  • Principal permissions

  • .NET roles

Web services

  • Windows

  • None (custom)

  • Message-level authentication

  • File authorization

  • URL authorization

  • Principal permissions

  • .NET roles

  • SSL and message-level encryption

Remoting

  • Windows

  • File authorization

  • URL authorization

  • Principal permissions

  • .NET roles

  • SSL and message-level encryption

Enterprise Services

  • Windows

  • Enterprise Services (COM+) roles

  • NTFS permissions

  • Remote Procedure Call (RPC) Encryption

SQL Server

  • Windows (Kerberos/NTLM)

  • SQL authentication

  • Server logons

  • Database logons

  • Fixed database roles

  • User-defined roles

  • Application roles

  • Object permissions

  • SSL


Lesson 4: Designing Authorization, Authentication, and Auditing Strategies

Designing an authorization and authentication strategy for an application is a challenging task. Proper authorization and authentication design during the early phases of your application development helps to mitigate many serious security risks. In many cases, you will also need to implement auditing functionality to track user and business activity in the application for security purposes.

In this lesson, you will learn the general process for designing authorization and authentication strategies. You will then learn how to design authorization, authentication, and auditing for the application tiers.

After this lesson, you will be able to

  • Identify the process of designing authorization and authentication strategies.

  • Design authorization strategies for user interface and user process components.

  • Design authorization strategies for business components and data access components.

  • Design authentication strategies for user interface and user process components.

  • Design authentication strategies for data access components.

  • Design auditing strategies.

Estimated lesson time: 25 minutes
How to Design Authorization and Authentication Strategies

To design authentication and authorization strategies for your application, you need to perform the following steps:

  1. Identify resources.

  2. Select an authorization strategy.

  3. Select the identities used for resource access.

  4. Consider whether identity should flow through the system.

  5. Select an authentication approach.

  6. Decide how to flow identity through the system.

Identify resources

Identify the resources that the application provides to the clients. Examples of resources include:

  • Web server resources such as Web pages, Web services, and static resources (HTML pages and images)

  • Database resources such as per-user data or application-wide data

  • Network resources such as remote file system resources and data from directory stores such as Active Directory®

Select an authorization strategy

The two basic authorization strategies are:

  • Role based. Users are associated with roles; if a user is authorized to perform the requested operation, the application uses fixed identities with which to access resources.

  • Resource based. Individual resources are secured by using Windows access control lists (ACLs). The application impersonates the caller prior to accessing resources, which allows the operating system to perform standard access checks.

Choose the identities used for resource access

Choose the identity or identities that should be used to access resources across the layers of your application.

  • Original caller’s identity. Assumes an impersonation or delegation model in which the original caller identity can be obtained and then flowed through each layer of your system. The delegation factor is a key criterion used to determine your authentication mechanism.

  • Process identity. This is the default case. Local resource access and downstream calls are made using the current process identity. The feasibility of this approach depends on the boundary being crossed, because the process identity must be recognized by the destination system.

  • Service account. Uses a fixed service account. For example, for database access this might be a fixed user name and password presented by the component connecting to the database. When a fixed Windows identity is required, use an Enterprise Services server application.

  • Custom identity. When you do not have Windows accounts to work with, you can construct your own identities that can contain details that relate to your own specific security context. These could include role lists, unique identifiers, or any other type of custom information.

Consider identity flow

To support per-user authorization, auditing, and per-user data retrieval, you might need to flow the original caller’s identity through various application tiers and across multiple computer boundaries. For example, if a back-end resource manager needs to perform per-caller authorization, the caller’s identity must be passed to that resource manager.

Based on resource manager authorization requirements and the auditing requirements of your system, identify which identities need to be passed through your application.

Select an authentication approach

Two key factors that influence the choice of the authentication approach are the nature of your application’s user base (the types of browsers they are using and whether they have Windows accounts), and your application’s impersonation/delegation and auditing requirements.

You have a variety of options for authentication in your .NET-connected Web applications. For example, you can choose to use one of the supported IIS authentication mechanisms, or you might decide to perform authentication in your application code. Consider some or all of the following factors when choosing an authentication method:

  • Server and client operating systems

  • The client browser type

  • The number of users, and the location and type of the user name and password database

  • Deployment considerations, such as whether your application is Internet- or intranet-based and whether it is located behind a firewall

  • The application type, such as whether the application is an interactive Web site or a non-interactive Web service

  • Sensitivity of the data you are protecting

  • Performance and scalability factors

  • Application authorization requirements, such as making your application available to all users, or restricting certain areas to registered users and other areas to administrators only

Some of the ASP.NET and IIS authentication types include:

  • Forms

  • Passport

  • Integrated Windows (Kerberos or NTLM)

  • Basic

  • Digest

Decide how to flow identity

You can flow identity (to provide security context) at the application level or you can flow identity and security context at the operating system level. To flow identity at the application level, use method and stored procedure parameters. Application identity flow supports:

  • Per-user data retrieval using trusted query parameters, as shown in the following code:

    SELECT x,y FROM SomeTable WHERE username='jane'

  • Custom auditing within any application tier

Operating system identity flow supports:

  • Platform level auditing (for example, Windows auditing and SQL Server auditing)

  • Per-user authorization based on Windows identities

To flow identity at the operating system level, you can use the impersonation/delegation model. In some circumstances, you can use Kerberos delegation, while in cases where the environment does not support Kerberos, you might need to use other approaches, such as using Basic authentication. With Basic authentication, the user’s credentials are available to the server application and can be used to access downstream network resources.

How to Design Authorization Strategies for User Interface Components

User interface components show data to users and gather data from them. You perform authorization at this level if you want to hide specific data fields from the user, show specific data fields to the user, or enable or disable controls for user input.

Authorization for user interface components

If the user is not supposed to see a certain piece of information, the most secure option is to avoid passing that piece of information to the presentation components in the first place.

It is common to perform some level of personalization of the user interface or menu so that users can see only the panes, Web elements, or menu entries that they can act on depending on their roles. A user interface .exe file usually starts the application. You should set code-access permissions on the user interface assemblies if you do not want to let it (or the local components it calls) access sensitive resources such as files.

Planning
Consider the security context in which the presentation components of the application will run, and test them in an appropriately restricted environment.
Authorization in user process components

User process components manage data and control flow between user processes. You should perform authorization at this level if you need to:

  • Control whether a user can start a user interface interaction process at all.

  • Add and remove steps or full user interface components in a user interaction flow based on who is executing it. For example, each sales representative might see data for only the appropriate region, so there is no need to present a step to choose the region of a sales report.

User process components are typically consumed only from user interface components. You can use code-access security to restrict who is calling them. You can also use code-access security to restrict how user process components interact with each other. This approach is especially important in portal scenarios when it is critical that a user process implemented as an add-in cannot gather unauthorized information from other user processes and elements.

How to Design Authorization Strategies for Business Components

Like the other tiers of an application, you can set authorization for business components. Use the following guidelines when setting authorization:

  • Try to make the business process authorization independent of user context, especially if you plan to use many communication mechanisms as queues and Web services.

  • Use role-based security as much as possible rather than relying on user accounts. Roll-based security provides better scalability, eases administration, and avoids problems with user names that support many canonical representations. You can define roles for serviced components in an Enterprise Services–based application, or you can use Windows groups or custom roles for .NET components that are not running in Enterprise Services.

How to Design Authorization Strategies for Data Access Components

Data access components are the last components that expose business functionality before your application data. You need to perform authorization at this level if you need to share the data access components with developers of business processes that you do not fully trust and if you want to protect access to powerful functions made available by the data stores.

To perform authorization, you can use Enterprise Services roles and .NET PrincipalPermission attributes, if you are using Windows authentication. Use .NET roles and attributes if you are not using a Windows security context.

If you are flowing the same user context into your data store, you can use the database’s authorization functionality, for example, granting or revoking access to stored procedures.

Because data access components are typically called only by other application components, they are a good candidate for restricting callers to the necessary set of assemblies—usually a combination of assemblies with components of the user interface layer, business process components, and business entities (if present).

How to Design Authentication Strategies for User Interface Components

User interface components need to authenticate the user if the application needs to perform authorization, auditing, or personalization.

Authentication for Web-based UI

A wide range of authentication mechanisms are available for Web-based user interfaces (UIs). To choose the right one for your scenario, see Figure 9.5.

Figure 9-5 Authentication in ASP.NET
Figure 9-5. Authentication in ASP.NET
Authentication for Windows-based UI

Windows-based user interfaces usually either rely on a custom authentication mechanism (in which the application prompts for a user name and password), or they authenticate users by using their Windows logons.

Authentication for user process components

User process components do not perform authentication; they rely on the security context set at application start.

The user process components should run in the same user context as the user interface itself, so that all authentication tasks are delegated to the user interface or even the rendering infrastructure. For example, in ASP.NET, any request to an ASPX page results in IIS requesting authentication credentials or ASP.NET redirecting the user to a forms-based authentication page. This operation is handled transparently to any user process layer and does not interrupt state flow, even when an authenticated session expires and needs to be reestablished.

How to Design Authentication Strategies for Data Access Components

Data access components are designed to be used by other components in the application or service. They are not usually meant to be called from scripts or other applications, so you can design them to rely on the security context set by the caller or the authentication mechanism of your remoting strategy. Data access components can authenticate with the database in two main ways: using service accounts and impersonating the caller.

Service accounts

Use one or a limited set of service accounts that represent roles or user type. In most cases, it will be just one service account, but you can use more if you need more control over authorization. For example, in the order processing application you could access your database as “TheOrderApplication,” or log on selectively as “OrderProcessingManager” or “OrderProcessingClerk,” depending on the role of the caller identity.

Use service accounts when:

  • You connect to the underlying data source from an environment in which impersonation of the initial caller is unavailable (for example, Microsoft BizTalk® Server).

  • You have very limited change control over the accounts that can log on to the other system, for example, when logging on to a relational database management system, which is strictly managed by the database administrator.

  • The data store you are accessing has a different authentication mechanism than the rest of your application, for example, when you are logging on to a Web service across the Internet.

Do not use service accounts when:

  • You do not have a secure way of storing and maintaining service credentials.

  • You need to access the data store with specific user resources because of security policies, for example, when you need access to data or objects in SQL Server on behalf of users.

  • The data store audits activities, and these audits need to correspond to individual users.

Impersonating the caller

You are impersonating the caller when you access a data store with a set of accounts that correspond one-to-one with your application user base. For example, if Jane logs on to your application, and your data access components access a database, you are impersonating Jane if you log on to this database with Jane’s credentials.

You need caller impersonation when:

  • The data store performs authorization based on the logged on user.

  • The data store needs to audit the activities of each individual end user.

How to Design Auditing Strategies

To audit your business activities, you need a secure storage location. In fact, auditing can be thought of as secure logging. If you are implementing your own auditing solution, you must ensure that audit entries are tamperproof or at least tamper-evident (achieved with digital signatures) and that storage location is secured (for example, either connection strings cannot be changed or storage files cannot be replaced, or both). Your auditing mechanism can use document signing, platform authentication, and code-access security to ensure that spurious entries cannot be logged by malicious code.

Auditing in user interface and user process components

The activity that occurs in user interface components is not usually audited. Activities that are audited at the user interface include global events such as logon, logoff, password changes, and all security exceptions in general.

Because user process components represent user activities, which can be stopped, abandoned, and so on, it is not common to audit them. As always, you might want to audit security-related exceptions.

Auditing in business process components

Auditing is most often performed for business processes. You will want to know who performed key business activities and when the activities occurred.

If you are auditing within the context of a transaction to a transactional resource manager such as SQL Server, you will want to have a new transaction started by your auditing component so that the failures in the original transaction tree do not roll back the audit entry.

Auditing in data access components

Data access components are the closest custom business logic layer to the data store. The data layer is a good location for implementing auditing.

The data access components in your application will usually invoke stored procedures that actually do the data-intensive work, so you might want to also audit inside the data base management system (RDBMS).

More Info
For information about how to implement auditing in SQL Server, see “Auditing SQL Server Activity” in the SQL Server 2000 SDK on the MSDN Web site (http://msdn.microsoft.com).


Activity: Threat Modeling and Mitigation

In this activity, you use what you learned in the lessons to work through threat modeling exercises.

Exercise 1: Identifying Potential Threats

The sales staff at Adventure Works Cycles can create orders for their customers in two ways. The first way allows the sales staff to use the public Web site in a manner similar to how the customers place orders. However, the sales staff will need to provide their credentials, which will allow discounts to be applied to the order. The second way is accomplished by means of the Handheld PCs and laptop computers that each sales representative has and a Windows Forms application that is installed on each laptop. The sales representative creates the order either on the Handheld PC or the laptop and obtains the customer’s signature by means of the Handheld PC. Later, the sales representative can connect to the network and upload the order to the order entry application.

Both ways of creating orders can be subject to a number of security threats. Open the C09Ex1.ppt file in the \SolutionDocuments\Chapter09 folder on the CD and examine the high-level architecture diagram for the Windows Forms application. Using the STRIDE threat model, identify some of the security threats to the application.

One possible answer to this exercise can be found in C09Ex1_Answer.ppt in the \SolutionDocuments\Chapter09 folder on the CD.

Exercise 2: Applying Mitigation Technologies

Using the possible threats you identified in Exercise 1, list some technologies that would help to mitigate these threats.

One possible answer to this exercise can be found in C09Ex2_Answer.ppt in the \SolutionDocuments\Chapter09 folder on the CD.


Summary

  • Common types of security vulnerabilities include:

    • Weak passwords

    • Misconfigured software

    • Social engineering

    • Internet connections

    • Unencrypted data transfer

    • Buffer overrun

    • SQL injection

    • Secrets in code

  • Principles for building security strategies include:

    • Rely on tested and proven security systems.

    • Never trust external input.

    • Assume that external systems are non-secure.

    • Apply the principle of least privilege.

    • Reduce available components and data.

    • Default to a secure mode.

    • Do not rely on security by obscurity.

    • Follow STRIDE principles.

  • The STRIDE model is a threat model. Each letter in the STRIDE acronym specifies a different category of security threat: spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

  • The steps to create a threat model are:

    • Arrange for a brainstorming meeting.

    • Apply the STRIDE security categories.

    • List all possible threats.

    • Create notes.

    • Research.

    • Rank the risk of each threat.

  • The important security features of .NET Framework include:

    • Type safety verification

    • Code signing

    • Encryption and data signing

    • Code-access security

    • Role-based security

    • Isolated storage

  • To design an authentication and authorization strategy for your application, you need to perform the following steps:

    • Identify resources.

    • Select an authorization strategy.

    • Select the identities used for resource access.

    • Consider identity flow.

    • Select an authentication approach.

    • Decide how to flow identity.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What are some of the drawbacks of traditional security models?

  2. What are some of the principles of secure coding?

  3. Which of the following statements about buffer overruns is true? (Select all that apply.)

    • Type safety verification was designed to eliminate buffer overruns.

    • A buffer overrun can cause an application to stop responding or to malfunction.

    • A buffer overrun can be exploited by a malicious user to run arbitrary code.

    • The error message that results from a buffer overrun can pose a security threat.

  4. During which MSF phase should the threat model be created?

    • Planning

    • Developing

    • Stabilizing

  5. What is the STRIDE model?

  6. Read the following security attack scenario, and then decide which elements of the STRIDE model are implicit in the attack.

    Carl sees that Bob has left his workstation unattended and unlocked. Carl sits down at Bob’s workstation and opens Bob’s e-mail application. Carl, pretending to be Bob, sends an e-mail message to Alice. Carl quits the e-mail client and then walks away unobserved.

  7. What is code-access security?

  8. What is role-based security?

  9. Which are the authentication providers supported by ASP.NET?

  10. What are the three types of security provided by Web services?

  11. What are the steps for designing an authorization and authentication strategy for an application?


Chapter 10: Completing the Planning Phase

Chapter 10
Completing the Planning Phase
About This Chapter

The planning phase encompasses the greater part of the architecture and design of a solution. It also results in plans to accomplish the development and deployment of the solution, and the schedules associated with tasks and resources. These plans help the project team to work on the subsequent phases of the project.

In this chapter, you will learn about the tasks and plans that the project team works on to complete the planning phase of the project.

Before You Begin

To complete the lessons in this chapter, you must

  • Understand the MSF Process Model.

  • Be able to create use cases, usage scenarios, and use case diagrams.

  • Be familiar with the outputs of the envisioning phase, such as vision/scope, project structure, and risk analysis documents.

  • Be familiar with tasks and outputs of the three design processes of the planning phase—conceptual, logical, and physical design.


Lesson 1: Incorporating Design Considerations

During the planning phase, several elements affect and shape the design of the application. Some of these elements might be non-negotiable and finite resources, such as time, money, and workforce. Other elements, such as available technologies, knowledge, and skills, are dynamic and vary throughout the development life cycle. While these elements influence the design of an application to some extent, the business problem dictates the capabilities the application must have for a satisfactory solution.

In this lesson, you will learn about the capabilities and considerations that might be addressed by a solution. You will learn about design considerations such as scalability, availability, reliability, performance, interoperability, and globalization and localization. You will also learn the techniques for incorporating these design considerations into a solution.

After this lesson, you will be able to

  • Design a solution for scalability.

  • Design a solution for availability.

  • Design a solution for reliability.

  • Design a solution for performance.

  • Design a solution for interoperability.

  • Design localization and globalization specifications for a solution.

Estimated lesson time: 25 minutes
How to Design for Scalability

Scalability is defined as the capability to increase resources to produce an increase in the service capacity. In a scalable application, you can add resources to manage additional demands without modifying the application itself.

A scalable application requires a balance between the software and hardware used to implement the application. You might add resources to either software or hardware to increase the scalability of the application. Adding these resources might produce a benefit; however, it could also have a negative or null effect, with the application showing no significant increase in service capacity. For example, you might implement load balancing in an application. This will help only minimally if the application has been written to make synchronous method calls or to retrieve lengthy datasets in response to a user’s request.

Common approaches

The two most common approaches to scalability are:

  • Scaling up. Refers to achieving scalability by improving the existing server’s processing hardware. Scaling up includes adding more memory, more or faster processors, or migrating the application to a more powerful computer. The primary goal of scaling up an application is to increase the hardware resources available to the application. Typically, you can scale up an application without changing the source code. In addition, the administrative effort does not change drastically. However, the benefit of scaling up tapers off eventually until the actual maximum processing capability of the machine is reached.

    Figure 10.1 illustrates the effect scaling up has on the service capacity of an application.

    Figure 10-1 Scaling up an application
    Figure 10-1. Scaling up an application

  • Scaling out. Refers to distributing the processing load across more than one server. Although scaling out is achieved by using multiple computers, the collection of computers continues to act as the original device configuration from the end-user perspective. Again, the balance between software and hardware is important. The application should be able to execute without needing information about the server on which it is executing. This concept is called location transparency. Scaling out also increases the fault tolerance of the application.

    Figure 10.2 illustrates the effect scaling out has on the service capacity of an application.

    Figure 10-2 Scaling out an application
    Figure 10-2. Scaling out an application
Designing for scalability

Good design is the foundation of a highly scalable application. The planning phase has the greatest impact on the scalability of an application.

Figure 10.3 illustrates the role of design, code tuning, product tuning, and hardware tuning in the scalability of an application. Design has more impact on the scalability of an application than the other three factors. As you move up the pyramid, the impact of various factors decreases. The pyramid illustrates that effective design adds more scalability to an application than increased hardware resources.

Figure 10-3 Scalability pyramid
Figure 10-3. Scalability pyramid

To design for scalability, use the following guidelines:

  • Design processes such that they do not wait. A process should never wait longer than necessary. A process can be categorized as synchronous or asynchronous. A synchronous process waits for another process to complete before it continues. Such processes must wait for another process to succeed or fail completely before performing another operation. Applications that implement synchronous processes encounter bottlenecks for resources. These bottlenecks affect both the performance and the scalability of the application. One way to achieve scalability is to implement asynchronous processes. In applications that have asynchronous processes, long-running operations can be queued for completion later by a separate process.

  • Design processes so that processes do not compete for resources. One of the biggest causes of scalability problems is competition for resources such as memory, processor cycles, bandwidth, or database connections. Plan your resource usage to minimize these problems:

    • Sequence resource usage to use the most plentiful resources first and the least plentiful resources last.

    • Acquire resources as late as possible. The shorter the amount of time a process uses a resource, the sooner the resource becomes available to another process.

  • Design processes for commutability. Two or more operations are called commutative if they can execute in any order and still obtain the same result. Typically, operations that do not involve transactions are commutative. For example, a busy e-commerce site that continuously updates the inventory of its products might experience contention for record locks. To prevent this, each inventory increment and decrement could become a record in a separate inventory transaction table. Periodically, the database could add the rows of this table for each product and then update the product records with the net change in inventory.

  • Design components for interchangeability. An interchangeable component is designed to release its resources, move into a pool managed by a resource manager, and be re-initialized for use by a new client. Design the component so that no client-specific state persists from client to client. In addition, the component should support aggregation and not be bound to a specific thread. Resource pooling schemes such as COM+ component pooling and Open Database Connectivity (ODBC) connection pooling use interchangeable resources. For example, you can use the Component Services Administration tool to enable object pooling, set minimum and maximum pool size, and create timeout settings. For more information, refer to Improving Performance with Object Pooling in the Platform SDK: COM+ (Component Services documentation in MSDN).

  • Partition resources and activities. Minimize relationships between resources and activities by partitioning them. This helps you avoid the risk of bottlenecks. Partitioning activities can also ease the load on critical resources such as the processor and bandwidth. For example, using Secure Sockets Layer (SSL) to provide a secure connection results in significant overhead. Therefore, you might decide to use SSL only for pages that require a high level of security and use dedicated Web servers to handle SSL sessions. You can also partition resources and activities by creating many small components rather than a few large components, and by limiting cross-device communication. However, partitioning can make a system more complex. Dividing resources that have dependencies can add significant overheads to an operation.

How to Design for Availability

Though all applications are available at least some of the time, Web-based applications and mission-critical enterprise applications must provide services at all times. If your enterprise application needs to work 24 hours a day, 7 days a week, you need to design for high availability. Advances in hardware and software have increased the quality of high-availability applications.

Definition of availability

Availability is a measure of how often the application is available to handle service requests as compared to the planned run time. Availability also takes into account repair time because an application that is being repaired is not available for use.

NOTE
Availability does not address business continuation issues such as backups and alternative sites.

Table 10.1 shows the measurements used for calculating availability.

Table 10-1. Measurement Types for Calculating Availability
Name | Calculation | Definition
Mean Time Between Failure (MTBF) | Hours / Failure Count | Average length of time the application runs before failing
Mean Time To Recovery (MTTR) | Repair Hours / Failure Count | Average length of time needed to repair and restore service after a failure

The formula for calculating availability is:

Availability = (MTBF / (MTBF + MTTR)) × 100

For example, the typical availability requirement for the Adventure Works Cycles application is that the site is available 24 hours a day, 7 days a week. If you assume 1000 continuous hours as a checkpoint, two 1-hour failures during this time period results in availability of:

((1000 / 2) / ((1000 / 2) + 1)) × 100 = (500 / 501) × 100 = .998 × 100 = 99.8%.

A popular way to describe availability is by the nines, for example, three nines for 99.9 percent availability. However, the implication of measuring by nines is often misunderstood. You need to do the arithmetic to discover that three nines (99.9 percent availability) represent about 8.5 hours of service outage in a single year. The next level, four nines (99.99 percent), represents about 1 hour of service outage in a year. Five nines (99.999 percent) represent about 5 minutes of outage per year.

Planning availability levels

To determine the level of availability that is appropriate for your application, you need to answer a few questions, such as:

  • Who are the customers of the application? What are their expectations from the application?

  • How much downtime is acceptable?

  • Do internal company processes depend on the service?

  • What is the schedule and budget for developing the application?

Techniques for availability

Designing for availability includes anticipating, detecting, and resolving hardware or software failures before they result in service errors, faults, or data corruption, thereby minimizing downtime. To ensure availability, provide multiple routes to application services and data. Use only tested, proven processes (both automated and people-based) that support the application throughout its life cycle.

In addition to unplanned downtime, planned downtime must be reduced. Planned downtime can include maintenance changes, operating system upgrades, backups, or any other activity that temporarily removes the application from service.

Availability of an application also depends on its reliability. For a highly available and reliable application, you need a reliable foundation: good application design, rigorous testing, and certification. Some of the techniques used for designing for availability include:

  • Reduce planned downtime. To avoid planned downtime, use rolling upgrades. For example, to update a component on a clustered server, you can move the server’s resource groups to another server, take the server offline, update the component, and then bring the server online. Meanwhile, the other servers handle the workload, and the application experiences no downtime. You can use this strategy in an application that scales out.

  • Reduce unplanned downtime with clustering. Clustering is a technology for creating high-availability applications. A cluster consists of multiple computers that are physically networked and logically connected using cluster software. By using clustering, a multiple server Web site can withstand failures with no interruption in service. When the active server fails, the workload is automatically moved to a passive server, current client processes are switched over, and the failed application service is restarted automatically. If a resource fails, customers connected to that server cluster might experience a slight delay, but the service will be completed. Cluster software can provide failover support for applications, file and print services, databases, and messaging systems that have been designed as cluster-aware and assigned to a cluster.

  • Use network load balancing. Network load balancing (NLB) is used to distribute traffic evenly across available servers. NLB also helps increase the availability of an application: if a server fails, you can use NLB to redefine the cluster and direct traffic to the other servers. NLB is especially beneficial for e-commerce applications that link external clients with transactions to data servers. As client traffic increases, you can scale out the Web server farm by adding up to 32 servers in a single cluster. NLB automatically detects server failures and redirects client traffic to the remaining servers, all the time maintaining continuous, unbroken client service.

  • Use redundant array of independent disks (RAID) for data stores. RAID uses multiple hard disks to store data in multiple places. If a disk fails, the application is transferred to a mirrored data image and the application continues running. The failed disk can be replaced without stopping the application.

  • Isolate mission-critical applications. An application is constantly performing tasks and requesting resources such as network communications, data access, or process threads. Each of these resource requests can affect the performance and availability of applications sharing the same resources. If an application shares these services on the same servers, the workload and throughput characteristics for these servers might change unfavorably. It is recommended that mission-critical applications use dedicated infrastructures and private networks.

  • Use queuing. Queuing enables your application to communicate with other applications by sending and receiving asynchronous messages. Queuing guarantees message delivery; it does not matter whether the necessary connectivity currently exists (with mobile applications, for example). Queuing removes a failure point from the application. Queuing is also a solution for managing peak workloads that can require a lot of hardware. In addition, by increasing the number of routes for successful message delivery, an application can increase the chances for successful and immediate message completion.

How to Design for Reliability

The reliability of an application refers to the ability of the application to provide accurate results. Reliability and availability are closely related. While availability measures the capacity to handle all requests and to recover from a failure with the least loss of access to the application, reliability measures how long the application can execute and produce expected results without failing. Users bypass unreliable Web sites, resulting in lost revenue and reduced future sales. In addition, the expense of repairing corrupted data increases the cost of application failure. Unreliable systems are also difficult to maintain or improve because the failure points are typically hidden throughout the system.

Reasons for application failure

An application is a collection of hardware, operating system services, software components, and human processes that together provide pre-specified business services. Reliability of the entire application depends on the reliability of the individual components. Because all components in a system are related, failure of one component can affect the reliability of other components.

Application failures can occur for many reasons:

  • Erroneous code

  • Inadequate testing

  • Change management problems

  • Operational errors

  • Lack of ongoing monitoring and analysis

  • Lack of quality software engineering processes

  • Interaction with external services or applications

  • Changing operating conditions, such as usage level or workload changes

  • Unusual events, such as security failures and broadcast storms

  • Hardware failures (disks, controllers, network devices, servers, power supplies, memory, and CPUs)

  • Environmental problems (power, cooling, fire, flood, dust, and natural disasters)

Designing for reliability

To design for reliability, you need to examine the application’s expected usage pattern, create a reliability profile, and create a solution that meets the profile. You must examine how a particular service is provided, evaluate failure scenarios, and design preferred alternatives. In addition, you need to consider the application’s interactions with other applications.

It is difficult to identify reliability problems and solutions for a system that has not been developed. However, you can begin by analyzing the currently running applications in the organization. Such analysis reveals the failure frequency and distribution, root causes, and possible improvements for existing systems. You can use this information to design a reliable solution.

A reliable solution ensures error-free data input, data transformations, state management, and non-corrupting recovery from any failure conditions. Creating a high-reliability application depends on the entire software development lifecycle, from the planning phase, through development and testing, to deployment and stabilizing. The following tasks can help you create a reliable application:

  • Putting reliability requirements in the specification

  • Using a good architectural infrastructure

  • Including management information in the application

  • Using redundancy

  • Using quality development tools

  • Using reliability checks that are provided by the application

  • Implementing error handling

  • Reducing the application’s functionality instead of completely failing the application

How to Design for Performance

An application’s performance is defined by metrics such as transaction throughput and resource utilization. A user might define an application’s performance in terms of its response time.

Performance goals and metrics

Before designing for performance, you need to determine performance goals of the application and metrics for measuring performance. To determine performance goals, you need to answer questions such as:

  • What is the business goal? For example, if the business goal of the solution is to handle more orders each week, you could begin with the expected increase in revenue and convert the figure into a performance goal for each functional area.

  • What is the critical functionality of the solution? Identifying critical features allows you to prioritize the system design. You might decide to degrade the performance of a low priority feature to maintain or increase the performance of a higher priority feature.

  • What are the features required by different sets of users? You can create profiles according to the various expectations of the organization and the end users of the solution. Because of varying expectations, the performance requirements of the application can differ. You need to determine the relationship between each functional area and performance goal. For example, the database stores all information about orders placed by the customer. From the customer’s perspective, the application should quickly update the database. The organization expects the solution to store valid data quickly. Therefore, the performance goal of the solution is to ensure fast inserts and updates to the database. Creating profiles helps in partitioning and developing accurate tests for the solution.

NOTE
For the purposes of testing, the performance goal must be expressed in a way that is measurable in your testing routines. You need to identify performance metrics for the application. For example, the performance goal of fast inserts and updates to a database can be measured in terms of transactions per second.
Designing for performance

You must define performance requirements before the team proceeds to the developing phase. To define a good performance requirement, you must identify project constraints, determine services that the application will perform, and specify the load on the application.

  • Identifying constraints. Constraints in the project include budget, schedule, infrastructure, and the choice of development tools or technologies. For example, you might need to deploy an application by a specific date. You might also need to use a specific development tool because the team has expertise in that tool only. You might not be able to design and develop applications that are processor intensive because the client computers do not have adequate hardware. You need to design an application so that it meets its performance goals within the limitations of the constraints. Instead of changing some aspects of a project to improve performance, you can modify aspects of the project that are not constrained to determine how you can improve performance. For example, can the team be trained so that they can create components by using a different tool? Can data access be improved by changing the data access technology?

  • Determining features. The features of an application correspond to use cases and usage scenarios. You can identify the usage scenarios that affect the performance of the application and, for each such scenario, specify what the user does and what the application does in response, including how databases and other system services are accessed. In addition, you need to determine how often each feature will be used. This information can help you create tests for measuring performance that resemble actual usage of the application as closely as possible.

  • Specifying the load. You can specify the load of an application as the number of clients that will use the application. In addition, you can examine how the load might vary over time. For example, the number of requests for an e-commerce site will be higher during certain times of year. You can use the load to define the performance metrics of the application.

How to Design for Interoperability

Typically, medium and large organizations have heterogeneous computing environments. For example, many organizations deploy distributed n-tier client/server applications that require access to data or transactions on existing systems. In addition, your application might need to interact with applications that have been developed using proprietary or third-party software.

Reasons for interoperability

You need to design for interoperability because interoperability:

  • Reduces operational cost and complexity. Customers can continue to work in mixed environments for the foreseeable future. The ability for different systems to operate in the same environment together reduces the cost of developing and supporting a heterogeneous infrastructure.

  • Enables optimal deployments. Customers might have business requirements that can be delivered with specific applications and platforms. An interoperable application enables the organization to continue using the diverse applications that address its specific requirements.

  • Uses existing investments. Typically, customers have a large and diverse range of systems installed in their environments and move to a new platform gradually. Therefore, new applications must be able to interact with previous applications. In addition, existing applications might be made Web-aware and need to allow access from an intranet or the Internet to systems hosted on environments such as an IBM mainframe. This extends the functionality of existing applications and protects the investments that the organizations have made.

Designing for interoperability

To integrate heterogeneous applications, you need to consider the following types of interoperability:

  • Network interoperability. Refers to the ability of multiple vendor systems to communicate with each other without having to use common protocols. In the past, applications might have been designed for predefined protocols such as Transmission Control Protocol/Internet Protocol (TCP/IP), Internetwork Packet Exchange /Sequenced Package Exchange (IPX/SPX), or Systems Network Architecture (SNA). Implementing technologies or standards such as Hypertext Transfer Protocol (HTTP), Extensible Markup Language (XML), SOAP, Web Services Description Language (WSDL), and XML Web services to make use of the Internet can make your applications independent of programming language, platform, and device.

  • Data interoperability. Refers to the ability of applications to access and use data stored in both structured and unstructured storage systems such as databases, file systems, and e-mail stores. Enterprise applications often require the sharing of data between disparate data sources and multiple applications. Published data exchange standards, such as cascading style sheets, ODBC, and XML, allow data access to both Windows-based and non-Windows-based data sources.

  • Applications interoperability. Refers to the infrastructure required to ensure interoperability between new n-tier applications and existing applications, business logic, and data. As you create new n-tier applications, they will need to work with a wide variety of existing applications. One of the methods of enabling application interoperability is by using Common Language Specification (CLS). CLS is a standard that is currently met by more than twenty different languages to allow the interoperability of services created in any CLS-compliant language.

    You can enable interoperability in Microsoft .NET-connected applications to access and use traditional Active Server Pages (ASP) and Component Object Model (COM) applications that you are not yet ready to migrate to .NET–connected solutions. In addition, XML was specifically created to allow applications to exchange data easily and without conversion code that would need to be created for each instance or type of data exchange.

  • Management interoperability. Refers to the tasks of user account management, performance monitoring, and tuning for heterogeneous applications in the organization.

How to Design for Globalization and Localization

Globalization and localization are processes that you use for developing world-ready applications. During the planning phase, you need to clearly identify and document globalization and localization requirements so that the design of the application can address these requirements.

NOTE
In the Microsoft .NET Framework, three namespaces have been provided to make your application easy to globalize and localize. They are the System.Globalization namespace, the System.Resources namespace, and the System.Text namespace.
Definition of globalization

Globalization is the process of designing and developing an application that can operate in multiple cultures and locales. Globalization involves:

  • Identifying the cultures and locales that must be supported

  • Designing features that support those cultures and locales

  • Writing code that executes properly in all the supported cultures and locales

Globalization enables you to create applications that can accept, display, and output information in different language scripts that are appropriate for various geographical areas. To globalize these functions, you use the concept of cultures and locales. A culture and locale is a set of rules and a set of data that are specific to a given language and geographical area. These rules and data include information about:

  • Character classification

  • Date and time formatting

  • Numeric, currency, weight, and measure conventions

  • Sorting rules

Definition of localization

Localization is the process of adapting a globalized application to a specific culture and locale, using separate resources for each culture that is to be globalized. A resource file contains culture-specific user interface items that are provided to an application as a text file, a .resx file, or a .resources file. An application prepared for localization has two conceptual blocks: the data block and the code block. The data block (usually contained in resource files) contains all user-interface string resources. The code block contains the application code that is applicable for all cultures and locales and accesses the correct resource file for the culture currently selected in the operating system.

To create a localized version of the application, you change the data block and combine it with the code block, which essentially remains the same. You need to have a basic understanding of relevant character sets commonly used in modern software development and the issues associated with them. Although all computers store text as numbers, different systems can store the same text by using different numbers.

To successfully create a localized version of an application, ensure that:

  • The code block is separate from the data block.

  • The application code can read data accurately, regardless of the culture and locale.

Issues in globalization and localization

Some of the issues that you need to consider while planning for globalization and localization are:

  • Language issues. Language issues are the result of differences in how languages around the world differ in display, alphabets, grammar, and syntactical rules. For example, various languages are read and written left-to-right, right-to-left, or top-to-bottom.

  • Formatting issues. Formatting issues are the primary source of discrepancies when working with applications originally written for another language, culture, and locale. During globalization and localization, you need to pay attention to factors such as addresses, currency types, dates, paper sizes, telephone numbers, time formats, and units of measure. Developers can use the National Language Support (NLS) application programming interfaces (APIs) in Microsoft® Windows® or the System.Globalization namespace to handle most of these issues automatically.

  • String-related issues. Strings are the text displayed in the various elements in an application’s user interface, such as message boxes, dialog boxes, title bars, status bars, and menus. For example, message boxes typically concatenate strings of standard text and context-specific texts. In different languages, the concatenated string might not be grammatically correct.

  • User interface issues. You should pay special attention to the design of the following user interface (UI) components:

    • Messages. The length of messages might differ in different languages.

    • Menus and dialog boxes. Menus and dialog boxes might become larger as a result of localization.

    • Icons and bitmaps. Icons and bitmaps must use symbols that are internationally accepted and convey the same meaning, regardless of the culture or locale.

    • Access and shortcut keys. The keyboards used in the different locales might not have the same characters and keys. You need to ensure that access keys and shortcut keys are supported in the keyboards used in the destination locales.

    • UI controls. UI controls should not be hidden or used as a parts of strings.

Best practices for globalization and localization

The following best practices provide a checklist of the issues associated with developing world-ready software.

  • Technical issues.

    • Use Unicode as your character-encoding standard to represent text. All applications process data, whether text or numerical. Different cultures and locales might use different data encoding techniques. Unicode is a 16-bit international character-encoding standard that covers values for more than 45,000 characters. It allows each character in all the required cultures and locales to be represented uniquely.

    • Implement a multilingual user interface. If you design the user interface to open in the default UI language, and offer the option to change to other languages, users who speak different languages can quickly switch to the preferred interface.

    • Examine Windows messages that indicate changes in the input language, and use that information to check spelling, select fonts, and so on.

    • Detect the culture that your application uses to handle dates, currencies, and numeric differences and change it to correspond to the culture that application supports. In the .NET Framework, culture refers to the user’s language, which can be combined with that user’s location. By specifying a culture, it is possible to use a set of common preferences for certain information, such as strings, date formats, and number formats, that corresponds to the user’s language and location conventions.

  • Cultural and political issues. Examples of cultural and political issues include disputes related to maps, which can induce governments to prevent distribution in specific regions. These issues do not prevent the application from running. However, they can create negative feelings about the application and customers might seek alternatives from other companies. To avoid such issues:

    • Avoid slang expressions, colloquialisms, and obscure phrasing in all text.

    • Avoid images in bitmaps and icons that are ethnocentric or offensive in other cultures and locales.

    • Avoid maps that include controversial regional or national boundaries.

  • User interface issues.

    • Store all user interface elements in resource files, message files, or a private database so that they are separate from the program source code.

    • Place only those strings that require localization in resource files. Leave non-localized strings as string constants in the source code.

    • Use the same resource identifiers throughout the life of the project. Changing identifiers makes it difficult to update localized resources from one version of the application to another.

    • If the same string is used in multiple contexts, make multiple copies of the string. The same string might have different translations in different contexts.

    • Allocate text buffers dynamically because text size might change when text is translated.

    • Be aware that dialog boxes might expand because of localization.

    • Avoid text in bitmaps and icons.

    • Do not create a text message dynamically at run time.

    • Avoid composing text that uses multiple insertion parameters in a format string.

    • If localizing to a Middle Eastern language such as Arabic or Hebrew, use the right-to-left layout APIs to lay out text in the application from right to left.

    • Test localized applications on all language variants of the operating system.


Lesson 2: Planning for Administrative Features

Administrative features are an important part of a solution. In this lesson, you will learn how to design and plan administrative features such as monitoring, data migration, and the licensing specifications of a solution.

After this lesson, you will be able to

  • Plan for monitoring in a solution.

  • Plan for data migration.

  • Create licensing specifications.

Estimated lesson time: 10 minutes
How to Plan for Monitoring

Application monitoring is used to ensure that the application is functioning correctly and performing at an optimal level. Automated monitoring enables identification of failure conditions and potential problems. Monitoring helps to reduce the time needed to recover from failures.

Typically, application monitoring is the responsibility of administrators and operators within the operations team. It is critical for an operations team to establish guidelines and procedures for application monitoring. Communicating these procedures to the development team allows both teams to work together to log and monitor information that can assist problem discovery and problem diagnosis. This process is ongoing and requires revision; both the operations and development teams should strive to continually refine monitoring processes.

Error logging is closely related to monitoring and is a development function. You should design an appropriate strategy for error management at an early stage during the design phase. The development team must communicate with the operations team to inform them of the types of error logs generated by the application. The operations team must inform the development team of the various mechanisms that are available for monitoring errors. Together, both teams must decide on the appropriate logging mechanisms and then develop and monitor applications accordingly.

The monitoring plan

The monitoring plan defines the process by which the operational environment will monitor the solution. It describes what will be monitored, how it will be monitored, and how the results of monitoring will be reported and used. Organizations use automated procedures to monitor many aspects of a solution.

The plan provides details of the monitoring process, which will be incorporated into the functional specification. Once incorporated into the functional specification, the monitoring process (manual and automated) is included in the solution design. Monitoring ensures that operators are made aware that a failure has occurred so that they can initiate procedures to restore service. Additionally, some organizations monitor their servers’ performance characteristics to identify usage trends. This process allows organizations to identify the conditions that contribute to system failure and to take action to prevent those conditions from occurring.

Elements of the monitoring plan

Some of the key sections of the monitoring plan are:

  • Resource threshold monitoring. Identifies the solution resources that will be monitored. This section also includes the threshold values of each of the resources. A threshold value might be, for example, when processor usage increases to more than 80 percent.

  • Performance monitoring. Defines the performance metrics to be gathered for the performance of the solution and the individual components of the solution. This section indicates the events that will be recorded and monitored, their frequency of occurrence, start and end times, and success and failure status. For example, you can record the logon attempts made by users, and the number of repeated failed logon attempts by the same user.

  • Trend analysis. Defines the analysis that will take place on the data collected during performance monitoring. You can use this information for predicting the performance of the application under varying situations. For example, you can predict the number of users for various parts of the day and determine how the application will perform under varying loads.

  • Detecting failures. Describes how the development, operations, and maintenance teams will use the functional specification and user acceptance criteria to detect failure incidents. You use the functional specification to determine the success criteria for the solution. This information is also included in the user acceptance criteria. For example, if shoppers must be able to browse items and select them from a list, and the list does not display any items, the event is marked as a failure.

  • Error detection. Describes the processes, methods, and tools teams will use to detect and diagnose solution errors. These errors are typically identified and resolved by the development, operations, and maintenance teams without the knowledge of the users.

  • Event logs. Describes the logs that will provide a system for capturing and reviewing significant application and system events. For example, you can use Microsoft SQL Server™ logs for an application that uses a SQL Server database.

  • Notifications. Describes how the operations team will be notified when monitoring and exception trapping has detected solution failures. Notification methods can include pagers and e-mail.

  • Tools. Describes the tools teams can use to detect, diagnose, and correct errors and to improve a solution’s performance. The team can use tools such as Microsoft Systems Management Server and System Monitor.

How to Plan for Data Migration

When data from earlier or existing sources is identified as a part of the new solution, data migration becomes a critical element. Without well-tested migration paths, new solutions can fail because earlier components can introduce risks that were never accounted for during planning. If data from earlier systems cannot be migrated successfully to the new solution, the new solution cannot be deployed and a return on investment cannot begin.

The migration plan describes the migration from existing systems or applications to the new solution. Migration is often more important in infrastructure deployment than it is in application development projects, but application development projects usually include some sort of migration.

The migration plan includes the following sections:

  • Migration strategies. Describes the strategy or strategies that will guide the migration process. These strategies do not need to be mutually exclusive but can describe different pieces of the overall migration. Strategy can be organized around releases (related to the business or to development or technology maturity) or organized around solution components. These strategies also need to take into account moving earlier systems into the new solution environment. You might have multiple migration strategy sections if you need to migrate both business objects and data.

  • Tools. Identifies the tools that will be used to support the migration strategy. These tools can include conversion tools, installation tools, testing tools, and training tools.

  • Migration guidelines. Describes the guidelines that must be followed within the environment, such as how migrated data will be validated or in what order data must be migrated.

  • Migration process. Describes how the migration will be conducted. It includes the preparatory activities in addition to the migration stages necessary to complete the migration process.

  • Test environment. Describes the test environment that replicates the production environment. This includes all environmental attributes that must be in place.

  • Rollback plan. Describes how a customer can roll back to the prior configuration if problems occur during migration.

How to Create Licensing Specifications

It is a good practice to determine purchasing requirements early in the project for both hardware and software that will be required by the solution. Purchasing specifications developed early in the process ensure that there is sufficient time for the approval process and that vendors have sufficient time to deliver hardware so as not to affect the schedule. An important part of purchasing specifications is licensing specifications.

You need to provide licensing specifications for both the developing and deploying phases. During the developing phase, the team will work with selected technologies and software products. You must ensure that you have sufficient licenses of the required products.

Depending on the type of solution and the number of users who will use the solution, you need to specify the number of licenses of any software that might be used.

For example, if your application can be deployed only on Windows XP, you need the appropriate number of Windows XP licenses for all users to install and run the application.


Lesson 3: Planning for Future Phases

The MSF Process Model consists of five phases: envisioning, planning, developing, stabilizing, and deploying. During the planning phase, you plan what will be developed, how it will be developed, and who will develop it. You also create plans for the activities that must be performed in the subsequent phases.

In this lesson, you will learn to plan for tasks in the subsequent phases of the project.

After this lesson, you will be able to

  • Create plans for the developing phase.

  • Create plans for the stabilizing phase.

  • Create plans for the deploying phase.

Estimated lesson time: 5 minutes
How to Plan for the Developing Phase

Before the team actually begins developing the solution, it is important to verify that the infrastructure of the development and test environments is ready. The test environment should ideally represent the production environment, but the team must balance the level of representation with the associated costs. It is important to maintain separation between the production environment and the development and test environments to prevent occurrences in development and test from affecting live production systems.

The development plan

During the planning phase, the project team creates a master project plan and a master project schedule. In addition, the team can create a development plan and a development schedule. The development plan describes the solution development process used for the project, in addition to the tasks necessary to create and assemble the components of the solution. This plan complements the functional specification that provides the technical details of what will be developed. The plan also provides consistent guidelines and processes to the teams creating the solution.

Having the development process documented indicates that the team has discussed and agreed on a consistent structure and direction to be used during the development process. This documentation allows developers to focus on creating the solution. Development guidelines and standards promote meaningful communication among the various teams, because they will use a common approach and common processes. The guidelines and standards also facilitate reuse among different groups and minimize the dependency upon one individual or group.

The development role in the MSF Team Model creates the development plan and the development schedule. The focus of the development role during this process is to consider how key aspects of the development process should be undertaken.

Elements of the development plan

Some of the key sections of the development plan are:

  • Development objectives. Defines the primary drivers that were used to create the development approach and the key objectives of that approach.

  • Overall delivery strategy. Describes the overall approach to delivering the solution. Examples of delivery strategy include staged delivery, depth-first, breadth-first, and features then performance.

  • Tradeoff approach. Defines the approach for making design and implementation of tradeoff decisions. For example, you might agree to trade features for schedule improvements or to trade features for performance.

  • Key design goals. Identifies the key design goals and the priority of each goal. Examples of design goals include interoperability and security.

  • Development and build environment. Describes the development and build environment and how it will be managed. Include information on items such as source code control tools, design tool requirements, operating systems, or other software installed.

  • Guidelines and standards. Lists and provides references to all standards and guidelines to be used for the project.

  • Versioning and source control. Describes how versioning and source control will be managed. This section includes identification of the specific tools that will be used and how developers are expected to use them.

  • Build process. Describes the incremental and iterative approach for developing code and for builds of hardware and software components. It also describes how the build process will be implemented and how often it will be implemented.

  • Components. Provides a high-level description of the set of solution components and how they will be developed.

  • Configuration and development management tools. Identifies all the development tools the team will use during the project. This includes tools for all steps in the project: development, testing, documentation, support, operations, and deployment.

  • Design patterns. Identifies the design patterns or templates that the team will use for this project and their sources. The team can acquire design patterns from both external and internal sources or create new design patterns.

  • Development team training. Identifies the training necessary to ensure that the development team will successfully develop the solution.

  • Development team support. Identifies the various types of support the development team will require, the sources of that support, the amount of support of each type that the team will require, and the estimated schedule for support.

How to Plan for the Stabilizing Phase

During the stabilizing phase, the testing team conducts tests on a solution whose features are complete. Testing during this phase emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and prioritizing bugs and preparing the solution for release.

During the planning phase, the team typically creates the following plans that will be used during the stabilizing phase:

  • The test plan

  • The pilot plan

The test plan

The test plan describes the strategy and approach used to plan, organize, and manage the project’s testing activities. It identifies testing objectives, methodologies and tools, expected results, responsibilities, and resource requirements. This document is the primary plan for the testing team. A test plan ensures that the testing process will be conducted in a thorough and organized manner and will enable the team to determine the stability of the solution. A continuous understanding of the solution’s status builds confidence in team members and stakeholders as the solution is developed and stabilized.

The testing role in the MSF Team Model is responsible for creating the test plan. This team is also responsible for setting the quality expectations and incorporating them into the testing plan.

The test plan breaks the testing process into different elements, including:

  • Code component testing

  • Database testing

  • Infrastructure testing

  • Security testing

  • Integration testing

  • User acceptance and usability testing

  • Stress, capacity, and performance testing

  • Regression testing

Elements of the test plan

The key sections of a test plan are:

  • Test approach and assumptions. Describes at a high level the approach, activities, and techniques to be followed in testing the solution. If different approaches are required for the solution’s various components, you need to specify which components will be tested by each approach.

  • Major test responsibilities. Identifies the teams and individuals who will manage and implement the testing process.

  • Features and functionality to test. Identifies at a high level all features and functionality that will be tested.

  • Expected results of tests. Describes the results that should be demonstrated by the tests. This information includes expectations of both the solution team and the testers. This section also defines whether the results must be exactly as anticipated or whether a range of results is acceptable.

  • Deliverables. Describes the materials that must be made available or created to conduct the tests and that will be developed from the tests to describe test results.

  • Testing procedures and walkthrough. Describes the steps the testing team will perform to ensure quality tests.

  • Tracking and reporting status. Defines the information that test team members will communicate during the testing process. This section defines the specific test status information that will be created and distributed. This information normally includes status information for each test case and the probability of completing the test cycle on schedule.

  • Bug reporting tools and methods. Describes the overall bug reporting strategy and methodology. This section also defines what will qualify as a bug in the code, product features, and documentation.

  • Schedules. Identifies the major test cycles, tasks, milestones, and deliverables. This section also describes who is responsible for each test cycle and its tasks. In addition, it identifies the expected start and completion date for each test cycle and the tasks within that cycle.

For the test plan for the Adventure Works Cycles case study, refer to the AWC Test Plan document in the \SolutionDocuments\Chapter10 folder on the companion CD.

NOTE
Testing is covered in detail in Chapter 11, “Stabilizing and Deploying the Solution.”
The pilot plan

The pilot plan describes how the team will move the candidate release version of the solution to a staging area and test it. The goal of the pilot is to simulate the equipment, software, and components that the solution will use when it is active. This plan also identifies how issues discovered during the pilot will be solved. The pilot plan includes details about how to evaluate the pilot; the results of the evaluation will facilitate a decision whether to move the solution to production.

Project teams often conduct one or more pilots to prove the feasibility of solution approaches, to experiment with different solutions, and to obtain user feedback and acceptance on proposed solutions. Pilot solutions implement only those subsets or segments of requirements or the functional specification that are necessary to validate the solution.

NOTE
Some projects might not conduct a pilot.

The pilot plan provides the means to validate the business requirements and the technical specification prior to deploying the solution into production. Planning the details of the pilot ensures that the participating project teams identify their roles and responsibilities and resource requirements specific to pilot development, testing, and deployment activities.

NOTE
You can learn more about creating pilot plans in Chapter 11, “Stabilizing and Deploying the Solution.”
How to Plan for the Deploying Phase

During the deploying phase, the team deploys the solution technology and components, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project.

The deployment plan

During the planning phase, the team typically creates the deployment plan. The deployment plan describes the factors necessary for a relatively problem-free deployment and transition to ongoing operations. It includes the processes of preparing, installing, training, stabilizing, and transferring the solution to operations. These processes include details of installation scenarios, monitoring for stability, and verifying the soundness of the new solution. This plan guides the implementation of the solution into production. This plan also provides detailed deployment guidelines and helps drive the solution’s deploying phase. Deployment is the beginning of the realization of business value for a given solution. A detailed and verified deployment plan accelerates value realization for both the customer and the project team.

The release management role of the MSF Team Model is responsible for designing and implementing the solution’s deployment plan. Release management is also responsible for specifying the solution infrastructure and ensuring that the solution continues to run as expected after it has been deployed.

Elements of the deployment plan

Some of the key sections of the deployment plan are:

  • Deployment scope. Describes the solution architecture and scale of deployment.

  • Seats. Describes the magnitude of the deployment in terms of sites, number of workstations, countries and regions, and other relevant size factors.

  • Components. Lists and describes the components to be deployed and any critical dependencies among them.

  • Architecture. Describes the solution’s architecture and how it might affect deployment.

  • Deployment schedule. Identifies the critical dates and anticipated schedule for the deploying phase.

  • Installation. Defines how the overall deployment will occur.

  • Deployment resources. Identifies the workforce that will be needed to complete the deployment and the sources of the personnel.

  • Solution support. Describes how the users will be supported during the deployment.

  • Help desk. Describes the support provided to users and applications by the help desk team, including support for direct user questions and application issues, and also in-depth support for new or difficult issues.

  • Desktop. Describes any changes in current workstation application support that might be required during deployment.

  • Servers. Describes any changes in current server support that might be required during deployment.

  • Telecommunications. Describes any changes in current telecommunication support that might be required during deployment.

  • Coordination of training. Describes how end-user and support staff training is coordinated with the deployment schedule.

  • Site installation process. Describes the four phases of site installation: preparing, installing, training, and stabilizing.


Lesson 4: Creating the Technical Specification

To begin creating the solution, the development team uses the technical specification document. In this lesson, you will learn about technical specification and the components of a technical specification document.

After this lesson, you will be able to

  • Describe the purpose of technical specification.

  • List the elements of a technical specification document.

Estimated lesson time: 5 minutes
What Is the Technical Specification?

The technical specification is a set of reference documents that usually include the artifacts of physical design, such as class specifications, component models, metrics, and network and component topologies. During the developing phase, the developers use the technical specification to scope and define their work products. The technical specification includes interface definitions, registry entries, bytes required to install, dynamic-link library (DLL) and assembly names, strong names, keys, and all identified elements that will affect deployment. When elements of the solution are completed during development, the technical specification is updated to ensure that it documents the solution.

Elements of a Technical Specification Document

The sections of a technical specification include:

  • Architecture overview. Describes the architecture that will be implemented by the solution.

  • Object model. Describes the object model of the solution. This section includes a description of all objects in the solution and their functionality.

  • Interfaces. Contains the code and details of methods of each interface in the solution.

  • Code flow. Describes the operation of each method in the solution.

  • Error codes. Describes the error codes used for error handling in the solution.

  • Error logging. Describes how various errors will be handled and logged in the solution.

  • Configuration. Describes how the solution will be registered on the destination computer. This section includes registry keys and their settings.

  • Supporting documentation. Lists the documents that describe the solution, such as the functional specification, and their locations.

  • Issues. Describes any known issues with the solution. Typically, the probable date of resolution for each is also specified in this section.

For the technical specification for the Adventure Works Cycles case study, refer to AWC Technical Specification.doc in the \SolutionDocuments\Chapter10 folder on the companion CD. This is a draft version of the technical specification document, as it would look prior to the developing phase. This document is updated throughout the developing phase.


Activity: Reviewing a Test Plan and Technical Specification

In this activity, you use what you learned in the lessons to work through a review of a test plan and a technical specification.

Exercise 1: Reviewing a Test Plan

Open the document named AWC Test Plan.doc in the \SolutionDocuments\Chapter10 folder on the companion CD.

  1. Review the test plan and then list three ways that use cases and usage scenarios are used in the testing process for AdventureWorks Cycles.

  2. How will bugs be approved and documented for action for the solution?

  3. Which user accounts must be configured on the test environment servers?

  4. Why is the following threat important to list under threats to testing?

    Availability of sales staff for testing. The test team should be overseen by at least one sales representative. Mitigation: Gain prior agreement from the vice president of sales for two sales representatives to be assigned to test the application.

Exercise 2: Reviewing a Technical Specification

Open the document named AWC Technical Specification.doc in the \SolutionDocuments\Chapter10 folder on the companion CD. Answer the following questions:

  1. What are the parameters for the addOrderDetail method?

  2. Will two types of client interfaces be available in the application?

  3. Why is the Interfaces section still to be determined?


Summary

  • Scalability is defined as the capability to increase resources to yield a linear increase in service capacity.

  • You can either scale up or scale out an application.

  • Guidelines for scaling include:

    • Design processes so that they do not wait

    • Design processes so that they do not fight for resources

    • Design processes for commutability

    • Design components for interchangeability

    • Partition resources and activities

  • Availability is a measure of how often an application is available for use.

  • To decide the availability level of an application, you need to answer the following questions:

    • Who are the customers and what are their expectations?

    • How much downtime is acceptable?

    • Do internal company processes depend on the application?

    • What are the schedule and budget for developing the application?

  • Guidelines for designing for availability of a solution include:

    • Reduce planned downtime

    • Reduce unplanned downtime by using clustering

    • Use network load balancing

    • Use RAID for data stores

    • Isolate mission-critical applications

    • Use queuing

  • The process of designing for reliability involves reviewing the application’s expected usage pattern, specifying the required reliability profile, and engineering the software architecture with the intention of meeting the profile.

  • To create a good reliability design, you need to perform the following tasks:

    • Put reliability requirements in the specification.

    • Use a good architectural infrastructure.

    • Include management information in the application.

    • Use redundancy.

    • Use quality development tools.

    • Use reliability checks that are provided by the application.

    • Use consistent error handling.

    • Reduce the application’s functionality instead of completely failing the application.

  • An application’s performance is defined by key application metrics, such as transaction throughput and resource utilization.

  • To determine performance goals, you need to answer questions such as the following:

    • What is the business goal?

    • What is the critical functionality of the solution?

    • What are the features required by different sets of users?

  • To integrate heterogeneous applications, you need to consider the following types of interoperability:

    • Network interoperability, which provides the core foundation for interoperability between systems

    • Data interoperability, which delivers the ability for users and applications to access and query information stored in both structured and unstructured storage engines

    • Applications interoperability, which provides the key infrastructure required to ensure interoperability between new and existing applications

    • Management interoperability, which focuses on reducing the burden of administration of multiple systems, including user accounts management

  • Globalization is the process of designing and developing a software product that functions in multiple cultures and locales.

  • Localization is the process of adapting a globalized application to a particular culture and locale.

  • Application monitoring is used to ensure that the application is functioning correctly and performing at the optimal level.

  • The monitoring plan describes what will be monitored, how the application will be monitored, and how the results of monitoring will be reported and used.

  • The migration plan describes the migration from existing systems or applications to the new solution.

  • You need to provide licensing specifications for both the developing and deploying phases.

  • The development plan describes the solution development process used for the project.

  • The test plan describes the strategy and approach used to plan, organize, and manage the project’s testing activities, and identifies testing objectives, methodologies and tools, expected results, responsibilities, and resource requirements.

  • The pilot plan describes elements of the solution that will be delivered as a pilot and provides the details necessary to conduct the pilot successfully.

  • The deployment plan describes the factors necessary for a smooth deployment and transition to ongoing operations and includes the processes of preparing, installing, training, stabilizing, and transferring the solution to operations.

  • The technical specification is a set of reference documents that usually include the artifacts of physical design, such as class specifications, component models, metrics, and network and component topologies.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. How do you scale up an application?

  2. What do you need to take into consideration while designing for scalability?

  3. What do you need to take into consideration while designing for availability?

  4. How does clustering enhance the availability of an application?

  5. How do you reduce planned downtime of an application?

  6. Why is reliability an important design consideration for an application?

  7. How do you design for reliability of an application?

  8. How do you define a performance requirement?

  9. Why do you need to design for interoperability?

  10. How do you prepare an application for globalization?

  11. What is the purpose of a monitoring plan?

  12. What is the purpose of the migration strategies section of the migration plan?

  13. Why do you need to provide licensing specifications for both the development and the deployment phase?

  14. What is the purpose of the development plan?

  15. What is the purpose of the test plan?

  16. Who creates the deployment plan?

  17. What is a technical specification?


Chapter 11: Stabilizing and Deploying the Solution

Chapter 11
Stabilizing and Deploying the Solution
About This Chapter

After the development phase of a project is complete, the project enters its stabilizing and deploying phases. The goal of the stabilizing phase of the Microsoft® Solutions Framework (MSF) Process Model is to improve the quality of the solution to meet the acceptance criteria for release to production. During the deploying phase, the solution is deployed to the production environment.

Before You Begin

To complete the lessons in this chapter, you must have

  • General understanding of Microsoft technologies.

  • Understanding of the MSF process and its phases.


Lesson 1: The MSF Stabilizing Phase

During the stabilizing phase, testing is conducted on a solution whose features are complete. Testing starts early in the MSF process with activities such as defining the success criteria and the testing approach during the envisioning phase, and creating a testing plan during the planning phase. However, it is during the stabilizing phase that the Testing team completes the tasks and creates the deliverables that move the feature-complete build to a state in which the defined quality level is reached and the solution is ready for full production deployment.

Testing during this phase emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and prioritizing bugs and preparing the solution for release.

The two main tasks in the stabilizing phase are:

  • Testing the solution. The team implements the test plans that were created during the planning phase, which were enhanced and tested during the development phase.

  • Conducting the pilot. The team moves a solution pilot from development to a staging area to test the solution with actual users and real scenarios. The pilot is conducted before the deploying phase is begun.

After this lesson, you will be able to

  • Explain the deliverables of the MSF stabilizing phase.

  • Explain the interim milestones of the MSF stabilizing phase.

  • Explain the team roles and responsibilities during the stabilizing phase.

Estimated lesson time: 15 minutes
MSF Stabilizing Phase Deliverables

The goal of the MSF stabilizing phase is to improve the quality of a solution and to stabilize it for release to production. During this phase, the team conducts testing on a feature-complete solution. The testing in this phase also includes testing the accuracy of supporting documentation, training, and other non-code elements.

The following are the deliverables of the stabilizing phase:

  • Pilot review

  • Release-ready versions of:

    • Source code and executables

    • Scripts and installation documentation

    • End-user Help and training materials

    • Operations documentation

    • Release notes

  • Testing and bug reports

  • Project documents

MSF Phase Interim Milestones

In addition to the deliverables, the stabilizing phase has interim milestones. The interim milestones of the stabilizing phase are:

  • Bug convergence

  • Zero-bug bounce

  • Release candidates

  • Golden release

Bug convergence

Bug convergence is the point at which the team makes visible progress against the active bug count. It is the point at which the rate of bugs that are resolved exceeds the rate of bugs that are found.

Figure 11.1 illustrates bug convergence.

Figure 11-1 Bug convergence
Figure 11-1. Bug convergence

Because the bug rate will still vary—even after it starts its overall decline—bug convergence usually manifests itself as a trend rather than a fixed point in time. After bug convergence, the number of bugs should continue to decrease until zero-bug release.

Zero-bug bounce

Zero-bug bounce (ZBB) is the point in the project when development resolves all the bugs raised by Testing and there are no active bugs—for the moment. Figure 11.2 illustrates ZBB.

Figure 11-2 Zero-bug bounce
Figure 11-2. Zero-bug bounce

After zero-bug bounce, the bug peaks should become noticeably smaller and should continue to decrease until the product is stable enough to release.

Careful bug prioritization is vital because every bug that is fixed creates the risk of creating a new bug, or regression issue. Achieving zero-bug bounce is a clear sign that the team is in the final stage as it progresses toward a stable product.

NOTE
New bugs will certainly be found after this milestone is reached. But it does mark the first time that the team can honestly report that there are no active bugs—even if it is only for the moment—and it focuses the team on working to stay at that point.
Release candidates

After the first achievement of zero-bug bounce, a series of release candidates are prepared for release to the pilot group. Each of these releases is marked as an interim milestone. The release candidates are made available to a preselected group of users so they can test it. The users provide feedback to the project team, and the project team in turn continues to improve the product and resolve bugs that appear during the pilot. As each new release candidate is built, there should be fewer bugs to report, prioritize, and resolve. Each release candidate indicates that the team is nearing the end of deployment.

Golden release

Golden release is the release of the product to production. Golden release is a milestone in the stabilizing phase, which is identified by the combination of zero-defect and success criteria metrics. At golden release, the team must select the release candidate that they will release to production. The team uses the testing data that is measured against the zero-defect and success criteria metrics and the tradeoff triangle to make this selection.

Team Focus During the Stabilizing Phase

Each team role has a specific focus and responsibilities during stabilization. The primary team roles that drive the stabilizing phase are testing and release management. Table 11.1 describes the roles and responsibilities of each team during the stabilizing phase.

Table 11-1. Stabilizing Phase Roles and Responsibilities
Role | Focus
Product management | Communications plan execution; production launch planning
Program management | Project tracking; bug priority
Development | Bug resolution; code optimization
User experience | Stabilization of user performance materials, training materials, user assistance materials
Testing | Testing; bug reporting and status; configuration testing
Release management | Pilot setup and support; deployment planning; operations and support training


Lesson 2: Testing and Piloting for Stabilization

The testing process is designed to identify and address potential solution issues prior to deployment. Testing certifies that the solution components meet the project plan’s goals for schedule and quality. It should also verify that the solution components meet the agreed-upon feature set.

The development team designs, documents, and writes code that is tested through unit testing and daily builds. This team tracks development progress against a project schedule, resolves reported bugs, and documents testing results.

The testing team designs and documents test specifications and test cases, writes automated scripts, and runs acceptance tests on components that are submitted for formal testing. This team assesses and reports on overall solution quality and feature completeness, and certifies when the solution features, functions, and components meet the project goals.

After this lesson, you will be able to

  • Identify the best practices of testing.

  • Explain the types of testing in the MSF process.

  • Explain the testing terms.

  • Explain the issue and bug tracking process.

  • Identify some of the tasks involved in testing.

  • Explain the process of conducting a pilot.

  • Close the stabilizing phase.

Estimated lesson time: 40 minutes
Testing Best Practices

There are some testing best practices that the testing team should consider implementing when testing a solution.

Success criteria

Judging whether a project has been successful is almost impossible without something to measure the project’s results against. The creation of success criteria involves defining conditions under which the proposed solution will achieve its goals. Success criteria are sometimes referred to as key performance indicators.

NOTE
Although defined here, success criteria for a project needs to be established during the envisioning and planning phases.
Zero-defect mindset

Zero-defect mindset means that the project team commits to producing the highest quality product possible. Each team member is individually responsible for helping achieve the desired level of quality. The zero-defect mindset does not mean that the deployed solution must be perfect with literally no defects; rather, it specifies a predetermined quality bar for the deliverables.

Testing Types

MSF defines two types of testing: coverage testing and usage testing.

Coverage testing

Coverage testing is low-level technical testing. For example, when a developer writes a section of code or a subject matter expert creates an automated unattended installation, he or she typically performs low-level testing to ensure that the solution meets the functional specification. In MSF, this type of testing is called coverage testing; in Microsoft product groups, it is also referred to as prefix testing.

Of course, if developers or subject matter experts are the only groups to perform coverage testing, risk is increased. Their closeness to the work and the pressures to deliver a finished product make it difficult for them to identify all issues and bugs in the solution. This is where external coverage testing can help. External coverage testing is low-level testing that is performed by a tester other than a developer or subject matter expert. Often this external coverage testing is automated to promote consistency and speed.

A typical strategy that is used for performing the coverage testing role is to use the buddy tester principle. Buddy testing involves using developers who are not working directly on the creation of a particular code segment, and employing them to perform coverage testing on their colleague’s code. This strategy works well because the skills that are required by coverage testers are on the same level as the skills that are required for development.

Usage testing

Usage testing is high-level testing that is often performed by potential users of the solution or subsets of this group. This type of testing is very important because it ensures that issues and bugs that are related to user performance enhancement are captured and addressed. Automated scripts and check lists are a best practice in this area because they provide repeatability and prescriptive direction to the usage tester, which will improve accuracy.

Testing Terms

Before you learn more about testing a solution, it is important to be familiar with some basic testing terms.

Check-in tests

Check-in testing ensures that tested code is behaving acceptably. This type of testing is performed by developers or testers before the code is checked in to the change control system. Check-in testing can be thought of as the aggregation of all internal coverage tests that are performed by developers before the code is checked in to the change control system.

Unit tests

A unit test is a form of developer-performed internal coverage testing or prefix testing that takes advantage of automated testing. The philosophy behind unit testing is to perform testing on isolated features (one small piece at a time).

Functional tests

Functional tests are normally specified by the users of the solution and are created by the testing team. These tests are often automated tests and are normally conducted by the testing team. They focus on testing end-to-end functionality rather than isolated features.

Build verification tests

The objective of build verification testing is to identify errors during the build process. It can be thought of as the identification of compilation errors, as opposed to run-time errors, of all solution components. This type of testing can be performed by both developers and testers. For some projects, a specific team might perform these tests.

Regression tests

Regression testing is the process of repeating identical actions or steps that were performed using an earlier build of a product on a new build or version of the product. The goal of this process is to determine the following:

  • Is the problem you previously reported still present?

  • Has the problem been completely resolved?

  • Did the resolution cause other or related problems?

Configuration tests

Most software-based solutions can be installed and configured in many different ways. The aim of configuration testing is to conduct solution tests in each of the possible solution configurations. Each of these configurations has the potential to affect the behavior of the solution and might result in the identification of new issues or bugs.

Compatibility tests

Often there is a requirement for the solution under development to integrate and interoperate with existing systems or software solutions. This form of testing focuses on integration or interoperability of the solution under development with existing systems.

This type of test often involves groups that are external to the project team. The external team must be identified as early as possible so its involvement can be planned for. Also, performing these tests in a completely isolated environment might not be possible.

Stress tests

Stress tests, also known as load tests, are specifically designed to identify issues or bugs that might present themselves when the solution under development is highly stressed. By stressing the solution, which most commonly entails loading the solution beyond the level that it was designed to handle, new issues or bugs might be seen.

Performance tests

Performance testing focuses on predicted performance improvements by the solution under development. These tests are often performed in conjunction with stress or loading tests. For example, if a design goal of the solution under development is to increase e-mail message throughput by 15 percent, tests would be devised to measure this predicted increase.

Documentation and Help file tests

This form of testing focuses on testing all developed support documents or systems. The documents and Help files are compared with the solution to discover any discrepancies. For example, testers might look for incorrect instructions, outdated text and screen shots, typographic errors, and so on.

Alpha and beta tests

In the MSF testing discipline, alpha code broadly refers to all code produced in the developing phase of the MSF Process Model, whereas beta code is all code tested in the stabilizing phase. Therefore, during the developing phase of the MSF Process Model tests are performed on alpha code, whereas during the stabilizing phase of the MSF Process Model tests are performed on beta code.

Parallel testing

Parallel testing is a common usage testing strategy. Parallel usage testing is testing both the current solution and the new solution, under development, side-by-side at the same time. The advantage of parallel usage testing is that it provides a quick check on expected solution behavior. For example, data is entered into the current solution and behaviors are observed. Then, the same data is entered into the new solution and its behavior is observed. These two observed behaviors can then be compared and used as usage testing data.

Planning
Parallel testing can be automated to quickly help validate the results without involving production users. However, the disadvantage of parallel testing is that if parallel testing cannot be automated, it doubles the work load of production users.
How to Categorize and Track Bugs

It is impossible to release a high quality solution to production without data from an issue or bug tracking system. Without a bug tracking system, the team cannot judge whether the zero-defect criteria have been met.

Categorization process

The MSF issue or bug categorization process builds on the risk categorization system of the MSF risk management process. In the MSF risk categorization system, team members are asked to estimate risk probability and impact, and these two variables are multiplied together to derive the risk exposure value, which is used in turn to prioritize these risks.

The issue or bug categorization prioritization system is a similar system. A risk is something that has not yet occurred, so probability of occurrence and impact of the risk to the project are appropriate variables to estimate. However, issues or bugs are things that have happened or exist now. The important variables to an individual issue or a bug are:

  • Repeatability. A variable that measures how repeatable the issue or bug is. Repeatability is the percentage of the time the issue or bug manifests itself. Is the issue or bug 100 percent repeatable, or can it be reproduced only 10 percent of the time? Note that zero is not a valid metric here because it would mean the issue or bug is never repeatable.

  • Visibility. A variable that measures the situation or environment that must be established before the issue or bug manifests itself. For example, if the issue or bug occurs only when the user holds down the Shift key while right-clicking the mouse and viewing the File menu, the percentage of obscurity is high. A highly obscure issue or bug is not very visible and therefore not as compelling as a highly visible issue or bug.

  • Severity. A variable that measures how much impact the issue or bug will produce in the solution, in the code, or to the users. For example, when an issue or bug occurs, does it crash the operating system or application, or does it cause one pixel of color to change on a menu bar? To be able to assign severity, the project team needs to define a list of problematic situations, with associated severity. For example, if the system crashes with loss of data and no workaround, it is severity 10; if it crashes with loss of data but with a workaround, it could be severity 9.

These three variables are estimated and assigned to each issue or bug by the project team and are used to derive the issue or bug priority. Table 11.2 describes the symmetrical scales to assign a value to each variable.

Table 11-2. Variables for Categorizing Bugs
Variable | Scale
Repeatability | A percentage in the range of 10% (integer value ‘0.1’) through 100% (integer value ‘1’), where 100% indicates that the issue or bug is reproducible on every test run.
Visibility | A percentage in the range of 10% (integer value ‘0.1’) through 100% (integer value ‘1’), where 10% indicates that the issue or bug is visible under only the most obscure conditions. Issues or bugs that manifest themselves in environments with simple conditions are said to be highly visible.
Severity | An integer in the range of 1 through 10, where classification 10 issues or bugs present the most impact to the solution or code.

The priority of a bug can be calculated by using the following formula:

(Repeatability + Visibility) * Severity = Priority

Table 11.3 provides an example of this priority calculation displayed in a matrix.

Table 11-3. Bug Prioritization Matrix
Description | Repeatability | Visibility | Severity | Priority | Submitted By | Assigned To
Description | 1 | 1 | 10 | 20.0 | Name | Name
Description | 0.9 | 0.9 | 9 | 16.2 | Name | Name
Description | 0.8 | 0.8 | 8 | 12.8 | Name | Name
Description | 0.7 | 0.7 | 7 | 9.8 | Name | Name
Description | 0.6 | 0.6 | 6 | 7.2 | Name | Name
Description | 0.5 | 0.5 | 5 | 5.0 | Name | Name
Description | 0.4 | 0.4 | 4 | 3.2 | Name | Name
Issue or bug tracking process

The bug tracking process, shown in Figure 11.3, is driven by the development and testing roles.

Figure 11-3 Issue or bug tracking process
Figure 11-3. Issue or bug tracking process

The steps in the bug tracking process are:

  1. Developers develop code, perform internal coverage testing, and then check this code into the change control system.

  2. Testers perform the daily or periodic build and external coverage testing on all submitted code.

  3. Testers submit issues or bugs into the issue or bug tracking system, entering issue or bug descriptions and Repeatability, Severity, and Visibility variables.

  4. The development and test leads conduct a Prioritization or Issue/Bug Prioritizing meeting and:

    • Calculate the priority of each issue or bug. This task is referred to in the MSF Testing Method as Issue/Bug Prioritizing.

    • Assign issues or bugs that exceed the zero-defect criteria to developers for correction.

    • Retire issues or bugs from a previous cycle of the sub-process that were corrected.

  5. Assigned developers resolve or correct issue or bug.

  6. Developers perform internal coverage testing and then check this code into the change control system.

This is a continuous process that starts again when developers develop code and check it into the change control system.

Testing Tasks

Two important tasks in the MSF Testing Method are code reviews and development environment construction. These two project tasks are very important to the successful implementation of the MSF Testing Method.

Code reviews

The MSF Testing Method defines three types of code reviews:

  • Comprehensive. A comprehensive code review is a formal review in which the developer is asked to present or walk through his or her code with the rest of the development team.

  • Casual. A casual code review is a peer-based review that is conducted by other developers from the direct development team. This is a particularly good strategy to mentor junior developers.

  • Independent. An independent code review is a review that is conducted by a third-party organization with the goal of providing a fresh set of eyes to review the code.

Testing environment construction

Before any development and therefore testing work can proceed, it is important that a development and testing environment is designed and built. This environment must be separated from the production environment and be capable of accommodating both development and testing requirements. Typical testing requirements are:

  • Build hardware to enable the testers to perform the daily and periodic builds.

  • Automate testing to facilitate the automation of as many test functions as possible.

  • Create change control systems; these systems must be in place and accessible to the testers.

  • Create issue or bug tracking systems; these systems must be in place and accessible to the testers.

How to Conduct a Pilot

A pilot is a test of the solution in the production environment, and a trial of the solution by installers, systems support staff, and end users. The primary purposes of a pilot are to demonstrate that the design works in the production environment as expected and that it meets the organization’s business requirements. A secondary purpose is to give the deployment team a chance to practice and refine the deployment process.

A pilot tests the solution under live conditions and takes various forms depending on the type of project.

  • In an enterprise, a pilot can consist of a group of users or a set of servers in a data center.

  • In Web development, a pilot can take the form of hosting site files on staging servers or folders that are live on the Internet, only with a test Web address.

  • Commercial software vendors, such as Microsoft, often release products to a special group of early adopters prior to final release.

These various forms of piloting have one element in common—the tests occur in a live production environment. The pilot is not complete until the team ensures that the proposed solution is viable in the production environment and every component of the solution is ready for deployment.

Process

The pilot is the last major step before full-scale deployment of the solution. Prior to the pilot, integration testing must be completed in the test lab environment.

The pilot provides an opportunity for users to provide feedback about how features work. This feedback must be used to resolve any issues or to create a contingency plan. The feedback can help the team determine the level of support they are likely to need after full deployment. Some of the feedback can also contribute to the next version of the product.

IMPORTANT
Ultimately, the pilot leads to a decision either to proceed with a full deployment or to delay deployment so you can resolve problems that could jeopardize deployment.

The pilot process is iterative. It starts with planning tasks, such as creating a pilot plan and preparing users and sites, and then moves to implementing the pilot, evaluating the results, fixing problems, and deploying another version until reaching the scope and quality that indicate the readiness for a full deployment.

Figure 11.4 illustrates the primary steps for planning and conducting a pilot.

Figure 11-4 Conducting a pilot
Figure 11-4. Conducting a pilot
Preparing for the pilot

A pilot deployment needs to be rehearsed to minimize the risk of disruption for the pilot group. At this stage, the development team is performing last-minute checks and ensuring that nothing has changed since pre-production testing. The following tasks need to be completed before starting the pilot:

  • The development team and the pilot participants must clearly identify and agree on the success criteria of the pilot. The criteria should map back to the success criteria for the development effort.

  • A support structure and issue-resolution process must be in place. This process might require that support staff be trained. The procedures used for issue resolution during a pilot can vary significantly from those used during deployment and when in full production.

  • To identify any issues and confirm that the deployment process will work, it is necessary to implement a trial run or a rehearsal of all the elements of the deployment.

  • It is necessary to obtain customer approval of the pilot plan. Work on the pilot plan starts early during the planning phase so that the communication channels are in place and the participants are prepared by the time the test team is ready to deploy the pilot.

    TIP
    The pilot sets the tone for the full deployment, so it is important that the plan is developed carefully and communicated effectively to the participants, and that the results are evaluated thoroughly.

    A recommended pilot plan includes the following:

    • Scope and objectives

    • Participating users, locations, and contact information

    • Training plan for pilot users

    • Support plan for the pilot

    • Communication plan for the pilot

    • Known risks and contingency plans

    • Rollback plan

    • Schedule for deploying and conducting the pilot

Implementing the pilot

Avoid the mistake of making pilot testing too easy. As much as possible, try every use case and scenario that will arise in production, including operations tasks, by including various use cases and scenarios in the rollout group. It is also recommended that you intentionally cause the pilot to fail so that you can test rollback procedures, disaster recovery, and business continuity planning.

Evaluating the results

At the end of the pilot, its success is evaluated and the next step is recommended. The project team then needs to decide whether to continue the project beyond the pilot. To help with the evaluation and recommendation, analyze information from a variety of sources. For example, obtain information from:

  • Web site feedback forms

  • Sessions with business managers

  • Problem reports

  • End-user surveys

  • Observations of the IT project team

  • Solution and operating system logs

It is important to obtain information about both the design and the deployment processes. Review what worked and what did not work so that it is possible to revise and refine the plan. Example of information to be gathered includes:

  • Training required for using the solution

  • Rollout process

  • Support required for the solution

  • Communications

  • Problems encountered

  • Suggestions for improvements

The feedback is used to validate that the delivered design meets the design specification, as well as the business requirements. The pilot is then evaluated to answer the following questions:

  • Did the pilot meet the success criteria you defined before the pilot began?

  • If metrics were established to measure your success, how did the pilot measure up?

After the data is evaluated, the team must make a decision. The team can select one of following strategies:

  • Stagger forward. Prepare another release candidate and release it to the original group and then to additional groups in serial fashion. The release to more than one group might have been part of the original plan or might have been a contingency triggered by an unacceptable first pilot.

  • Roll back. Return the pilot group to their pre-pilot state.

  • Suspend the pilot. Put the solution on hold or cancel it.

  • Patch and continue. Fix the build that the pilot is running and continue.

  • Proceed to deployment phase. Move forward to deploy the pilot build to the full live production environment.

Outputs of conducting a pilot

As cycles of the pilot tests are completed, the team prepares reports detailing each lesson learned and how new information or issues are resolved. The following can result from performing the pilot testing:

  • The identification of additional risks

  • The identification of frequently asked questions for training purposes

  • The identification of user errors for training and documentation purposes

  • The ability to secure buy-in and support from pilot users

  • Documentation of concerns and issue resolutions

  • Updates to documentation—particularly Help files and deployment plans

  • Determination of whether all success criteria were met

How to Close the Stabilizing Phase

Closing the stabilizing phase requires completing a milestone approval process. The team needs to document the results of the different tasks it has performed in this phase to submit the project to management for approval.

The stabilizing phase culminates in the release readiness approved milestone. This milestone occurs when the team has addressed all outstanding issues and has released the solution and made it available for full deployment. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues they need to address before beginning the transition to deployment and, ultimately, release.

After all of the stabilization tasks are complete, the team must formally agree that the project has reached the milestone of release readiness. As the team progresses from the release milestone to the next phase of deploying, responsibility for on-going management and support of the solution officially transfers from the project team to the operations and support teams. By agreeing, team members signify that they are satisfied with the work that is performed in their areas of responsibility.

Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference.


Lesson 3: The MSF Deploying Phase

At the end of the stabilizing phase, the release readiness approved milestone indicates the solution’s readiness for deployment into the production environment.

During the deploying phase, the team deploys the solution technology and components, stabilizes the deployment, moves the project to operations and support, and obtains final customer approval of the project. After the deployment, the team conducts a project review and a customer satisfaction survey. Stabilizing activities might continue during this period as the project components are transferred from a test or staging environment to a production environment.

After this lesson, you will be able to

  • Describe the dynamics of the team composition during deployment.

  • Explain the goal, milestones, and deliverables of the MSF deploying phase.

Estimated lesson time: 15 minutes
MSF Deploying Phase Milestones and Deliverables

The main deploying tasks include preparing for deployment and then deploying the solution. After deployment, stabilization, and transfer to operations, the project team conducts a project review.

The deploying phase culminates in the deployment complete milestone. Deliverables during this phase are:

  • Operations and support information systems

  • Procedures and processes

  • Knowledge base, reports, and logbooks

  • Repository of all versions of documents, configurations, scripts, and code

  • Project closeout report

    • Project documents

    • Customer survey

    • Next steps

Team Focus During the Deploying Phase

After completing the stabilizing phase, the project team can migrate to the deploying phase in a variety of ways. One deployment option is to use the organization’s operations team to handle the actual deployment. If the operations team manages the entire deployment, representatives from the development team usually remain on the project for a period of time after going live to mitigate potential problems during the transfer of ownership. Another option is to combine members from each group and create a separate deployment team. The release management role is responsible for coordinating the required activities that ensure a successful deployment.

Table 11.4 lists the focus and responsibility areas of each team role during deploying.

Table 11-4. Deploying Phase Roles and Responsibilities
Role | Responsibility
Product management | Customer feedback, assessment, sign-off
Program management | Solution/scope comparison; stabilization management
Development | Problem resolution; escalation support
User experience | Training; training schedule management
Testing | Performance testing; problem identification, definition, resolution, and reporting
Release management | Site deployment management; change approval
Deployment Scenarios

Some of the solution scenarios for deployment include Web applications and services, client/server applications, packaged applications, enterprise infrastructure, and mobile applications.

The MSF process model works regardless of the type of project you are trying to deploy. However, the complexity and length of the deploying phase varies depending on what you are deploying. For example, a Web application can be deployed with ease and minimal impact to physical locations, geographies, and workstations, whereas an infrastructure project that involves rolling out workstations is a longer and more complicated process. It is essential to make sure the team’s solution scenario for deployment is appropriate for the project type.

In addition to the solution scenarios, it is necessary to consider the types of hardware and operating system requirements when deploying a solution. A solution needs a different type of solution scenario depending on whether it is to be deployed to a datacenter, to a group of enterprise servers, or to mobile devices. Some of the hardware and operating system requirements for solution scenarios include:

  • Enterprise servers

  • Datacenter (Internet, department, global)

  • Web services

  • Clients (desktop, mobile)


Lesson 4: Deploying to a Production Environment

This lesson focuses on the considerations that are involved in deploying a solution to a production environment and the steps that are taken in the deployment.

After this lesson, you will be able to

  • Explain how to plan for deployment.

  • Distinguish between core and site-specific components.

  • Deploy core components.

  • Deploy site-specific components.

  • Explain how to prepare for the transition to operations.

  • Describe the steps for deploying the solution to a production environment.

  • Explain the closeout activities for the deploying phase.

Estimated lesson time: 30 minutes
How to Plan for Deployment

During development and especially as the stabilizing phase nears completion, the release management lead assigns deployment tasks to staff members. These individuals review the project status and test results, and update the deployment plan, which is initially created during the planning phase. The team creates task-based procedures that help ensure a successful deployment.

Staging and production environments

To be ready for deployment, the physical infrastructure, system software, and application software are tested, installed, and configured in their respective environments.

Documentation

The project team and operations representatives revisit and update the following documentation:

  • Deployment diagrams that are created during the planning phase.

  • A test plan that includes coverage for areas that are exposed in real use. The operation team needs to update the test plans that were created during the planning phase.

  • A security plan that the operations team uses to ensure that all personnel are aware of the security standards and rules to which the project adheres.

  • A backup plan that will prevent the loss of data. During the planning phase, the team creates a plan for processes that the team will use for file and data backups to prevent loss of data. This is updated when planning for deployment.

  • A plan for analyzing system performance and site usage. The operations team is responsible for the site’s daily maintenance and routine care.

  • A plan for log handling and other administrative tasks.

  • A disaster recovery plan. During the planning phase, the team creates a disaster recovery plan that establishes what the team expects to happen to the solution, its equipment, personnel, and data should a crisis occur. During the planning process for deployment, the team will review the document and validate and update its contents.

  • A business contingency plan. During the planning phase, the team creates a business contingency plan, establishing what will happen if the business activities halt. When planning for deployment, the team reviews and validates the contents of the business contingency plan.

  • Training information. The team must ensure that support personnel who will maintain or update the solution are properly trained, and that proper channels or regulations are provided in the event of a disaster.

Deployment plan review

The deployment plan is created during the planning phase and revised throughout the development process. However, when planning for deployment, the release manager might need to make changes to the deployment plan because of changes made to the solution during development and stabilization. The release manager must review and revise the deployment plan and confirm that the team has accomplished the following tasks:

  • The deployment strategy is reviewed and approved.

  • Setup, installation, configuration, test, operation, and support procedures are available, reviewed, and approved.

  • Deployment procedures are documented, reviewed, and approved.

  • Hardware and software components are available and tested.

  • The deployment team has clearly defined roles, and the assigned personnel are trained and available.

  • There is a plan and ample resources for ownership transfer to the operations team.

Customer sign-off

The solution’s key stakeholders review the collateral documentation and solution and confirm that the solution is ready for deployment. The project team prepares an affidavit reiterating that the key stakeholders have reviewed the solution and the accompanying collateral documentation, and that they find the solution to be final and acceptable in the current state.

Core Components vs. Site-Specific Components

For efficient deployment of solutions, it is important to group components as core components and site-specific components.

Core components

Core components are components located at a central location that enable interoperability of the overall solution. Core components are usually the enabling technology of the enterprise solution. Examples of core components are:

  • Domain controllers

  • Network routers

  • Database servers

  • Mail routers

  • Remote access servers

Site-specific components

Components that are located at individual locations and enable users to access and use the solution are called site-specific components. Examples of site-specific components are:

  • Local routers

  • File print servers

  • Client applications, such as Microsoft Office XP

In most cases, core components must be deployed before site-specific components are deployed. For example, when Microsoft Exchange Server is deployed, the core backbone, which supports all sites, must be in place first, and only then can the site components be deployed.

How to Deploy Core Components

Deploying core components involves selecting an appropriate deployment strategy and then performing the deployment. Selecting a deployment strategy requires a thorough understanding of both the solution and the needs of the customer.

A core component is often shared by multiple locations; it is a critical or enabling part of the overall solution. For virtually any solution, you must deploy some core components before users can use the solution. When considering how to deploy a solution, it is necessary to identify those components that are not functionally vital to the overall solution and to decide on an effective strategy for deploying them. For many projects, the cost of deploying all core components first is excessive and unnecessary.

TIP
Devices that are functionally redundant and exist only to provide capacity usually do not need to be installed before deploying to the sites.

You can use two main strategies for deploying core components:

  • Serial. All core components are deployed prior to any site deployments. This approach has less risk and is adequate for short deployments and small environments.

  • Parallel. Core components are deployed as needed in parallel to support each site deployment. This is a more cost-effective approach for larger environments or for deployments that will extend over a longer period.

Depending on the solution scenario, the core technology might need to be deployed before or in parallel with site deployments.

How to Deploy Site-Specific Components

Site deployment represents a process within a process. It involves the execution of a well-thought-out plan for installing the solution. Figure 11.5 depicts the process of deploying site-specific components.

Figure 11-5 Site-specific deployment process
Figure 11-5. Site-specific deployment process

Sites can be deployed serially by fewer teams or in parallel by more teams. Parallel site deployment requires more coordination and provides less opportunity to deal with the ramp-up of usage. However, a more serialized deployment can introduce confusion to the users, especially when the new solution must coexist with an existing system.

Site deployment also involves the use of the system by users in a production environment. The team must take steps to ensure that the necessary operations and support infrastructures exist for these users as they gain access to the system. Site deployment involves four phases:

  • Preparing the site deployment

  • Installing the site deployment

  • Training during site deployment

  • Stabilizing the site deployment

Preparing for the site deployment

Preparing for site deployment involves three distinct activities: taking inventories, scheduling, and informing. A coordinator often performs these activities off-site. The coordinator validates all the deployment information collected during planning, creates a final schedule for the actual site deployment, and informs the team about when the deployment will occur. This phase is performed to validate the information about the site to make sure that nothing significant has changed since the site survey was performed during the planning phase. It is also used to verify that all required equipment for the deployment has been delivered to the site.

Installing the site deployment

To minimize disruption and confusion about the process, the team does not install the solution until all preparations are made. In some cases, last-minute issues that are uncovered during the preparatory phase might indicate the need to revisit the site after the issues are resolved.

NOTE
In some cases, the team might choose to delay activation until the solution is stable and users have undergone training.

During installation, the following tasks are performed:

  • Installing or upgrading required hardware or software

  • Validating that the installed systems function as expected

  • Activating the system for user access

During deployment, the team should have a support mechanism in place in case it encounters problems. Generally, developers and testers on the core project team should be ready to support the site deployment team.

Training during site deployment

It is the responsibility of the deployment team to ensure that all users receive suitable training. During the planning phase, the project team developed a training plan that prescribes the appropriate level and type of training for all users. Training can be delivered before, during, or after installation.

Use the following guidelines for training during site deployment:

  • Deliver appropriate training to each user

  • Vary training based on user background and experience

  • Include a variety of media as defined in the training plan

  • Train local support staff

Avoid the temptation to employ a one-size-fits-all strategy. If the training strategy requires all users to undergo the same training process, novice users will be forced to learn too quickly, and more experienced users will feel held back. Consider alternatives to the traditional courseware approach to training, such as coaching sessions and a mentoring program.

Stabilizing the site deployment

Stabilization is an important part of the site deployment process. It is never a good idea to install a solution and then simply walk away from the deployment. It is the responsibility of the deployment team to remain with the project until the team is comfortable putting it into production. For this to occur, the team must focus on the success criteria, obtain the customer’s approval, and collect user feedback to ensure satisfaction and evolve the site deployment process. Each site deployment should go through the sign-off process. During the planning phase, a person at the site should have been designated to have the authority to sign off on the site deployment.

What Is the Quiet Period?

The quiet period begins when deployments are complete. During the quiet period, the team begins transferring responsibility to operations and support. A quiet period of 15 to 30 days is needed to generate statistically useful data. The quiet period also serves as a baseline for the service-level agreement.

The operations plan and acceptance criteria established by the project team during the planning phase define service levels for the solution. These levels serve as a baseline for the service-level agreement (SLA), which operations begins monitoring when responsibility is transferred to them.

A service-level agreement is defined as an agreement between the service provider and the customer that defines the responsibilities of all participating parties and that binds the service provider to provide a particular service of a specific agreed-upon quality and quantity. It constrains the demands that customers can place on the service to those limits that are defined by the agreement.

How to Transfer the Project to Operations and Support

Disengaging from the project includes transferring operations and support functions to permanent staff. In many cases, the resources to manage the new systems already exist. In other cases, it might be necessary to design new support systems.

Some of the tasks that need to be performed during transferring the project to operations and support include:

  • Activate report systems. Ensure that you transfer call volume and issue resolution to the help desk. Transfer system faults, corrective actions, and trend analysis to operations.

  • Publish knowledge base. The knowledge base provides easy access to corrective knowledge and can be used by support teams and users.

  • Validate operations. Before disengaging from the project, verify that the operations are being performed.

NOTE
It is very important for the project team to transition responsibility for the deployment to a support group at the customer’s company. If the project team cannot transition the responsibility, the project team will become the support group. The customer will continue to rely on the project team for help with questions and support issues.
Closeout Activities

After deployment is complete and ownership and responsibility have been transferred to operations and support, the team performs closeout activities for the project.

When the team has obtained customer sign-off, the project is officially complete, and the team has reached the deployment complete milestone. The following are the closeout activities:

  • Survey customer satisfaction. The customer satisfaction survey provides an important opportunity for the team to receive feedback from the customer. It is a necessary component of the closeout report and represents validation of the entire project. At a minimum, the persons who are surveyed should include project sponsors and key stakeholders.

  • Prepare closeout report. The closeout report is the final physical deliverable of the deployment. It includes final versions of all the major deliverables: the vision/scope document, the functional specification, and so on.

    Typically, the closeout report also includes a summary of information solicited from the customers and users and a summary of the known next steps. Essentially, the closeout report answers the question, “Where do we go from here?”

  • Conduct project review. Typically, the team conducts two types of project reviews: team and customer. Most technology projects end with a meeting, or project review, in which team members review the project and identify areas that could be improved in future projects.

    The project review is an opportunity for the entire team to reflect on the process and outcomes of the implementation. The team documents this reflection as action items in the next project plan.

    IMPORTANT
    In addition, customer reviews are conducted with sponsors and key stakeholders to determine customer satisfaction levels, outstanding issues, and next steps.

  • Obtain customer approval. Upon project closeout, the product manager obtains the final sign-off from the customer, signaling the customer’s approval of the solution and permission to disengage from the project.


Activity: Prioritizing Bugs

In this activity, you use what you learned in the lessons to assign and prioritize bugs.

The project testing team has been testing the E-Commerce Web application and has identified a number of bugs. The following is a list of the identified bugs without any priority assigned to them:

  • In 12 out of 75 tests, the browser stopped responding when the user submitted an order. The order status on the server showed that it was submitted, but the user never received a confirmation or an order number in these instances.

  • If a sales representative applies a discount that is greater than 15 percent, the system accepts it without approval from a manager.

  • When the user is viewing the order confirmation page and he or she clicks Keep Shopping, the account logon page appears. This seems to occur only for users whose user names are longer than 8 characters. In the test database, this equates to 20 users out of 172.

  • When the customer logs on, the background of the Help page changes from white to off-white.

  • In 50 tests, the Track Orders page twice displayed order details for the wrong order.

  • Performing a load test of 1000 simultaneous users showed a degradation of 18 percent in performance. Average number of users to simultaneously access the E-Commerce Web site in production is estimated to be 300.

  • The copyright notice does not appear on the Order Confirmation page.

  • In 130 tests, the home page failed to load 6 times. Performing a refresh successfully loaded the home page.

  • Every time the home page appears, the View Cart button is missing. This happens even after something is placed in the cart.

  • In 40 tests, there were 2 instances in which the sales manager was unable to apply a discount that was greater than 15 percent to an order. In all 40 tests, the same sales manager account was used, but different products were added to the orders.

  • In 8 out of 50 tests, error HTTP 404 - File Not Found occurred when the user clicked Keep Shopping on the Order Confirmation page.

  • The list of catalogs does not appear when viewing product details for bicycle helmets.

  • If the sales manager is viewing product details and he or she presses the Enter key, the Help topics home page appears in the browser.

  • In 25 tests, the Order Confirmation page failed to appear 3 times.

  • In 25 tests, the Track Orders page failed to show the order details 16 times.

  • Every time the production clerk attempts to connect to the administration site over SSL, the following error message appears: “The page cannot be displayed. The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings.” The production clerk cannot access the data to manage the online catalog.

Estimate the repeatability, visibility, and severity of each of the preceding bugs. You might have to guess at some of the values based on the amount of information you have available. Then, using the formula discussed in the chapter, compute the priority of each of the bugs.

Open the C11Ex1.doc file in the \SolutionDocuments\Chapter11 folder on the companion CD to complete this exercise. One possible answer to this exercise can be found in C11Ex1_Answer.doc in the \SolutionDocuments\Chapter11 folder.


Summary

  • The purpose of the stabilizing phase is to reduce the risks of releasing the solution to production.

  • A successful stabilizing phase requires that the team make the transition from a mindset focused on building features to one focused on getting the solution to a known state of quality.

  • The goals of the deploying phase are:

    • Place the solution into a production environment.

    • Facilitate the smooth transfer of the solution from the project team to the operations team.

    • Secure customer approval that the project is complete.

  • Steps in the site deployment process are preparing, installing, training, and obtaining sign-off.

  • The project team can disengage from the project only after sign-off from the customer.

  • Deliverables of the deploying phase are operations and support information systems, repository of all versions of documentation and code, and project closeout reports.


Review

The following questions are intended to reinforce key information presented in this chapter. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the appendix.

  1. What are some of the specific goals of the stabilizing phase?

  2. How does ongoing analysis of bug convergence provide warning signs about the stability of the project?

  3. Why is zero-bug bounce a positive indicator for the project?

  4. What is a release candidate, and what are some of its features?

  5. What is a pilot, and what are its goals?

  6. Why should pilot testing not be too easy?

  7. What are the deliverables of the deploying phase?

  8. Which person or group is the best candidate to deploy the solution?

  9. What are some examples of core components? What are some examples of site components?

  10. What is the quiet period, and what are some of its features?

  11. What type of documents result from completing closeout activities?

  12. Which MSF role handles the final sign-off from the customer?

  13. What are the two types of project reviews that MSF advocates at the end of the deployment phase?


Appendix A: Questions and Answers

Appendix A
Questions and Answers
Chapter 1 Introduction to Designing Business Solutions Review

  1. Describe the differences between the waterfall model and the spiral model, and describe how MSF uses both in the MSF Process Model.

    The waterfall model is based on milestones. For a milestone to be achieved, all the tasks related to that phase must be completed. The next phase of development cannot be started until the milestone from the previous phase is completed. The clearly identifiable milestones of this model make it is easy to monitor the progress of the project and the schedule, and to assign responsibilities and accountability to the appropriate resources. The waterfall model is more applicable to projects that have clearly defined requirements and are not liable to modifications in the future.

    The spiral model was created with the intention of being able to refine the product requirements and project estimates on a regular basis. Each time the project goes through an iteration of the spiral model, the development team can assess the project and plan for the next iteration. However, because the spiral model has no clear checkpoints, monitoring the progress of the project is difficult. The spiral model is suited best for rapid development of small projects.

    The MSF Process Model incorporates the milestone approach of the waterfall model with the iterative approach of the spiral model. By using the process model, the development team takes an iterative approach to building a solution, while tracking the progress of each iteration by using milestones.

  2. In the MSF Team Model, who is responsible for the design process?

    The program management role is responsible for the design process.

  3. The tradeoff triangle describes the three types of tradeoffs that a project team and the customer can make. What is a fourth tradeoff that could be considered but that should never be compromised?

    Quality is another tradeoff that could be considered in addition to features, resources, and schedule. However, quality should be the last tradeoff to be compromised because of the poor results that would ensue.

  4. Using the following statement, complete the tradeoff matrix below.

    “Given a fixed feature set, we will choose resources and adjust the schedule as necessary.”

    Fixed

    Chosen

    Adjustable

    Resources

    X

    Schedule

    X

    Features

    X

  5. Describe the purpose of performing daily builds in the MSF Process Model.

    Daily builds allow the development team and the customer to understand the current state of the project and to measure the stability of the project on a frequent basis. Daily builds can be applied to both software development projects and hardware infrastructure projects.

  6. When you reach the release readiness milestone, what phase have you completed?

    The stabilizing phase is complete when the project team reaches the release readiness milestone and the solution has been validated by the project team and the customer.

  7. During which phase of the MSF Process Model is the initial risk assessment document created?

    During the envisioning phase, risk assessment begins and a risk assessment document is created. However, risk assessment is an ongoing process that occurs throughout the duration of the project. Therefore, the risk assessment document will continue to undergo changes and updates while the project progresses. In addition, as the project progresses, risk mitigation plans are created as a part of risk assessment.

  8. When are test cases established in the MSF Process Model?

    The majority of work on test cases is performed during the developing phase. However, the testing role is involved in the project from the very beginning.

  9. List several types of tests that are performed during the stabilizing phase.

    Following is a list of the types of tests that will be conducted during the stabilizing phase:

    • Component testing

    • Database testing

    • Infrastructure testing

    • Security testing

    • Integration testing

    • User acceptance and usability testing

    • Stress, capacity, and performance testing

    • Regression testing

    • Recording the number of bugs

  10. Why is it important to create a vision statement for the project during the envisioning phase?

    The vision statement communicates the direction for guiding the team toward its business goals. Everyone on the project team must agree to and support the vision of the solution. This agreement and support is fundamental to the success of the project. If members of the team do not agree with the vision statement, the success of the project is at risk.

  11. What are some of the key tasks that are performed during the planning phase?

    • Creation of the functional specification

    • Creation of the development, testing, and staging environments

    • Development of the project plans

    • Creation of the project schedule

    • Development of the solution design and architecture

  12. Describe the quiet period and the activities that occur during this period.

    The quiet period is the time between the deployment stable interim milestone and the deployment complete interim milestone of the deploying phase. During this period, the effectiveness and performance of the solution are measured. The results of this activity lead to an estimate of the effort needed to maintain the solution for continued operations.

Chapter 2 Gathering and Analyzing Information Review

  1. What is the difference between the interviewing and focus-group techniques of gathering information?

    An interview is a one-on-one meeting between a member of the project team and a user or stakeholder. The interviewer asks the user or stakeholder questions related to work and processes.

    A focus group is a form of group interview, in which a group of individuals discuss a process or an activity in the presence of a facilitator. The group of individuals represents all the relevant users and stakeholders of the process. You should use focus groups when many people must be interviewed in a short period. In addition, the various people in a focus group can help each other fill any information gaps.

  2. When should you use for prototyping instead of shadowing to gather information?

    Shadowing is the process of gathering information by observing a user performing day-to-day tasks in the actual work environment. You can ask the user questions related to the work. However, some activities cannot be understood by watching. You might need to document the actions that the user performed, such as keystrokes. In such a situation, you must use prototyping.

  3. How do you identify the most effective information gathering technique for a project?

    To identify the most effective information gathering technique, you consider the advantages and disadvantages of each technique. You identify the type of information to be collected and the amount of time you have to collect the information. If you want to gather information quickly, use interviewing or focus groups instead of surveys.

  4. What is the purpose of creating use cases?

    You create use cases to:

    • Identify the business process and all activities from start to finish.

    • Document the context and environmental issues.

    • Document relationship between business needs and user requirements.

    • Describe needs and requirements in the context of use.

    • Focus users and the development team.

  5. What is an actors catalog?

    The actors catalog contains a list of actors used in the use cases. It contains information such as actor name, actor responsibilities, and the sources from which the actor was identified.

  6. What is ORM?

    ORM is a modeling language that allows to you to present information as elementary facts. An elementary fact asserts that an object has a property and that one or more objects participate in a relationship. ORM expresses the model in terms of natural concepts, like objects and roles. ORM is based on the assumption that objects play roles in real life.

  7. What is UML?

    UML is a simple, extensible, and expressive visual modeling language. It is a set of notations and rules for modeling software systems of varying complexities. UML enables the creation of simple, well-documented, and easy to understand software models.

  8. What are the purposes of the various UML views?

    The five UML views are:

    • The user view, which represents the goals and objectives of the system from the viewpoint of various users and their requirements from the system.

    • The structural view, which represents the static or idle state of the system.

    • The behavioral view, which represents the dynamic state of the system.

    • The implementation view, which represents the distribution of the logical elements of the system.

    • The environment view, which represents the distribution of the physical elements of the system.

  9. What is an actor in a use case?

    An actor is an entity that interacts with the system to be built for the purpose of completing an event. An actor can be:

    • A user of the system.

    • An entity, such as another system or a database, that resides outside the system.

  10. What is the purpose of a usage scenario?

    A usage scenario describes in detail a particular instance of a use case. You need to create many usage scenarios to completely describe a use case.

  11. What are the steps in creating a usage scenario?

    To create a usage scenario, you perform the following steps:

    • Determine the preconditions for the usage scenario, specifying information that must exist before a scenario can be executed.

    • Identify the postconditions for the usage scenario, which describe what must be accomplished upon completion of the usage scenario.

    • Break the activity into discrete steps.

    • Identify exceptions that might occur for any step. You might need to develop usage scenarios for these exceptions.

    • Identify the requirement that this particular usage scenario addresses, for tracking and traceability.

Chapter 3 Envisioning the Solution Review

  1. What is the purpose of envisioning?

    The overall purpose of envisioning is to develop a common vision of the goals of the solution and share it with the customers. Specifically, some of the purposes served by envisioning are as follows:

    • Achieving an early understanding of the goals and constraints of the project among the customers and the team

    • Analyzing the feasibility of the solution and gaining approval from key stakeholders

    • Defining the scope of the project

    • Estimating the resources that are required to complete the project

    • Identifying the major milestones for the project

  2. What are the responsibilities of the various roles during the envisioning phase?

    Responsibilities of the various roles are as follows:

    • The product management role is responsible for ensuring that the customer requirements are addressed by the project team.

    • The program management role is responsible for developing the project design goals and solution concept.

    • The development role is responsible for providing the technical implications of the proposed solution and the feasibility of the solution concept.

    • The user experience role is responsible for analyzing the performance needs and support issues of the end users of the solution.

    • The testing role is responsible for defining the quality requirements of the solution and how the specified level of quality can be achieved.

    • The release management role is responsible for identifying all that is required for deploying the solution.

  3. What are the outputs of the envisioning phase?

    The key outputs of the envisioning phase are as follows:

    • The vision/scope document, which describes the goals and constraints of the project

    • The project structure document, which describes the organization of the team and the standards used by the team for documentation

    • The risk assessment document, which lists the risks associated with the project, their impact, and corresponding mitigation plans

  4. What is the purpose of specifying the project scope?

    You create the project scope to specify what the project will and will not accomplish. Therefore, you identify the features that the customer considers essential in the solution and focus on successfully including them in the solution. To accomplish this, you need to analyze all project variables and make the appropriate tradeoffs. Some of the benefits of defining the scope of the project are that scope enables the team to focus on the work that must be done. Defining the scope also helps the team to clearly identify all tasks in the project.

  5. How does the envisioning phase end?

    The envisioning phase ends at the vision/scope approved milestone. This milestone involves a meeting and follow-up conversations in which key stakeholders, customers, and representatives of each role in the team approve the vision/scope document to indicate that they have a formal agreement about the goals and objectives of the project and solution. They “sign off” on this document to indicate that all parties believe the team can proceed with the project.

  6. What kinds of change management decisions are recorded in the project structure document?

    In the change management section of the project structure document, you record the processes that the team will follow to handle changes in the project. Some of the decisions that are made include:

    • How will you define change on the project?

    • What is the release date? Who will determine the release date, and how will it be determined? What will the basis be for determining the release date?

    • Who will define the change management process that will be used?

    • How will proposed changes be identified and tracked? Who will track this information?

    • How will you assess the impact of a change? How much deviation are you willing to accept before major rescheduling?

  7. What is the difference between business goals and design goals?

    Business goals use business language to describe what the customer wants to change in the business by using the solution. Design goals represent the attributes of the solution that the project team is going to develop. The project team uses the design goals to illustrate what they want to accomplish with the solution.

  8. What are the guidelines for creating user profiles?

    While creating user profiles, remember the following:

    • Identify the goals and expectations of the users of the solution.

    • Identify the factors that might affect the ability of the user to use the solution.

    • To help provide required support, identify problems that users might have had with similar products or solutions and methods.

    • Determine whether the solution will be used globally.

    • Identify the number of users at each location where the solution will be implemented, the infrastructure at each location, and the network bandwidth available at each location.

    • Identify how the information flows between users of the solution. Identify the volume and importance of the communication.

    • Analyze the hierarchical structure of the organization and its implications on information flow between different levels of the hierarchy.

    • Analyze the scope of user functions.

    • Analyze policies that might affect the implementation of the solution.

  9. What are the essential components of a risk assessment document?

    A risk document must contain the following:

    • Risk statements, which capture the nature of the risk

    • Risk probability, which describes the likelihood of the occurrence of the risk

    • Risk severity, which specifies the impact of the risk

    • Risk exposure, which specifies the overall threat of the risk

    • Mitigation plans, which describe the efforts for preventing or minimizing the risk

    • Contingency plans and triggers, which specify the steps that you need to take when a risk occurs and when to take those steps

    • Risk ownership, which specifies the team member who is responsible for monitoring the risk

  10. What are the guidelines for assessing risks for a project?

    You must use a consistent scale to calculate the probability for every risk and its impact. If you express the impact of some risks by using a number and others by using financial terms, you cannot compare the exposure of the different risks. In addition, you need to rank the risks according to their exposure. Review this list frequently during the life of the project and update the list according to the importance of the risks.

Chapter 4 Creating the Conceptual Design Review

  1. What is the purpose of the planning phase?

    The purpose of the planning phase is to achieve a detailed and validated understanding of the problem to be solved and to define a solution that addresses the problem. This is the solution that is most likely to be successful given the assumptions and constraints as understood by the team.

  2. What is the difference between the responsibilities of the product management and project management roles during the planning phase?

    During the planning phase, product management represents the users and ensures that the product addresses their needs. Project management ensures that the solution is created to specifications defined by the product manager.

  3. What are the major deliverables of the planning phase?

    The major deliverables of the planning phase are:

    • The functional specification, which describes what will be built and how it will be built.

    • The master project plan document, which presents how the solution will be built by the various teams involved in the project.

    • The master project schedule, which specifies the time frame during which the project team will build and deploy the solution.

    • The updated master risk assessment document, which lists the risks associated with the project and their mitigation plans.

  4. How does a functional specification serve as a blueprint for the development team?

    The functional specification identifies what the solution is going to be. This enables the development team to formulate development strategies and estimate the time and effort required to develop the solution.

  5. What are the goals of a functional specification?

    The goals of a functional specification are:

    • Consolidating a common understanding of the business and user requirements.

    • Articulating a logical way to break down a problem and modularize the solution.

    • Providing a framework to plan, schedule, and develop the solution on time.

    • Serving as a contract between the team and the customer about what will be delivered.

  6. What are the risks of not creating a functional specification?

    Some of the risks of not creating a functional specification are:

    • The solution might not address the customer requirements.

    • The project manager might not correctly estimate the time and effort required to complete the project.

    • The team might be unable to define customer expectations clearly or share a common understanding of the solution with the customer.

    • The team might not have enough information to validate that the solution meets the customer requirements.

  7. What is the difference between the business and user requirements of the solution?

    The business requirements of the solution are specified by the customer. These requirements focus on meeting the business goals and objectives.

    The user requirements are provided by the end user of the solution and focus on using the solution to effectively perform day-to-day tasks.

  8. What are the benefits of creating a conceptual design?

    The conceptual design helps you:

    • Develop part of the functional specification.

    • Develop an effective user interface.

    • Determine how different components work together in a solution.

    • Design a solution that addresses both business and user needs.

  9. A company plans to increase its sales by 15 percent during the next financial year by implementing an online shopping site. The company intends to provide its users a Web site that is fast, provides secure credit card processing, and is available at all times. Also, only registered users will be able to purchase products on the site. What are the user, system, operation, and business requirements for this site?

    The requirements for this site are:

    • Business requirement: A Web site that improves the annual sales by 15 percent.

    • User requirement:

      • Users can complete their purchases in five minutes.

      • Users can access only their own credit card details.

    • System requirement: Only registered users will be able to purchase products on the site.

    • Operation requirement: The users must be able to access the site at all times.

  10. What are the goals of the analysis step of conceptual design?

    The goals of the analysis step are to

    • Review the user and business processes and activities.

    • Create scenarios to illustrate context, workflow, task sequence, and environmental relationships in the business.

  11. What is the benefit of synthesizing information?

    When you synthesize information, you present the information to the entire team and receive their perspectives about user requirements and solutions. You also ensure that all team members have a common understanding of user requirements and expectations.

  12. What are the tasks for creating the future state?

    To create future state usage, the team performs the following tasks:

    • Envision the desired future state.

    • Redesign the current process to optimally support key business activities and processes.

    • Create accurate target future state scenarios.

    • Validate future state scenarios by using iteration.

  13. What are the benefits of validating the conceptual design?

    Some of the benefits of validation include:

    • Reducing risk.

    • Highlighting missing information.

    • Indicating diverging views and interpretations of the solution, especially between the business and users.

    • Verifying the volume of activity.

    • Assisting in prioritization.

    • Providing a baseline for proceeding to logical design.

  14. What are the four service categories?

    The four service categories are:

    • User services that provide the user interface in an application

    • Business services that enforce business rules in the correct sequence

    • Data services that provide the lowest visible level of detail for manipulating data

    • System services that provide functionality outside the business logic

  15. Study and categorize the following services.

    • Displaying the employee details service

    • Updating the employee details service

    • Employee information service

    • E-mail service

    The categorized services are:

    • Displaying the employee details service: User service

    • Updating the employee details service: Business service

    • Employee information service: Data service

    • E-mail service: System service

  16. What are the characteristics of a refined business requirement?

    A business requirement must be:

    • Well defined.

    • Concise.

    • Testable.

    • Grouped in a hierarchical manner.

    • Written in business language without jargon.

  17. How do you refine use cases during the analysis step of conceptual design?

    To refine the use cases diagram, you perform the following tasks:

    • Create subordinate use cases.

    • Create usage scenarios for each subordinate use case.

    • Validate each use case and usage scenario against refined requirements.

  18. What are the criteria for evaluating the cost of a solution?

    The criteria are:

    • Resources, work effort, and time

    • Operational costs of technical options and emerging technologies

    • Annual and recurring life cycle costs

Chapter 5 Creating the Logical Design Activity

  1. The shopping cart checks inventory to determine the availability of a particular product.

    Objects include shopping cart, inventory, and product.

  2. A new user creates an account in order to place orders.

    Objects include user, account, and orders.

  3. A user adds a product to the shopping cart.

    Objects include user, product, and shopping cart.

  4. A user retrieves an order to check its status.

    Objects include user and order.

Chapter 5 Creating the Logical Design Review

  1. What are the two steps of logical design?

    • Analysis, during which you identify objects, services, attributes, and relationships

    • Optimization, during which you refine the object list, verify the design, and implement control

  2. What are the outputs of the logical design?

    • The logical object model, which is a set of objects with corresponding services, attributes, and relationships

    • A high-level user interface design

    • The logical data model

  3. Should you focus on technological issues during logical design?

    Though logical design is considered to be technology independent, it is a good practice to consider physical constraints and opportunities during logical design to validate that the design can be implemented. Experienced teams and designers typically use the optimization step of logical design to identify the technology constraints to create a pseudophysical design. Logical design is the basis for evaluating the feasibility of the physical design and deciding implementation alternatives.

  4. What are the benefits of logical design?

    • Logical design reduces the complexity of the solution.

    • Logical design reflects and supports the requirements of conceptual design.

    • Logical design provides a view of the solution as a single unit.

    • Logical design acts as a point of contact for organizing cross-functional cooperation among multiple systems.

    • Logical design acts as a starting point for the physical design.

  5. How do you identify services in a usage scenario?

    To identify services, examine a usage scenario to determine what the object is supposed to do, the kind of data the object must maintain, and the actions that the object must perform. If an object maintains information, it also performs the operations on the information.

  6. How do you identify attributes in a usage scenario?

    In a usage scenario, look for the words or phrases that further identify the object.

  7. What is a sequence diagram?

    A sequence diagram shows the actors and objects that participate in an interaction and the events they generate, arranged chronologically. It also identifies object dependencies in the system.

  8. How do you design the tables and columns in a data store for a solution?

    Each object that maintains data corresponds to a table in the data store. The attributes of the object form the columns in the table. Each row in the table stores values for various fields for a specific instance of the object.

  9. What is the purpose of refining the list of objects?

    You need to refine the list of objects because:

    • Two objects might express the same information or control the same activity.

    • Nouns in usage scenarios might be key attributes of another object.

    • You might need a new object to control or coordinate a set of services.

  10. How do you verify the design by using individual object verification?

    In individual object verification, you identify an object’s inputs and outputs and the capability or functionality that the object must provide. For any given input, you should be able to accurately predict the output and behavior and verify the independent parts of the object.

  11. What is the purpose of control in logical design?

    Control enables you to sequence objects. Control in logical design:

    • Ensures transactional integrity of a scenario.

    • Coordinates services across multiple objects.

    • Identifies cross-object interdependencies.

  12. You are creating the logical design of a solution for a customer, and you discover a scenario that was not discovered in your previous analysis. What should you do with this new information?

    First, you should review all your current documentation to verify that the new information is not covered in your analysis. If the new information does not exist in your analysis, determine the effect of including functionality based on this new information in this version of the solution. Also determine the effect of omitting functionality based on the new information from this version. Once you have this information, you should notify the customer of the situation and work together to determine the best way to manage the new information. Be aware that the scope of the project might change depending on what you do with the new information.

  13. What is the responsibility of the testing role during logical design?

    The testing role is primarily responsible for validating the logical design by measuring it against the conceptual design to validate that the logical design will cover the requirements. In addition, the testing role begins to define a high-level test plan.

Chapter 6 Creating the Physical Design Review

  1. What are the goals of physical design?

    The goals of physical design are:

    • Transforming the logical design to specifications for a set of components

    • Providing a baseline for implementing the design

    • Identifying appropriate technologies for development

    • Creating a structural view of the solution from the perspective of the development team

  2. What is the difference between conceptual, logical, and physical designs?

    During conceptual design, the project team describes the solution from the perspective of the business and user communities. During logical design, the project team describes the solution from its own perspective. During physical design, the project team describes the solution from the perspective of the development team.

  3. What does the development team do during physical design?

    During physical design, the development team evaluates technologies, creates prototypes, and prepares for development.

  4. What does the deployment model include?

    The deployment model consists of:

    • The network topology, which indicates hardware locations and interconnections.

    • The data topology, which indicates data store locations in relation to the network topology.

    • The component topology, which indicates the locations of components and their services in relation to the network topology.

  5. What does the project team do during the research step of physical design?

    During the research step, the team considers constraints such as enterprise architecture, business process, and infrastructure. In addition, the team identifies the requirements of the solution in terms of performance, availability, and scalability. The team then analyzes the differences between the requirements and constraints.

  6. How does the project team handle the gap between requirements and constraints?

    To handle the gap between requirements and constraints, the project team:

    • Identifies the areas in the infrastructure where the requirements might conflict with the constraints.

    • Analyzes the gaps between the requirements and the constraints and determines whether they need to make choices to resolve conflicts.

    • Identifies the requirements that are absolutely necessary for the project.

    • Brainstorms solutions with all groups associated with the project.

  7. During the analysis step of physical design, how does the project team use the list of objects and services created during logical design?

    The project team uses the list by:

    • Categorizing services as user services, business services, data services, and system services

    • Identifying hidden services

  8. How does the project team refine the class diagrams during the analysis step of physical design?

    The project team refines the class diagrams by:

    • Identifying objects that were not apparent during logical design

    • Consolidating logical objects

    • Categorizing objects into a services-based model

    • Refining the methods by focusing on parameters

    • Refining the attributes

  9. How do you select the candidate technologies for the solution?

    In evaluating and selecting candidate technologies for the solution, you address business considerations, enterprise architecture considerations, and technology considerations.

  10. What is the difference between the network topology and the data topology of the deployment model?

    The network topology is an infrastructure map that indicates hardware locations and interconnections. The data topology is a map that indicates data store locations in relation to the network topology.

  11. What is the difference between the distribution strategy and the packaging strategy?

    The distribution strategy is a rationale for determining where the services will be located in the solution architecture. Distribution is services-based and not component-based.

    The packaging strategy is a rationale for determining which services will reside in each component. You might have multiple strategies in a single solution.

  12. What is the difference between cohesion and coupling?

    Cohesion is the relationship among various internal elements of a component. Coupling is the relationship of a component with other components. A component should be tightly cohesive but loosely coupled.

  13. What is the purpose of a programming model?

    The programming model:

    • Describes how the development team can use the selected technologies.

    • Specifies standards that will be followed during the implementation of the project.

    • Sets specific guidelines to provide consistent component implementation.

  14. Page 251

    A component interface:

    • Is a contract that represents the supplier and consumer relationship between components

    • Is a means to access the underlying services

    • Represents one or more services

    • Includes underlying object attributes

  15. What are the various types of users of the user services layer of an application?

    There are two types of users of the user services layer of an application: human users who require an interface through which they can interact with the system, and other computer systems. A user interface provides visual means for humans to interact with systems. User services provide the navigation, validation, and error-processing logic.

Chapter 7 Designing the Presentation Layer Review

  1. What is the function of the presentation layer in the business application architecture?

    The presentation layer is the part of the business application that provides a communication mechanism between the user and the business service layer of the application. The presentation layer contains the components that are required to enable user interaction with the application. The most simple presentation layers contain user interface components, such as Windows Forms or ASP.NET Web Forms. For more complex user interactions, you can design user process components.

  2. What are the features of a good user interface?

    Some of the features of a good user interface design include:

    • Intuitive design

    • Optimum screen space utilization

    • Ease of navigation

    • Controlled navigation

    • Input validation

    • Menus, toolbars, and Help

    • Efficient event handling

  3. What are the differences between a high-fidelity and low-fidelity design?

    • Low-fidelity designs show main features, structure, and navigation; high-fidelity designs show the detailed screen layouts and interface elements.

    • Low-fidelity designs allow you to quickly and easily explore alternative designs; high-fidelity designs, although quick to implement and change, require a computer and software.

    • Low-fidelity designs are great for brainstorming and quick feedback; high-fidelity designs are typically developed from a low-fidelity design.

  4. What are some of the options that application developers can use to design user assistance for an application?

    Some of the options for designing user assistance in applications include:

    • Online Help

    • ToolTips

    • Wizards

    • Status displays

    • Accessibility aids

  5. What are the various types of user interface models, and when should you use them?

    • Windows desktop user interfaces are used when you need to provide disconnected or offline capabilities or rich user interaction, and maybe even integration with the user interfaces of other applications.

    • Web-based user interfaces allow for standards-based user interfaces across many devices and platforms. Therefore, you should use Web-based user interfaces when an application must be used on a wide variety of client devices.

    • Mobile device user interfaces need to be able to display information on a much smaller screen than other common applications and must offer acceptable usability for the devices being targeted.

    • Document-based user interfaces are used in some applications so that users can enter or view data in document form in the productivity tools they commonly use.

  6. Describe the difference between a user interface component and a user process component. Describe a situation in which you would use a user process component.

    A user interface component makes up the interface to the application that the user will be interacting with. A user process component encapsulates a specific process that a user might perform while interacting with the application. An example of a user process component is the user logon process. A user might be able to log on by means of a Web browser or a Windows-based application. The interfaces will be different, but the process of logging on can be the same. Abstracting the process of logging on away from the interface promotes reuse and consistency within the application.

  7. How do you separate user interface from user process?

    To separate user interface from user process, perform the following steps:

    1. Identify the business process or processes that the user interface process will help to accomplish. Identify how the user sees this as a task. (You can usually do this by consulting the sequence diagrams that you created as part of your requirements analysis.)

    2. Identify the data needed by the business processes. The user process will need to be able to submit this data when necessary.

    3. Identify additional state you will need to maintain throughout the user activity to assist rendering and data capture in the user interface.

    4. Design the visual flow of the user process and the way that each user interface element receives or gives control flow.

  8. Your design calls for the use of Windows Terminal Services. What kind of user interface will you create to implement this design?

    The remote computer will contain a Windows Forms user interface. The local computers will simply use Remote Desktop as a thin client to access the remote computer.

  9. During the envisioning and planning phases, you determined that the users of the solution will be using a wide variety of hardware, will be located at various remote locations, and will not all have access to the company’s intranet. What type of client lends itself to these constraints?

    A Web-based client would be most appropriate. Because the users will not have a consistent hardware configuration, and because some might not have access to the company intranet, a secure Web-based solution would be appropriate.

  10. After your design of the user interface is complete, what are some of the ways you can validate the design before implementing it?

    The design of the UI will be derived from interviews with the users, the requirements that the customer has identified and approved, and the various use cases, usage scenarios, and activity diagrams that you created during the conceptual and logical design processes. After the user interface design is complete, you compare it to each of the sources to ensure that the user interface meets all the requirements.

Chapter 8 Designing the Data Layer Review

  1. How is the data model designed during the planning phase?

    During the conceptual design process, the team researches and analyzes data requirements. These requirements help determine what actually must be stored and processed by the business solution. During logical design, the project team derives a set of data entities that are derived from the data requirements. At this stage, the team defines the relationships between various entities and creates a database schema.

  2. What is the purpose of the database schema?

    A database schema specifies how data is organized in a database. In the logical design process, the members of the project team create a database schema so that they can focus on what must be built before they focus on how to build it.

  3. What are the characteristics of attributes?

    The characteristics are:

    • Attributes describe an entity.

    • Attributes must be attached to the entity that they most closely describe.

    • Attributes define the columns in database tables.

  4. What is the purpose of specifying data types in a database?

    Specifying data types in a database fulfills the following purpose:

    • Data types specify how data will be stored in a database.

    • Data types specify how data will be formatted.

    • Data types help enforce data validation.

    • Appropriate data type choices optimize data storage.

  5. How do most DBMSs support a many-to-many relationship?

    Most DBMSs support a many-to-many relationship by using a join table to hold information that maintains the relationship between the entities.

  6. How do you optimize transactions for good system performance?

    The transaction should be short-lived, incorporate only what is required, and should not be distributed.

  7. What is the impact of indexing on data access?

    Queries performed on indexed data are much faster and more efficient than queries performed on data that is not indexed. Rather than scanning an entire table each time a value is needed, the DBMS can use the index to quickly lead the query directly to the location of the required data because the index records the location of the data in the table.

  8. What is the difference between horizontal and vertical partitioning?

    In horizontal partitioning, you segment a table containing a large number of rows into multiple tables containing the same columns. In vertical partitioning, you segment a table containing a large number of columns into multiple tables containing rows with equivalent unique identifiers.

  9. What are the benefits of normalization?

    • Minimized duplication of information

    • Reduced data inconsistencies

    • Reduction of empty fields (improved storage)

  10. What is denormalization?

    Denormalization is the process of reversing normalization to generate tables with more fields that require fewer joins.

  11. What are the three types of data integrity that can be enforced in a database?

    The following three types of data integrity can be enforced in a database:

    • Domain integrity specifies a set of legitimate data values for a column and determines whether null values are to be allowed.

    • Entity integrity requires that each row in a table has a unique identifier, known as the primary key value.

    • Referential integrity ensures that the relationships between the primary keys (in the parent entity’s table) and foreign keys (in the child entity’s table) are always maintained.

  12. How do you identify data integrity requirements?

    To identify data integrity requirements:

    • Examine data requirements for uniqueness or limits and constraints that might be specified to ensure that entities can exist and be implemented correctly.

    • If limits and constraints have been specified, determine whether the limits and constraints are bound to an entity or to a relationship between entities.

    • Implement referential integrity requirements to ensure that all relationships are maintained.

  13. What are the criteria for identifying business rules?

    The criteria for identifying business rules are:

    • Identify conditions that must be satisfied for data to be considered valid.

    • Identify conditions that must be avoided.

    • Identify sequences in which events must occur.

  14. How do keys implement referential integrity?

    Primary and foreign key relationships from the physical model directly correspond to the database engine’s key settings. These key settings automatically enforce referential integrity between linked tables.

  15. What are the benefits of using components to implement business rules?

    The benefits are:

    • Easier maintenance because the code is stored in only one or a few locations and can be easily updated

    • Scalability because additional application servers can be added to distribute the increased processing load

Chapter 9 Designing Security Specifications Review

  1. What are some of the drawbacks of traditional security models?

    Some of the drawbacks of traditional security models include:

    • They are based on user identity and not on code identity.

    • They are highly prone to virus and worm attacks.

  2. What are some of the principles of secure coding?

    The following are some of the principles of secure coding:

    • Rely on tested and proven security systems.

    • Never trust external input.

    • Assume that external systems are insecure.

    • Apply the principle of least privilege.

    • Reduce available components and data.

    • Default to a secure mode.

    • Do not rely on security by obscurity.

    • Follow STRIDE principles.

  3. Which of the following statements about buffer overruns is true? (Select all that apply.)

    • Type safety verification was designed to eliminate buffer overruns.

    • A buffer overrun can cause an application to stop responding or to malfunction.

    • A buffer overrun can be exploited by a malicious user to run arbitrary code.

    • The error message that results from a buffer overrun can pose a security threat.

    All of these statements are true.

  4. During which MSF phase should the threat model be created?

    • Planning

    • Developing

    • Stabilizing

    The threat model is created during the planning phase.

  5. What is the STRIDE model?

    The STRIDE model is a threat model that allows application designers to predict and evaluate potential threats to an application. Each letter in the STRIDE acronym specifies a different category of security threat: spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

  6. Read the following security attack scenario, and then decide which elements of the STRIDE model are implicit in the attack.

    Carl sees that Bob has left his workstation unattended and unlocked. Carl sits down at Bob’s workstation and opens Bob’s e-mail application. Carl, pretending to be Bob, sends an e-mail message to Alice. Carl quits the e-mail client and then walks away unobserved.

    Four types of attacks—spoofing identity, tampering, repudiation, and elevation of privilege—are possible in the above scenario.

  7. What is code-access security?

    The .NET Framework provides code-access security to help protect computer systems from malicious code and to provide a way to allow mobile code to run safely. Code-access security allows code to be trusted to varying degrees, depending on the code’s origin and on other aspects of the code’s identity.

  8. What is role-based security?

    Role-based security applies mostly to the spoofing identity security threat by preventing unauthorized users from performing operations that they are not authorized to perform. Role-based security allows code to check the identity and role membership of the user. The .NET Framework includes classes to check Windows users and groups, in addition to classes to help implement role-based security for other authentication schemes.

  9. Which are the authentication providers supported by ASP.NET?

    ASP.NET supports three authentication providers: forms, Microsoft Passport, and Windows.

  10. What are the three types of security provided by Web services?

    The three types of security are:

    • Platform/transport-level (point-to-point) security

    • Application-level (custom) security

    • Message-level (end-to-end) security

  11. What are the steps for designing an authorization and authentication strategy for an application?

    To design an authorization and authentication strategy for an application, you perform the following steps:

    1. Identify resources.

    2. Select an authorization strategy.

    3. Select the identities used for resource access.

    4. Consider identity flow.

    5. Select an authentication approach.

    6. Decide how to flow identity.

Chapter 10 Completing the Planning Phase Activity, Exercise 1

  1. Review the test plan and then list three ways that use cases and usage scenarios are used in the testing process for AdventureWorks Cycles.

    Adventure Works Cycles uses use cases and usage scenarios in the following ways:

    • Use cases and usage scenarios define the actions to be tested for user functionality.

    • Use cases and usage scenarios define the actions to be tested for adminstrative functionality.

    • Use cases and usage scenarios will be used to write the specific test script scenarios.

  2. How will bugs be approved and documented for action for the solution?

    Change requests will be issued for bugs meeting the change criteria.

  3. Which user accounts must be configured on the test environment servers?

    • Network Administrator

    • Sales Representative 1

    • Sales Representative 2

    • Sales Manager

    • Web Customer 1

    • Web Customer 2

    • Reseller

    • Production Clerk

  4. Why is the following threat important to list under threats to testing?

    Availability of sales staff for testing. The test team should be overseen by at least one sales representative. Mitigation: Gain prior agreement from the vice president of sales for two sales representatives to be assigned to test the application.

    Because the bulk of the functionality is defined by usage scenarios with a sales representative as at least one of the actors, this requirement will greatly increase the validity of the testing. It will also ensure approval from the sales staff (provided the two selected representatives feel that their input is responded to by means of change requests). It can also provide the benefit of creating two representatives that are able to be very productive in the training and implementation of the application.

Chapter 10 Completing the Planning Phase Activity, Exercise 2

  1. What are the parameters for the addOrderDetail method?

    The parameters are: ProductID and Quantity.

  2. Will two types of client interfaces be available in the application?

    Yes, Windows Forms and Web Forms.

  3. Why is the Interfaces section still to be determined?

    The interfaces cannot be documented until they are developed and validated. Although pseudocode could be written, it should not be left permanently in the technical specification, but replaced with the code when it is developed.

Chapter 10 Completing the Planning Phase Review

  1. How do you scale up an application?

    You scale up an application by adding more memory, more or faster processors, or by migrating the application to a single more powerful machine.

  2. What do you need to take into consideration while designing for scalability?

    • Design processes so that they do not wait.

    • Design processes so that they do not fight for resources.

    • Design processes for commutability.

    • Design components for interchangeability.

    • Partition resources and activities.

  3. What do you need to take into consideration while designing for availability?

    Designing for availability includes anticipating, detecting, and resolving hardware or software failures before they result in service errors, event faults, or data corruption, thereby minimizing downtime.

  4. How does clustering enhance the availability of an application?

    Clustering allows two or more independent servers to behave as a single system. In the event of a failure of a component such as a CPU, motherboard, storage adapter, network card, or application component, the workload is moved to another server, current client processes are switched over, and the failed application service is automatically restarted, with no apparent downtime. When a hardware or software resource fails, customers connected to that server cluster might experience a slight delay, but the service will be completed.

  5. How do you reduce planned downtime of an application?

    One of the best ways to avoid planned downtime is by using rolling upgrades. For example, assume that you need to update a component on a clustered server. You can move the server’s resource groups to another server, take the server offline for maintenance, perform the upgrade, and then bring the server online. During the maintenance, the other servers handle the workload and the application experiences no downtime.

  6. Why is reliability an important design consideration for an application?

    • Unreliable systems are very costly. Users bypass unreliable Web sites, resulting in lost revenue and reduced future sales.

    • The expense of repairing corrupted data increases the loss due to application failure.

    • Unreliable systems are difficult to maintain or improve because the failure points are typically hidden throughout the system.

  7. How do you design for reliability of an application?

    To design for reliability of an application, you need to perform the following tasks:

    • Document reliability requirements in the specification.

    • Use a good architectural infrastructure.

    • Include management information in the application.

    • Use redundancy.

    • Use quality development tools.

    • Use reliability checks that are provided by the application.

    • Use consistent error handling.

    • Reduce the application’s functionality instead of completely failing the application.

  8. How do you define a performance requirement?

    To define a good performance requirement, you must identify project constraints, determine services that the application will perform, and specify the load on the application.

  9. Why do you need to design for interoperability?

    • Reduces operational cost and complexity

    • Enables optimal deployments

    • Uses existing investments

  10. How do you prepare an application for globalization?

    • Identify the cultures and locales that must be supported.

    • Design features that support those cultures and locales.

    • Write code that functions equally well in all the supported cultures and locales.

  11. What is the purpose of a monitoring plan?

    A monitoring plan describes what will be monitored, how the application will be monitored, and how the results of monitoring will be reported and used. Customers use automated procedures to monitor many aspects of a solution.

  12. What is the purpose of the migration strategies section of the migration plan?

    The migration strategies section describes the strategy or strategies that will guide the migration process. These strategies do not need to be mutually exclusive but can describe different parts of the overall migration. Strategy could be organized around releases (related to the business or to development or technology maturity) or organized around solution components. These strategies also need to take into account the migration of earlier systems into the new solution environment. You might have multiple migration strategy sections if you need to migrate both business objects and data.

  13. Why do you need to provide licensing specifications for both the development and the deployment phase?

    • During the developing phase, the team will work with selected technologies and software products. You must ensure that there are sufficient licenses for the required products.

    • For the developing phase, you need to specify the number of licenses needed for any software that might be used. The number of licenses needed depends on the type of solution and the number of users who will use the solution.

  14. What is the purpose of the development plan?

    The development plan describes the solution development process used for the project. This plan provides consistent guidelines and processes to the teams creating the solution. Having the development process documented indicates that the team has discussed and agreed on a consistent structure and direction to be used during the development process. It also facilitates reuse among different groups and minimizes the dependency upon one individual or group.

  15. What is the purpose of the test plan?

    The test plan describes the strategy and approach used to plan, organize, and manage the project’s testing activities. It identifies testing objectives, methodologies and tools, expected results, responsibilities, and resource requirements. This document is the primary plan for the testing team. A test plan ensures that the testing process will be conducted in a thorough and organized manner and will enable the team to determine the stability of the solution.

  16. Who creates the deployment plan?

    The release management role of the MSF Team Model is responsible for designing and implementing the solution’s deployment plan. Release management is also responsible for specifying the solution infrastructure and ensuring that the solution continues to run as expected after it has been deployed.

  17. What is a technical specification?

    The technical specification is a set of reference documents that usually includes the artifacts of physical design, such as class specifications, component models, metrics, and network and component topologies. During the developing phase, the technical specification becomes the method for documenting the actual implementation of the developed solution.

Chapter 11 Stabilizing and Deploying the Solution Review

  1. What are some of the specific goals of the stabilizing phase?

    The goals of the stabilizing phase include

    • Improve solution quality

    • Address outstanding issues to prepare for release

    • Make the transition from building features to focusing on quality

    • Stabilize the solution

    • Prepare for release

  2. How does ongoing analysis of bug convergence provide warning signs about the stability of the project?

    If the numbers of reported and fixed bugs are not converging over time, the team is reporting as many new bugs as it is fixing. Solution stability is no closer than it was on the first day of the project. The team must treat this lack of convergence as a serious issue and resolve it quickly.

  3. Why is zero-bug bounce a positive indicator for the project?

    Zero-bug bounce indicates that development has caught up with the backlog of active bugs needing resolution. It indicates that the quality of the build is improving.

  4. What is a release candidate, and what are some of its features?

    After the first achievement of zero-bug bounce, a series of release candidates are prepared for release to the pilot group. Each of these releases is marked as an interim milestone. The purpose of the release candidate is to make the product available to a preselected group of users to test it. The users provide feedback to the project team, and the project team in turn continues to improve the product and resolve bugs that appear during the pilot.

  5. What is a pilot, and what are its goals?

    A pilot is a test of the solution under live conditions, such as a subset of production servers, a subset of users in a users group, or a trial period for the entire production environment (with the ability to roll back). The goal of a pilot is to take the next step in the ongoing stabilization process and reduce the risks associated with deployment.

  6. Why should pilot testing not be too easy?

    A pilot should test every case and situation that will arise in production, including operations tasks. A pilot that is too easy will not reveal enough information to select the strategy for moving forward. Intentional crashes of the pilot should be included to test rollback procedures, disaster recovery, and business continuity planning. The results of a rigorous pilot that is completed by proactive users will tell the team whether it should stagger forward, roll back, suspend the pilot, patch and continue, or proceed to the deployment phase (the ultimate goal of the pilot).

  7. What are the deliverables of the deploying phase?

    The deliverables of the deploying phase are: operations and support information systems, including procedures and processes, knowledge base, reports, and logbooks; a repository of all versions of documents, load sets, configurations, scripts, and code; and a project closeout report, including project documents and customer surveys.

  8. Which person or group is the best candidate to deploy the solution?

    This varies with the organization and the project. Sometimes the project team is the best candidate, and sometimes a specific deployment feature team should assume the responsibility. In some cases, an outside group should handle deployment. Ultimately, it is most important to develop a solid deployment plan and provide it to the person or group that is able to deliver a solid deployment.

  9. What are some examples of core components? What are some examples of site components?

    Core components are such things as domain controllers, mail routers, remote access servers, and database servers. Site components include such things as local routers and file print servers.

  10. What is the quiet period, and what are some of its features?

    The quiet period begins when deployments are complete. Deployments are complete and the team begins transferring responsibilities to operations and support. The quiet period generally lasts from 15 to 30 days.

  11. What type of documents result from completing closeout activities?

    Closeout activities usually produce a customer satisfaction survey, a closeout report (including formal project closure, final deliverable versions, a customer survey result compilation, and a summary of next steps), a project review document, and a customer sign-off document.

  12. Which MSF role handles the final sign-off from the customer?

    Product management typically obtains final sign-off from the customer for release of the solution. This signals the customer’s approval of the solution and permission to disengage from the project.

  13. What are the two types of project reviews that MSF advocates at the end of the deployment phase?

    Two types of project reviews are team reviews and customer reviews. In a team review, the core team assesses what it did well and what could have been improved. In a customer review, the team discusses with sponsors and stakeholders the project’s outstanding issues, the level of quality and customer satisfaction, and the next steps following the project.


A

accessibility aids Specialized programs and devices that help people with disabilities use applications more effectively.

activity diagram A UML diagram used to represent the state transition and flow of an application.

actor An entity in a use case that interacts with the system to be developed for the purpose of completing an event.

actors catalog An artifact that contains information about all the actors that will be used in use cases. See also artifact.

aggregation A special type of association that represents the relationship between a whole and its parts.

alpha code All code produced during the developing phase of the MSF Process Model. See also beta code.

analyzing risk The process of converting risk data into information that can be used to make risk decisions.

application architecture A set of definitions, rules, and relationships that form the structure of an application.

applications interoperability The infrastructure required to ensure interoperability between new n-tier applications and existing applications, business logic, and data.

architecture A design and plan for building something. Also the style of that plan or design. See also application architecture.

artifact An item that is physically available in the business environment and that describes an element or core business process.

association A structural relationship that describes a connection among objects.

asynchronous communication services Services that provide a message-based form of execution in which the requesting application is not dependent on a response within any given period of time.

asynchronous control The situation in which a client can submit a request and then continue performing other tasks.

attributes The names of data values that an object holds. Also known as properties.

authentication The process of positively identifying the clients of your application. Clients might include end users, services, processes, or computers.

authorization The process of defining what authenticated clients are allowed to see and do within the application.

availability A measure of how often an application is available to handle service requests as compared to the planned run time.


B

behavioral view A UML view that represents the dynamic or changing state of a system.

beta code All code tested during the stabilizing phase of the MSF Process Model. See also alpha code

buddy testing A type of testing that involves developers who are not working directly on the creation of a particular code segment, employing them to perform coverage testing on their colleague’s code.

buffer overrun A type of error that occurs when more data is written to a buffer than the buffer was programmed to contain.

bug Any issue arising from the use of the product.

bug convergence The point at which the team makes visible progress towards minimizing the active bug count.

build verification testing A type of testing used to identify errors during the build process. It can be thought of as the identification of compilation errors, as opposed to run-time errors, of all solution components.

business goals Goals representing what the customer wants to achieve with the solution. Business goals form the basis for determining the success criteria of the solution.

business requirements Requirements defining what the solution must deliver to capitalize on a business opportunity or to meet business challenges.

business rules catalog An artifact in internal team documentation that lists the business rules for a solution. This is a living document.

business services Units of application logic that enforce business rules in the correct sequence.


C

cache architecture A version of the client/server architecture in which the application provides a means for processing some client requests without forwarding the requests to another device.

check-in testing A type of testing performed by developers or testers before the code is checked into the change control system. This testing is performed to ensure that tested code is behaving correctly.

class diagram A UML diagram that depicts various classes and their associations.

Class-Responsibility-Collaboration (CRC card) A modeling tool that indicates all the classes with which a class must interact and identifies the relationships between classes.

client/server architecture A two-tier architecture that is based on a request-and-provide strategy. The client initiates a session with the server and controls the session, enlisting the server on demand.

clustered index A type of index that physically reorders the rows of data in a table to match the order of the index.

clustering A technology for creating high-availability applications. A cluster consists of multiple computers that are physically networked and logically connected by cluster software.

code signing The process of providing a set of code with credentials that authenticate the publisher of the code.

code-access security A technique that allows code to be trusted to varying degrees, depending on the code’s origin and on other aspects of the code’s identity.

cohesion The relationship among different internal elements of a component.

collaboration diagram A UML diagram that represents a set of classes and the messages sent and received by those classes.

commutative processes Two or more operations that can execute in any order and still obtain the same result.

compatibility testing A type of testing that focuses on the integration or interoperability of the solution under development with existing systems.

component and data topology A map that indicates the locations of packages, components, and their services in relation to the network topology. It also indicates data store locations.

component diagram A UML diagram that represents the implementation view of a system. This diagram is used to represent the dependencies between components or component packages.

conceptual design The first design process of the planning phase, during which the project team views the problem from the perspective of the users and business requirements and defines the problem and solution in terms of usage scenarios.

conceptual schema design procedure (CSDP) A methodology in ORM that focuses on the analysis and design of data. The conceptual schema specifies the information structure of the application, including the types of facts that are of interest, any constraints on these facts, and the rules for deriving some facts from others.

configuration testing A type of testing used to conduct solution tests in each of the possible solution configurations.

constraints Parameters to which the final business solution must adhere. They are aspects of the business environment that cannot or will not be changed.

coupling The relationship of a component with other components.

coverage testing Low-level technical testing.

CRC card See Class-Responsibility-Collaboration.

CSDP See conceptual schema design procedure.

customer One or more individuals who expect to gain business value from a solution.


D

data integrity The consistency and accuracy of data.

data interoperability The ability for applications to access and use data stored in both structured and unstructured storage systems such as databases, file systems, and e-mail stores.

data services Units of application logic that provide the lowest visible level of detail for manipulating data.

data type A definition used to specify the kind of data that is stored in a field.

database A collection of data values that are organized in a specific manner.

database schema A description that specifies how data is organized in a database.

delegation An extended form of impersonation that allows a server process that is performing work on behalf of a client to access resources on a remote computer. See also impersonation.

denial of service (DoS) Any attack that attempts to shut down or prevent access to a computing resource.

denormalization The process of reversing normalization to generate tables with more fields that require fewer joins.

dependency A relationship between two objects in which a change to one object (independent) can affect the behavior or service of the other object (dependent).

deploying phase The final phase of the MSF Process Model. During this phase, the team deploys the solution technology and site components, stabilizes the deployment, transfers the project to operations and support, and obtains final customer approval of the project.

deployment diagram A UML diagram that represents the mapping of software components to the nodes of the physical implementation of a system.

deployment model A model that represents the mapping of the application and its services to the actual server topology.

deployment view See environment view.

design goals A type of project goal. These goals focus on the attributes of the solution.

design view See structural view.

developing phase The third phase of the MSF Process Model. During this phase, the project team creates the solution, creates the code to implement the solution, documents the code, and develops the infrastructure for the solution. The developing phase culminates in the scope complete milestone.

development An MSF Team Model role that is responsible for developing the solution according to the specifications provided by the program management role.

distribution strategy A rationale for determining where services will be located in the solution architecture.

documentation and Help file tests A type of testing that focuses on testing all developed support documents or systems. The documents and Help files are compared with the solution to discover any discrepancies.

domain integrity A type of data integrity used to specify a set of valid data values for a column and determine whether null values are to be allowed.

DoS See denial of service.


E

elementary fact Refers to the fact that an object has a property, or that one or more objects participate in a relationship.

elevation of privilege An attack in which a malicious user gains access to greater privileges than the administrator intended, creating the opportunity for the user to launch attacks of every other category of security threat.

encryption The process of disguising data before it is sent or stored.

end user One or more individuals or systems that interact directly with a solution.

entity integrity A type of data integrity that requires each row in a table to have a unique identifier, known as the primary key value. See primary keys.

environment view A UML view that represents the distribution of the physical elements of a system. Also known as the deployment view.

envisioning phase The first phase of the MSF Process Model, during which the project team is assembled and comes to agreement with the customer on the project vision and scope. The envisioning phase culminates in the vision-approved milestone.


F

fact instance An individual observation about the relationship between two or more data values.

fact type The set of fact instances that share the same object types and predicate relationships.

flat-file database A type of data store in which all data in a single file is stored as a set of rows and columns.

focus group An information-gathering technique in which individuals discuss a topic and provide feedback to a facilitator.

foreign keys Keys used to link two tables.

forms authentication A system by which unauthenticated requests are redirected to a Hypertext Markup Language (HTML) form by means of Hypertext Transfer Protocol (HTTP) client-side redirection.

functional specification A virtual repository of project and design-related artifacts that are created during the planning phase of the MSF Process Model.

functional tests Tests that are specified by the users of the solution and created by the testing team.


G

generalization A relationship between a general thing (called the parent) and a specialized or specific thing (called the child).

globalization The process of designing and developing an application that can operate in multiple cultures and locales.

glossary One of the artifacts in internal team documentation that contains a list of terms used in artifacts and their meanings.

granularity A measure of the number of services and objects packaged in a single component.


H

hashing The process of matching data of any length to a fixed-length byte sequence.

hierarchical database A database that stores a wide range of information in a variety of formats.

high-fidelity design A design that provides detailed information about screen layout and interface elements.

horizontal partitioning A method of partitioning tables in which a table containing many rows is divided into multiple tables containing the same columns.


I

identity A characteristic of a user or service that can uniquely identify the user or service.

impersonation A technique used by a server application to access resources on behalf of a client application.

implementation view A UML view that represents the structure of the logical elements of a system.

index An ordered list of rows in a table that a database management system (DBMS) can use to accelerate lookup operations.

information disclosure A security error in which an unauthorized user views private data, such as a file that contains a credit card number and expiration date.

instance An item of interest in the universe of discourse.

interchangeable component A component that is designed to release its resources, move into a pool managed by a resource manager, and be re-initialized for use by a new client application .

interface A means for requesting that a service perform an operation and a means for receiving information about the resulting attributes.

interim milestone A point in time that signals a transition within a phase and helps to divide large projects into manageable pieces. See also milestone.

interviewing An information gathering technique that involves a one-on-one meeting between a member of the project team and a user or stakeholder.


K

key A value used to uniquely identify each instance of an entity.


L

layered architecture A version of the client/server architecture in which various services in the application are clearly positioned in specific layers.

layered-client-cache-stateless-cache-server architecture A version of the client/server architecture that combines the layered-client-server, client-cache, and cached-stateless-server approaches by adding proxies throughout the system as necessary.

living documents Documents that are used and updated throughout the life cycle of the project.

localization The process of adapting a globalized application to a specific culture and locale, using separate resources for each culture.

logical design A process in the planning phase during which the solution is described in terms of its organization, its structure, and the interaction of its parts from the perspective of the project team.

low-fidelity design A design that shows the main structure and features of the user interface (UI) and illustrates the navigation path.


M

manageability The ease with which a system can be managed on all levels.

management interoperability The tasks of user account management, performance monitoring, and tuning for heterogeneous applications.

master project plan A collection of plans that addresses tasks performed by each of the six MSF team roles to achieve the functionality described in the functional specification.

master project schedule The schedule that applies a time frame to the master plan. The master project schedule synchronizes project schedules across the teams. It includes the time frame in which the teams intend to complete their work.

master risk assessment document A document used to describe the risks associated with developing the solution. The master risk assessment document that is developed during the envisioning phase is reviewed and updated regularly, but particularly at the milestones.

meaningful sample population Instances of information in the UoD, and the real-world problem that the project team is trying to solve.

messaging service A type of service used to route information and deliver information that is not time-dependent to many individuals.

Microsoft Solutions Framework (MSF) A structure developed by Microsoft that is a set of models, principles, and guidelines for planning, building, and managing business solutions.

milestone A point at which the team assesses progress and makes mid-course corrections. Milestones are review and synchronization points, not completion points.

mitigating risk The practice of predicting risks and then taking steps to eliminate them from a proposed course of action.

MSF See Microsoft Solutions Framework.

MSF Process Model A phase-based, milestone-driven, and iterative model that describes a generalized sequence of activities for building and deploying enterprise solutions. The MSF Process Model combines the waterfall model’s milestone-based planning, and the resulting predictability, with the spiral model’s beneficial feedback and creativity.

MSF readiness management process A process to help teams develop the knowledge, skills, and abilities (KSAs) needed to create and manage projects and solutions.

MSF risk management process A discipline that advocates proactive risk management, continuous risk assessment, and decision making throughout the project life cycle.


N

navigation map A map in user interface (UI) design that shows which component is called for each UI event.

network interoperability The ability of multiple vendor systems to communicate with each other without having to use common protocols.

network load balancing (NLB) A technique used to distribute traffic evenly across available servers.

network topology An infrastructure map that indicates hardware locations and interconnections.

NLB See network load balancing.

nonclustered index A type of index that maintains a small table of index information about a column or group of columns.

normalization The process of progressively refining a logical model to eliminate duplicate data from a database.


O

object diagram A UML diagram that depicts various objects in a system and their relationships with each other.

Object Role Modeling (ORM) A rich modeling methodology that allows you to analyze information at the conceptual level and model complex fact-driven, data-related business requirements.

object type The set of all possible instances of a given object.

object-oriented database A data storage system in which database objects appear as programming language objects in one or more existing programming languages.

objects People or things described in usage scenarios.

Online Help Refers to any help that is immediately available upon user request while the user is interacting with the system.

operations requirement A type of requirement that the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks.

operations team The organization responsible for the ongoing operation of the solution after delivery.

ORM See Object Role Modeling.


P

packaging strategy A rationale for determining which services go into each component.

parallel testing A common usage testing strategy in which both the current solution and the solution under development are tested side-by-side at the same time.

Passport authentication A centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites.

performance testing A type of testing that focuses on predicted performance improvements to the solution under development.

physical design The final design process of the planning phase. During this process, components, services, and technologies of the solution are described from the perspective of development requirements.

pilot A test of a solution in the production environment, and a trial of the solution by installers, systems support staff, and end users.

pilot plan A plan that describes how the team will move the candidate release version of a solution to a staging area and test it.

planning phase The second phase of the MSF Process Model, during which the team determines what to develop and plans how to create the solution. The team prepares the functional specification, creates a design of the solution, and prepares work plans, cost estimates, and schedules for the various deliverables. This phase culminates with the project plan approved milestone.

population The group of all combined instances of a given type of item of interest in the UoD.

preliminary deployment model A model that includes network, data, and component topologies and enables the project team and other stakeholders to review the design.

primary keys Keys that uniquely identify each row of data in a table.

problem statement A short narrative describing the issues the business hopes to address with the project. It relates primarily to the current state of business activities.

process A collection of activities that yield a result, product, or service; usually a continuous operation.

process model A model that guides the order of project activities and represents the life cycle of a project.

process view See behavioral view.

product management An MSF Team Model role that is responsible for managing customer communications and expectations. During the design phase, product management gathers customer requirements and ensures that business needs are met. Product management also works on project communication plans such as briefings to the customers, marketing to users, demonstrations, and product launches.

program management An MSF Team Model role that is responsible for the development process and for delivering the solution to the customer within the project constraints.

programming model A model that describes how the development team can use the specific technologies and that sets guidelines for providing consistent component implementation and increasing the maintainability of the components.

project sponsor One or more individuals responsible for initiating and approving the project and its result.

project structure document A document that defines the approach a team will use to organize and manage a project. It describes the team’s administrative structure, standards and processes, and project resources and constraints.

project tradeoff matrix A tool that helps identify the project features that are considered essential, the features that are not essential but that would be good to include, and the features that can be eliminated or added to the next version to accommodate the other two variables.

prototyping A technique in which information is gathered by simulating the production environment. Prototyping is a validation technique in which a prototype is used to provide details of processes, process flow, organizational implications, and technology possibilities.


R

realization A relationship, between classes, in which one abstract class specifies a contract that another class needs to carry out.

regression testing The process of repeating identical actions or steps that were performed using an earlier build of a product on a new build or version of the product.

relational model database A database in which data is stored in multiple tables and columns.

relationships A description of how objects are linked to each other.

release management An MSF Team Model role that is responsible for defect-free deployment and operations of the solution. Release management validates the infrastructure implications of the solution to ensure that it can be deployed and supported.

release readiness milestone The major milestone at the end of the stabilizing phase that represents the point at which the team has addressed all outstanding issues and releases the product.

reliability The ability of the application to provide accurate results.

repeatability A variable that measures how repeatable an issue or bug is. Repeatability is the percentage in which the issue or bug manifests itself. It is expressed as a percentage in the range of 10 percent (integer value 0.1) through 100 percent (integer value 1), where 100 percent indicates that the issue or bug is reproducible on every test run.

repudiation A situation in which a system administrator or security agent is unable to prove that a user—malicious or otherwise—has performed some action.

risk The possibility of loss or injury; a problem that might occur.

risk probability The likelihood that a risk will occur.

risk source Where a risk might originate.

role playing A validation technique in which a set of selected users performs multiple versions of a process to evaluate it and identify areas of potential refinement.


S

scalability The capability to increase resources to produce an increase in the service capacity.

scaling out Distributing the processing load across more than one server.

scaling up Achieving scalability by improving the existing server’s processing hardware.

scope A guideline used to define what will and will not be included in a project. The scope corresponds to the project vision as defined in the vision statement and incorporates the constraints imposed on the project by resources, time, and other limiting factors.

secure communications A generic term used to describe the process of ensuring that messages remain private and unaltered as they cross networks.

security context A generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread.

sequence diagram A UML diagram that describes the interaction between classes. A sequence diagram shows the actors and objects that participate in an interaction, and a chronological list of the events they generate.

service A specific behavior that a business object must perform.

set Any group of instances. A set is not necessarily the same as a population. It can be part of a population, or a combination of instances from more than one population.

severity A variable that measures how much impact an issue or bug will have on a solution, on code, or on users. Severity is an integer in the range of 1 through 10, where classification 10 issues or bugs present the most impact.

shadowing An information gathering technique in which you observe a user performing tasks in the actual work environment and ask the user any questions you have related to the task.

signed data A standards-based data type that consists of any type of content combined with encrypted hashes of the content for zero or more signers.

solution concept A description of the approach the team will take to meet the goals of the project. Provides the basis for proceeding to the planning phase.

spiral model An iterative process model in which the stages of application development are characterized as inception, elaboration, construction, and transition. Each stage has five activity phases: requirements, design, implementation, deployment, and management. The spiral model’s process is a continual cycle through the stages of development, with each stage requiring multiple cycles through the five phases.

spoofing identity An attack involving a malicious user posing as a trusted entity.

SQL injection A type of security error that can occur when developers dynamically build Structured Query Language (SQL) statements by using user input.

stabilizing phase The last of four distinct phases of the MSF Process Model. During this phase, all team efforts are directed toward addressing all issues derived from feedback. No new development occurs during this phase. The stabilizing phase culminates in the release readiness milestone.

state diagram A UML diagram that describes how a class behaves when external processes or entities access the class.

state management A process by which the solution maintains state and page information over multiple requests for the same or different pages.

stateless architecture A version of the client/server architecture in which each client request contains all the information that is required by the server to process the request. No information is stored on the server.

stored procedures Named collections of SQL statements that are stored on the DBMS. They are precompiled, eliminating the need for the query analyzer to parse the statement every time the stored procedure is called.

stress test A type of test specifically designed to identify issues or bugs that might present themselves when the solution under development is operating under extreme conditions.

STRIDE threat model A technique used for identifying and categorizing threats to an application. Each letter in the STRIDE acronym specifies a different category of security threat: spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

structural view A UML view that represents the static or idle state of the system. Also known as the design view.

surveys An information gathering technique in which sets of questions are created and administered to specific sets of users.

synchronous control The situation in which object services are invoked and the calling object waits for control to be returned.

system requirement A type of requirement that specifies the atomic transactions and their sequence in a system. System requirements help the project team define how the new solution will interact with existing systems.

system services Units of application logic that provide functionality outside the business logic.


T

tampering An attack in which a user gains unauthorized access to a computer and then changes its operation, configuration, or data.

technical specification A set of reference documents that usually includes the artifacts of physical design, such as class specifications, component models, metrics, and network and component topologies.

test plan A plan that describes the strategy and approach used to plan, organize, and manage a project’s testing activities.

testing An MSF Team Model role that is responsible for identifying and addressing all product quality issues and approving the solution for release. This role evaluates and validates design functionality and consistency with project vision and scope.

top ten risk list An identification of the ten top priority risks, taken from the risk assessment document.

tradeoff triangle A tool that shows that any change to any one component represented in the tradeoff triangle implies that a corresponding change might need to be made to other components. The tradeoff triangle helps to explain the constraints and present the options for tradeoffs.

transactional service A type of service that provides the mechanism and environment for a transaction-based application.

type-safe code Any code that accesses only the memory it is authorized to access.


U

UML See Unified Modeling Language.

Unified Modeling Language (UML) A standard modeling language that is used to model software systems of varying complexity.

unit test A type of developer-performed internal coverage testing that takes advantage of automated testing.

universe of discourse (UoD) An application area in ORM that you create to design a solution.

UoD See universe of discourse.

usage scenario Specifies the activity performed by a particular type of user and provides additional information about the activities and task sequences that constitute a process.

usage testing A type of high-level testing that is often performed by potential users of a solution or by subsets of this group.

use case A description of high-level interactions between an individual and a system. A use case specifies the sequence of steps that a user will perform in a usage scenario.

use case diagram A UML diagram that represents the functionality that is provided to external entities by a system.

user experience An MSF Team Model role that is responsible for analyzing the performance needs and support issues of users and for considering the product implications of meeting those needs.

user instruction An information gathering technique in which users train the project team on the tasks that they perform.

user interface components Components that manage interaction with the user, display data to the user, acquire data from the user, interpret events that are caused by user actions, change the state of the user interface, and help users view progress in their tasks.

user profile A document that specifies the various users of the solution and their roles and responsibilities.

user requirement A type of requirement that defines the nonfunctional aspect of a user’s interaction with a solution.

user services Units of application logic that provide the user interface in an application. The user services of an application manage the interaction between the application and its users.

user view A UML view that represents the part of the system with which the user interacts.


V

vertical partitioning A method of partitioning tables in which a table containing many columns is divided into multiple tables containing rows with equivalent unique identifiers.

visibility A variable that measures the situation or environment that must be established before an issue or bug manifests itself. Visibility is a percentage in the range of 10 percent (integer value 0.1) through 100 percent (integer value 1), where 10 percent indicates that the issue or bug is visible under only the most obscure conditions. Issues or bugs that manifest themselves in environments with under common conditions are said to be highly visible.

vision statement A short, concise statement used to establish a common vision and reach consensus among team members that a project is valuable to the organization and is likely to succeed.

vision/scope meeting A meeting during which the team and the customer arrive at a shared understanding regarding how the proposed solution will address the business challenge and how it is applicable to the current business scenario, given the scope that has been defined.


W

walkthrough A validation technique in which a facilitator guides users through a scenario and asks questions to determine whether the users agree with the description of individual actions and events.

waterfall model A linear process model that has the following well-defined development steps: system requirements, software requirements, analysis, program design, coding, system test, and operations. This process model has fixed transition and assessment points. All tasks for a particular step must be completed before proceeding to the next step.

Windows authentication A system used by Microsoft ASP.NET in conjunction with Internet Information Services (IIS) authentication.

wizard A user assistance device that guides users step by step through a procedure.


Z

ZBB See zero-bug bounce.

zero-bug bounce (ZBB) The point in the project when development resolves all the bugs raised by testing and there are no active bugs. More bugs might be logged after this point.

zero-defect mindset The goal for project teams in which the team commits to producing the highest quality product possible.


About This eBook

This eBook has been converted from the print version of this title. Every effort has been made to ensure the accuracy of this conversion. For readability and accessibility reasons, the eBook version may contain differences in formatting from the original print version. The content of the eBook is not updated to reflect any content changes made for reprint releases.

Figures and Images

The figures and screen shots throughout the book are converted to electronic format as 1:1 images. The eBook uses Microsoft Internet Explorer to shrink the images down to fit within the content pane. To see the larger 1:1 image, simply click on the image. The 1:1 image will open in a separate window. If you click on more than one image to view the 1:1 image, each image will open in a separate window, and remain open until that window is closed.

Search

The .CHM format allows full-text searching to better locate the information you need. To conduct a search, open the eBook and click the Search tab. In the Search Topics text box, type the word or topic on which you wish to search. Click List Topics to display the search results. To view a search result, either a) double-click on the result in the Select Topic list, or b) click on the result in the Select Topic list, and click Display. The topic will then display in the content pane. Search results are ranked by the number of times the words searched on occur within the topic results. The highest-ranked topic will include the most references to the search criteria.

For advanced search options, open the drop-down list next to the search input box to clarify multiple search terms with the parameters AND, OR, NEAR, or NOT.

Favorites

To save a topic for viewing later, select the topic so that it displays in the content pane. Select the Favorites tab. The topic title, or heading, will appear in the Current Topic box. Click Add and the topic title will appear in the Topics pane. To view a topic saved in Favorites, select the title, and click Display. To remove a Favorite topic at any time, select it from the topic pane, and click Remove.

External Links

This eBook may contain links to Web sites outside of the Microsoft domain. All hyperlinks within the text were valid at the time this eBook was published. Due to the nature of the World Wide Web, we cannot guarantee that all links to Web sites are still valid after the release date of the eBook.

Accessibility

This eBook utilizes Internet Explorer to display content. Internet Explorer offers many accessibility features, such as keyboard shortcuts and compatibility with Assistive Technology. To find out more about accessibility within Internet Explorer, go to www.microsoft.com/enable/products and select the version of Internet Explorer installed on your computer.

Tell Us What You Think

We need to hear from you regarding your experience with our eBooks. Tell us what you like, don't like; which features you use, and which features you would like to see in future versions of our eBooks. Send your comments to epublish@microsoft.com. Please note that technical support is not offered through this alias.

About Microsoft Press

Microsoft Press is a division of Microsoft Corporation and the leading source of comprehensive self-paced learning, training, evaluation, and support resources to help everyone from developers to IT professionals to end users get the most from Microsoft technology. Choose from hundreds of current titles in print, multimedia, and network-ready formats—learning solutions made by Microsoft, with the most timely and accurate information available. For more information, visit www.microsoft.com/mspress.