CHAPTER 1 Introduction to Designing
Microsoft certified solution developer.
Exam 70 -- 300.
Go back and cover, general understanding of the
software development life cycle.
Chapter 1, introduction to designing business
Microsoft solutions framework. MSF.
Lesson one: overview of the Microsoft solutions
Phases in the MSF process model, roles in the MSF team
MSF disciplines, risk management, readiness management,
and project management.
Purpose of iteration, waterfall model and spiral model.
Waterfall model, spiral model.
The MSF process model combines the best principles of
the waterfall and spiral models.
Waterfall model has simple milestones in a step down
The spiral model goes round and round.
This model is based on the continual need to refine
requirements and estimates for a project.
Effective when used for rapid application development
of very small project. Can generate
No clear checkpoints or milestones, consequently the
development process might become chaotic.
Think of the MSF model as, the spiral model with
The MSF process model consists of five distinct phases.
Each phase culminates in a milestone.
MSF team model.
This model emphasizes the importance of clear roles,
responsibilities, and goals of individual members to the success of the
The flexibility of the MSF team model helps you adapt
to the scope of the project , the size of the team, and the skill of each
This model forms of basis of creating effective,
resilient, and successful project teams.
The team worked toward a single vision, team members
operate as peers, each is responsible equally.
MSF team member roles.
In a small project, individuals may take on more than
Combining roles adds risk to a project.
See page 5 in chapter 1 for more details.
Not part of the MSF team.
2. Customer or
3. End user.
Includes disciplines for managing people, processes,
and technology elements that most projects encounter.
The three MSF disciplines are No. 1. risk management, No. 2. readiness management, and No. 3. project management.
The MSF risk management discipline advocates proactive
risk management and continuous risk management in decision-making
throughout product life cycle.
The team continuously assesses, monitors, and actively
manages risk until resolved or turn into problems to be handled as such.
No. 1. Risk
The MSF risk management process defines six logical
steps through which the team manages current risk, plans and executes
risk management strategies, and documents knowledge for the enterprise.
analysis, transforms the estimates of data about risk into a form the team
can be used to make decisions about prioritization.
planning. Information from the
analysis is used to formulate strategies, plans, and actions.
tracking. Monitors the status, and
documents the progress of the plans.
control. Process of executing risk
action plans and their associated status reporting.
learning. Documents the lessons
learned, tools used, and records the knowledge and reusable form for use
within the team and by the enterprise.
See more about MSF risk management in chapter 3. Envisioning the solution.
No. 2, readiness management.
The MSF readiness management discipline includes a
process to help you develop the knowledge, skills and abilities needed to
create a managed project and solutions.
There are four steps of the readiness management
Breakdown, four steps of the readiness management
A. Define, identifies the scenarios, competencies, and
proficiency levels needed to successfully manage the solution.
B. Assess, team begans analysis of the current
competencies as they relate to the various job roles. Comparing current skill level to require
skill level is necessary to develop a learning plan, so that team members
can reach the necessary competency levels.
C. Change, team members began to improve their skills
by means of structured learning to raise current proficiency levels to the
desired levels. Steps include.
1. Training, learning
and mentoring that occurs according to what was outlined in the learning
progress, enables individuals or overall readiness to be determined at any
time. This tracking enables the
members to make necessary adjustments to the learning plan.
D. Evaluate, the team determines whether the learning
plans were effective and whether the lessons learned are successfully
implemented on the job.
To the MSF readiness management process is an ongoing,
and iterative approach to readiness.
The process is adaptable for both large and small
Term:KSA= knowledge, skills, abilities.
Following the steps in the process helps manage the
various tasks required to align the individual, project team, and
organizational knowledge, skills and abilities.
No. 3. MSF
project management process.
To deliver a solution within constraints, strong
project management skills are necessary.
planning and change control.
B. define and manage the scope of the project.
C. prepare a budget and manage costs.
D. prepare and track schedules.
E. insure that the right resources are allocated to the
F. manage contracts and vendors and procure project
G. facilitate team and external communications.
H. facilitate the risk management process.
I. document and monitor the team's quality management
The MSF team model does not contain a project manager
role, however most project management functions are conducted by the MSF
program management role.
Major issue here, major issue here, major issue here,
major issue here, major issue here.
The differentiating factor of the MSF approach to
project management is that project management job function activities do
not form the hierarchy structure in the decision-making process.
The MSF advocates against a rigid dictatorial style of
project management. The rigid style
hinders the development of an effective team of peers, which is a key
success factor of MSF.
All roles are equally important, major decisions are made
by consensus of the core team.
The program management role makes a final decision on
the issue by moving into the role of decision leader to enable the project
Program management role makes the decision with the
goal of meeting the customers requirements in delivering the solution
within constraints. After the
decision is made, the team returned to operate as a team of peers.
How to manage trade-offs. Project scope.
Ambiguous projects scopes can contribute to failure.
The scope of a project specifies what the solution will
and will not do.
To effectively define and manage the scope, you need
2. Manage trade
Identifying trade-offs might result in a reduction of
features. Both the team and the
customer must review the trade-offs and be prepared to make difficult
The trade-off triangle, and the project trade-off
matrix, are two of the tools that MSF uses for managing trade-offs.
Page 8 of 25 in chapter 1.
The triangle consist of, resources, deployment date,
Project trade-off matrix, helps identify the features
that are essential, semi essential, and not essential or added to the next
Example: given fixed _________, we will choose a
___________, and adjust ____________ if necessary.
Here are some following 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.
For the trade-off process to work effectively, both the
team in the customer must agree to improve the matrix.
Iterations are continued within a specific days until
the goal for the phase has been reached.
Instances of iterations in a project life-cycle
3. Creating periodic
builds, weekly or daily.
releases. 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 released
Think of the spiral model, with three circles, version
1, version 2, and version 3. Each
version has its own spiral model.
Increasing on the y axes.
Version releases improve the team's relationship with
the customer and insure the best ideas are reflected in the solution.
Customers will be more receptive to defer features
until a later release date, if initial releases and later releases are met.
Guidelines facilitate the adoption of version releases.
A. Create a
multiple version released plan.
This allows the team to make the best use of available resources and
B. Work through
iterations rapidly. Maintaining a
manageable scope, not an expanding one. Danger here is an expanding scope.
C. Deliver core
functionality first. Delivering a
solid based solution quickly is better than nothing for months.
This also allows developers to incorporate customer
feedback that will motivate feature development and subsequent iterations.
high-risk features first. During
the risk assessment phase, the team identifies the riskiest features.
2. Living documents
documentation that changes as the project changes. Living documents allow things to make
modifications to the aspect of project design in the initial set of
requirements. This process ensures
that completed solution meets the final requirements and not the initial
ones. MSF project documents are
The MSF model recommends that planning documents start
out as generalized documents without extensive details.
As the solution progress is through different phases,
the documents are developed into detailed plans.
These plans are once again reviewed and modified
iteratively. The number of these
plans depend on the size of the project.
periodic builds. Daily builds.
MSF recommends frequent builds for testing and reviews.
This applies to code in addition to builds of hardware
and software components.
By creating daily builds, you insure that you
understand the stability of the total solution. You have also have cumulative ample test that before
releasing the solution.
Daily builds is particularly effective for larger,
complex projects that are divided into smaller subsystems.
Development and testing occurred continuously and
Daily builds insurer that all code is compatible, an
allows the various sub teams to continue their development and testing
2: Phases in the MSF Process Model
Lesson 2. Phases in the Microsoft solution framework
process model. MSF.
As stated in lesson 1, the MSF's process model is
milestone based with five phrases.
This lesson covers, the past, milestones, and
deliverables, of the envisioning, planning, developing, stabilizing, and
deploying phases of the MSF process model.
Creating a broad description. The goals and constraints of the project. Here you identify the team and what the
team must accomplish. To build a shared
vision. With all key stakeholders
of the project.
This culminates in a vision and scope approved
The milestone indicates that the customer and the team
agree about the purpose and direction of the project.
1. Setting up
the team. Usually senior
management. Remember the skills,
and resources available.
2. Defining the
project structure., identification of administrative structure for the
team, and standards for management of the project.
3. Defining the
business goals. Analysis of the
business problems and opportunities in order to identify the objectives for
the current situation. Analyze the
difference between the current unexpected situation. Here you create problem statement and
identify the direction of the project.
5. Creating a
mission statement and defining the scope of the project. Identification of the scope, defines
what will and will not be included in the solution. This is fundamental to the project.
requirements and user profiles.
Identification of the stakeholders, in users, and sponsors for the
project and documentation of their requirements for the solution.
7. Developing a
solution concept. Creation of a
baseline solution concept. Outlining
the approach the team will take.
This concept is created by using the requirements that have been
risk. This is an interative step
that is conducted during all stages of the product lifestyle.
9. Closing the envisioning phase. This is accomplished when the
vision-scope document is formally approved. All stakeholders including the project team.
Milestones of the envisioning phase.
Interim milestones of the envisioning phase are.
1. Core team
organized. Not complete team. Roles and responsibilities of each
member. Hierarchy of
accountability, points of contact with customer. Structure of the team.
2. Vision --
scope created. The first
version. And distributed among all.
Review cycle, iterations of feedback, discussions, and
Including the general timetable,
Deliverables of the envisioning phase.
1. Vision --
Problem statement and business objectives.
A review of the existing processes.
A broad definition of user requirements.
User profiles identifying who will benefit from the
A vision statement and scope definition.
The solution concept outlining the approach the team
will take to plan the project.
Solution design strategies.
A description of all MSF team roles and a list of
corresponding team members.
The project structure and process standards for the
team to follow.
A preliminary risk assessment.
A list of the primary identified risk.
Plans for mitigation or eliminating the identified
The team determines what to develop, and how to create
Functional specifications, create the design of the
solution, and prepares plans, cost estimates, and schedules for the various
The planning phase involves the analysis of requirements.
Requirements validate the correctness of the design.
Here the team create user profiles that specify the
various users of the solution and their roles and responsibilities. The team create a series of usage
scenarios. The scenario specifies the
activity performed by the particular type of user. Usage scenarios are completed for all
user profiles. After creating usage
scenarios, the team creates use cases for the usage scenarios. A use case specifies sequence of steps
that a user will perform in a usage scenario.
design. You the problem from the
perspective of the users and business.
Define the problem and solution in terms of usage scenarios.
design. You view the solution from
the perspective of the project team, and define the solution as a set of
design. You view the solution from
the perspective of the developers.
Defining technologies, component interfaces, and services of the
The functional specification describes the behavior in
appearance of each feature of the solution. It describes the architecture and design for all features.
The team performs a following key tasks during the
the solution design and architecture.
Identify the business requirements, user requirements, and
technologies in the use of this information to design a proposed
2. Create the
functional specification. This
describes the requirements that must be met by the solution.
project plans. Consolidate the
plans into a master project plan.
The master project plan includes the approach, dependencies, and
assumptions for the solution.
project schedules. Creation of the
master project schedule. Consists
of milestone based schedules for each of the team roles in the project
5. 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 original environment. A.k.a. test bed.
6. Closing the
planning phase. Completion of the
milestone approval process.
Documentation of the results of completing the task preformed during
the planning phase.
Milestones of the planning phase.
The interim milestones of the planning phase are as
validation complete. The team
evaluates the products and technologies that will be used. The team also checks out its customers
current production environment.
This includes server configurations, network, desktop software, and
all relevant hardware.
specifications complete. At this
milestone, the functional specification is completed and submitted for
review to the customers and stakeholders.
Remember, design document is different from the functional
specification. The design document
is written for the project team and describes the internal workings of the
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.
project schedule complete. The
schedule includes all detailed project schedules and the solution release
date. Like the master plan, the
master schedule combines and integrates information from each of the roles
of the team.
and test environments set up. Test
bed, server configurations, employment automation tools, hardware, are
identify 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
the interim milestone has been met.
They agree that due dates are realistic, project roles and
responsibilities are well-defined, and everyone agrees to the deliverables
for the project. They agree the
mechanisms are in place for addressing areas of project risk.
Planning phase deliverables.
The planning phase deliverables provide the basis for
making future trade-off decisions.
The following are the deliverables produced during the planning
project planning master project schedule.
Here the project team creates the solution. This process includes greeting code that
implements the solution and documenting the code. In addition to code the team also develops the infrastructure
for the solution.
The following key tasks are.
1. Starting the
development cycle. The verification
that all tasks during the envisioning and planning phase's has been
2. Creating a
prototype application. Verification
of the concept. This environment is
as similar as possible to the production environment. Now actual developing occurs.
the solution components.
Developing of the solution's core components and the
extension of these components to the specific needs of the solution.
4. Building the
solution. A series of daily or
frequent builds that culminate with the major internal builds as
significant points that the development team is delivering key features of
5. Closing the
developing phase. Completion of all
features, and delivery of code in documentation. The solution is considered complete. The team enters a milestone approval
Developing phase milestones.
Here the team creates a proof of concept application
and creates the solution.
1. Proof of
concept application complete. This
test key elements of the solution in the test environment. The team leads the operations team and
users through the solution to validate the requirements.
builds complete. Because they
solution is developed in segments, it is a good practice to synchronize the
solution segments Product level.
You do this with the help of internal builds. Number of frequency of internal builds
depends on the size and complexity of the project.
The developing phase culminate in the scope complete
milestone. All features or complete
and have gone three in testing. The
product is now ready for external testing and stabilization. Additionally, customers, users,
operations in support personnel, and key project stakeholders can evaluate
the product and identify any issues that must be addressed before the
solution is shipped.
Developing phase deliverables.
1. Source code
in executable files.
scripts in configuration settings for deployment.
specifications and test cases.
Here the team performs integration, load, and beta
testing. In addition, the team test
the deployment scenarios for the solution.
The team focuses on priorities and resolving issues for solution
All features are complete, all quality levels are
met. The solution is ready for
This is after the solution is considered stable.
1. Testing the
2. Conducting a
pilot. Deployment of the solution
in the staging area and testing of the solution with actual users and real
1. Testing the
The pilot is conducted a test environment, a rigorous
acceptance in usability testing.
capacity and performance testing.
9. Recording the
number of bugs.
2. Conducting a
pilot. Deployment of the solution
in the staging area and testing of the solution with actual users and real
Test tracking recording. Test tracking recording occurs or frequent intervals during
the developing, testing, and stabilization phases. During the stabilization phase,
reporting is dependent upon issued and by.
Regular communication of test that is to the team and other key
stakeholders insurers a well-informed teen.
Stabilizing phase milestones.
convergence. The rate of bugs
resolved exceeds the rate of bugs found.
After convergence, the number of bugs continue to
decrease until zero bug release.
The end of the project is near.
2. Zero bug
3. Release candidates.
release combination of zero of the effects and success criteria matrix
The stabilization phase culminates in the release
readiness milestone. All issues
have been addressed. Product have
been shipped. At this point, the
responsibility for managing and supporting the solution is officially
transferred from the project team to the operations and support teams.
Stabilization phase deliverables.
4. Test results
in testing tools.
5. Source code
in executable files.
During his phase, the team employs the solution
technology & site components, stabilizes the deployment, and transfers
the project to operations and support.
They also obtain the final customer approval of the project. The team indexing project reviewing the
customer satisfaction survey. The
deploying phase culminates in the deployment complete milestone.
Following key tasks.
of deployment in operations procedures.
Formal documentation of deployment operational procedures outline
how the project team intends to perform deployment in transition task.
and stabilization. Completion of
the actual component and site deployment's.
review. Completion of post project
reviews with the customer and project team.
Stabilization activities might continue during his
phase because the project components are transferred from test environment
to the production environment.
Deployment interim milestones.
components deployed. Other not core
components, might be still stabilizing.
Sometimes the core components must be installed, while other none
core components are being stabilized.
deployments complete. At this
point, all intended users must be able to access the solution.
Lead developers must confirm that their sites are
This milestone might not be applicable for project to
do not include clients side deployment.
stable. The customer and team agree
that the sites are operating satisfactorily. Some issues might exist, but they will be able to be track
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. Typical quiet periods last
15 to 30 days. During this time,
the team managers the effectiveness and performance of the solution. They estimate the maintenance effort
required for continuing operations.
The team can also work on the next release of the solution during
complete. This is a culmination of
the deploying phase. By this time
the solution should be providing the expected value.
It can be difficult to determine when a deployment is
The team can have a difficult time closing the project
because of ongoing issues.
Therefore, the team needs to clearly defined in completion milestone
for the deployment, rather than attempting to reach a point of absolute
Deploying phase deliverables.
and support information systems.
A. Procedures and processes.
knowledge base, reports, and logbooks.
repository for all versions of documents and code developed during the
3. A training
final versions of all project documents.
customer satisfaction data.
definition of next steps.
Lesson 3, introducing a case study, adventure work
session will be place here………………………..thanks. lance
3: Introducing the Case Study—Adventure Works Cycles Application
CHAPTER 2 Gathering and
1: Gathering Information
2: Analyzing Information
3: Using Modeling Notations
4: Creating Use Cases and Usage Scenarios
Gathering and Analyzing Information
CHAPTER 3 Envisioning the
1: The Envisioning Phase
2: Creating a Vision/Scope Document
3: Creating the Project Structure Document
4: Analyzing Risks
Developing a Vision/Scope Document
CHAPTER 4 Creating the
1: An Introduction to the Planning Phase
2: An Overview of the Functional Specification
3: An Overview of the Conceptual Design Process
4: Building the Conceptual Design
5: Optimizing the Conceptual Design
CHAPTER 5 Creating the
1: An Overview of Logical Design
2: Creating a Logical Design
3: Documenting Logical Design Output
4: Optimizing Logical Design
Identifying Objects for the Logical Design
CHAPTER 6 Creating the
1: An Overview of Physical Design
2: Physical Design Analysis
3: Physical Design Rationalization
4: Physical Design Implementation
Working on the Physical Design
CHAPTER 7 Designing the
1: Basics of User Interface Design
2: Designing the User Interface
3: Designing User Process Components
Creating the User Interface
CHAPTER 8 Designing the
1: Designing the Data Store
2: Optimizing Data Access
3: Implementing Data Validation
Creating a Data Schema
CHAPTER 9 Designing
1: Overview of Security in Application Development
2: Planning for Application Security
3: Using .NET Framework Security Features
4: Designing Authorization, Authentication, and Auditing Strategies
Threat Modeling and Mitigation
CHAPTER 10 Completing the
1: Incorporating Design Considerations
2: Planning for Administrative Features
3: Planning for Future Phases
4: Creating the Technical Specification
Reviewing a Test Plan and Technical Specification
CHAPTER 11 Stabilizing and
Deploying the Solution
1: The MSF Stabilizing Phase
2: Testing and Piloting for Stabilization
3: The MSF Deploying Phase
4: Deploying to a Production Environment
APPENDIX A Questions and