Tài liệu Module 2: Solution Design Processes pdf

Module 1: Course OverviewModule 4: Deriving a Logical Data Design Module 5: Normalizing the Logical Data Design DesignProcesses Services-BasedDesign Activity 2.1: Identifying Services Mo

Module 2: Solution Design Processes

Module 1: Course Overview

Module 4: Deriving a Logical Data Design Module 5: Normalizing the

Logical Data Design

DesignProcesses

Services-BasedDesign

Activity 2.1: Identifying Services

Module 2: Solution Design

Processes

At the end of this module, you will be able to:

" Explain design processes as they pertain to business solutions and centric solutions

data-" Explain the concepts and benefits of services-based design

" Identify phases in the project life cycle

This module provides a high-level overview of the MSF Process Model, the MSF Design Process Model, and the MSF Application Model The courses

in the MSF curriculum cover these topics in greater detail For more information about the MSF curriculum, see http://www.microsoft.com/msf/

In this module, you will learn

about the MSF Process

Model, the MSF Design

Process Model, and the

MSF Application Model, as

well as Windows DNA

Note

! Design Processes

" Requirements Gathering

" Benefits of the Design Process

In this section

In this section, you will learn about design processes and the MSF Process Model You will see how these processes form an application model for solution design and how the design processes interact with each other

Slide Objective

To explain the purpose of

this section and what

students will learn in this

section

Lead-in

In this section, you will learn

about design processes for

business and data-centric

solutions

The MSF Process Model

" Course 1608 also covers the Planning Phase, but it focuses on application design

Release

Course 1609

Scope Complete

Scope Complete Approved Approved Vision Vision

Project Plan Approved

Project Plan Approved

Microsoft® advocates the MSF Process Model for Application Development as the recommended project life cycle model for business-solution software development projects

The MSF Process Model is phase-based, meaning that each project is broken into distinct phases so that the team and key stakeholders understand where the project is in the life cycle and what key tasks are being accomplished

The MSF Process Model is milestone driven, meaning that each phase culminates with a deliverable-based milestone that marks the team’s progress This milestone creates a point of transition, synchronizes the project team and customer, and allows for review and possible corrective action

The phases of the MSF Process Model are as follows:

" The Envisioning Phase is the period during which the team and customer define the business requirements and overall goals of the project The Envisioning Phase culminates in the Vision Approved Milestone, indicating that the team and customer agree on project direction

" The Planning Phase is the period during which the team and customer define what will be built, as well as how and when it will be built The Planning Phase culminates in the Project Plan Approved Milestone, indicating that the team, customer, and key stakeholders agree on what will

be delivered and when

" The Developing Phase is the period during which the team implements the design and builds the application The Developing Phase culminates in the Scope Complete Milestone, indicating that code for all features is complete and that the product is ready for external testing and stabilization

Slide Objective

To describe the four phases

and the four major

milestones of the MSF

Process Model and to

explain which phase of the

MSF Process Model will be

covered in this course

Lead-in

This course focuses on the

beginning stages of the

Envisioning Phase of the

MSF Process Model

Delivery Tip

Point out that these are

standard, major milestones,

but that each project will

also have its own unique

interim milestones

The model is conceptual, so

it does not represent ratios

of duration

Each phase and major

milestone will be examined

in more detail in later

modules

" The Stabilizing Phase is the period during which team efforts are directed at addressing all known issues (from code defects to mismanaged

expectations) No new development occurs during this phase; rather, the application code is stabilized and optimized The Stabilizing Phase culminates in the Release Milestone, at which point responsibility for the product shifts to the operations team

This course focuses on the Planning Phase of the MSF Process Model You will learn how to take the requirements gathered in the Envisioning Phase and turn them into a data design and data services

This course leads into the Project Plan Approved Milestone, which signals that the functional specification of the application is complete to a point that it can begin to be implemented

" This process results in:

Before any business and data solution can be built, both the problem and the desired solution must be understood This understanding is not always easy to achieve, and complete, reliable information is critical for good decision-making When gathering information, you need to consider business needs, business processes, existing systems, and the people involved

The process of gathering information and requirements leads to a business justification for the project It also generates descriptions of what actions and processes (if any) the current system performs and what the future application needs to do to satisfy the requirements

Slide Objective

To introduce topics related

to the gathering of data

Lead-in

Data gathering forms the

basis for all future design

processes

The MSF Design Process Model

Conceptual Design

Scenarios

Services and Objects, User Interface, and Logical Database

Logical Design

Components, User Interface, and Physical Database Physical Design

The MSF Design Process Model consists of three design phases—conceptual, logical, and physical—which are described as follows:

" Conceptual design The goal in conceptual design is to identify business needs and to understand what users do and what they require The design team views the problem from the perspectives of the user and the business and defines the problem and solution in terms of scenarios that reflect complete and accurate requirements

Conceptual design does not take into account the approach or the technologies needed to build the solution Rather, conceptual design is equivalent to rough sketches for building a house These are easily understood models jointly created by the customer and the architect

" Logical design The goal in logical design is to define the solution’s organization and communication among its different parts The design team views the solution from the perspective of the project team and defines it as a set of cooperating services The design team does not, however, define these services in terms of a specific technology

Logical design takes the business problem identified in the scenarios of conceptual design and formulates an abstract model of the solution that includes objects and services, user interface prototypes, and a logical database design The logical design details a plan and set of specifications for building a solution, much like a detailed blueprint for building a house

" Physical design The goal in physical design is to apply real-world technology constraints, including implementation and performance considerations, to the logical design The design team views the solution from the perspective of the developers and defines the solution’s services and technologies At this point, the project team can begin to consider the best way to implement the solution and the appropriate tools to use

Slide Objective

To briefly describe the

conceptual, logical, and

physical design phases of

the MSF Design Process

Model

Lead-in

You need to understand the

three distinct stages of

design

Delivery Tip

Make sure you stress the

importance of conceptual

design Also emphasize that

conceptual design for

data-centric solutions will have to

consider data requirements

as they relate to the rest of

the design

Delivery Tip

The boundary between

conceptual and logical

design can sometimes be

vague Try to help students

understand that these two

design processes are

distinct, and that logical

design begins after the

conceptual idea is in place

In physical design, the outputs of logical design are used to produce components, user interface specifications, and physical database design To use the house metaphor once more, physical design is where the plans of various contractors for the physical elements of the structure—such as wiring, plumbing, heating, and ventilation—are reviewed and selected The contractors’ plans add detail to the architects’ plans and reflect real-world construction constraints

Data and the MSF Design Process Model

" Conceptual data model

" Logical data model

" Physical data model

The MSF Design Process Model represents the design of a solution as a flow from conceptual design to logical design to physical design Determining when one design stage ends and the next one begins is sometimes difficult Part of the challenge in understanding and producing conceptual, logical, and physical designs is knowing what real-world outputs should be produced by each design stage

In conceptual design, the data requirements for a solution are researched, documented, and analyzed These requirements help determine what actually needs to be stored and processed by the business solution

In logical design, a preliminary set of data entities derived from the data requirements are produced These entities are documented and mapped out, and the relationships between entities are identified The logical design helps ensure that the data design for the solution will represent and map to the conceptual requirements

In physical design, the entity models produced in logical design are mapped to tables, fields, and relationships in a database This database physically

represents the logical model

Slide Objective

To introduce how the stages

of the MSF Design Process

Model relate to data-centric

solutions

Lead-in

The conceptual, logical, and

physical design stages of

the MSF Design Process

Model can be used to

that encompasses much

more than the models briefly

discussed in this course

Although this course cannot

delve into the details,

encourage students to

research on their own, or

discuss MSF after class

Benefits of the Design Process

" Ensures that the business problem is solved

" Assists in building a consensus

" Brings discipline to the application development process

The main benefit of the design process is that it helps ensure that the final application solves the original business problem

In addition, the design process aids in building a consensus among groups in an organization A consensus is necessary between the business and user, and between the business environment and developer, to ensure that everyone supports the project This consensus also helps to determine whether the application solves the business problem in the best way

The design process brings discipline to the application development process By following the required phases, stages, and steps, the project team ensures that the development project is complete and well designed First, the team gathers and analyzes data; they then undertake the conceptual, logical, and physical design of the application; finally, they implement the application based upon those designs

Slide Objective

To explain some of the key

benefits of the design

process

Lead-in

Using this design process

has several benefits

! Services-Based Design

" Data Services

" Examples of Services

" Benefits of Services-Based Design

" Activity 2.1: Identifying Services

In this section

In this section, you will learn what a service is and what types of services make

up an application

Slide Objective

To explain the purpose of

this section and what

students will learn

Lead-in

In this section you will learn

about the services that

make up an application

The MSF Application Model

A logical network of cooperative, distributed, and reusable services that support a business solution

The MSF Application Model provides a logical, three-tier, services-based approach for designing and developing software applications and business solutions According to this model, an application is a logical (not physical) network of cooperating services that together achieve a common goal

The services can be distributed across both physical and functional boundaries

to support the needs of the business solution The possible breadth of use of each service allows for parallel development, better use of technology, easier maintenance, and increased flexibility in the distribution and deployment of each logical service in the solution

Each logical division of the solution falls into one of three categories:

" User services are components and services that exist to help the user work with the solution

" Business services are components and services that encapsulate business logic for one or more solutions General business drivers (decision-making logic) can be employed at this level to ensure that a business process is carried out in an exact manner, no matter which application requests the service

" Data services are components and services that encapsulate manipulation logic for a given set of user and business services Data services provide an isolation layer between the business logic and the actual data

containing three types of

services: user services,

business services, and data

services

Logical Network of Cooperating Services

Business Services

User Services

Data Services

The MSF Application Model does not consider business solutions to be monolithic implementations, but instead views them as a logical network of reusable services This overlapping of services creates a network of applications that allows the efficient reuse of logic and components The network exists as a collection of cooperative and distributed services that support a business solution

The services should always focus value and actions toward the customer, not the provider In this way, each service stays true to its initial design and maps directly to actions desired by the user

Slide Objective

To explain how applications

can integrate and use

services from other

applications

Lead-in

Services can cooperate with

services at other layers or in

other applications

Data Services

" Abstract implementation of data storage

Data services are responsible for ensuring that requests for data are performed properly, regardless of the underlying data structure They primarily abstract the various data-storage engines to the business services so that the business services can employ similar logic across multiple data services

If the underlying database changes, the data services can hide those changes from other services and make sure that requests for data are fulfilled in the appropriate manner In this way, only the data services need to be aware of the change

Data technologies are also encapsulated so that the user and business services never have to be concerned with how the data is being accessed

between data stores and the

other services that use data