|
CHAPTER 1 Introduction to Designing
Business Solutions
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
solutions.
Microsoft solutions framework. MSF.
Lesson one: overview of the Microsoft solutions
framework.
Coverage.
Phases in the MSF process model, roles in the MSF team
model.
MSF disciplines, risk management, readiness management,
and project management.
Managing trade-offs.
Purpose of iteration, waterfall model and spiral model.
Models.
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
framework.
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
great synergy.
No clear checkpoints or milestones, consequently the
development process might become chaotic.
Think of the MSF model as, the spiral model with
milestones.
The MSF process model consists of five distinct phases.
Envisioning.
Planning.
Developing.
Stabilizing.
Deploying.
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
project.
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
member.
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.
1. Product
management.
2. Program
management.
3. Development.
4. Testing.
5. Release
management.
6. User
experience.
In a small project, individuals may take on more than
one role.
Combining roles adds risk to a project.
See page 5 in chapter 1 for more details.
Project stakeholders.
Not part of the MSF team.
1. Project
sponsor.
2. Customer or
business sponsor.
3. End user.
4. Operations.
MSF disciplines.
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
management.
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.
A. Risk
identification.
B. Risk
analysis, transforms the estimates of data about risk into a form the team
can be used to make decisions about prioritization.
C. Risk
planning. Information from the
analysis is used to formulate strategies, plans, and actions.
D. Risk
tracking. Monitors the status, and
documents the progress of the plans.
E. Risk
control. Process of executing risk
action plans and their associated status reporting.
F. Risk
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
process.
A. Define.
B. Assess.
C. Change.
D. Evaluate.
Breakdown, four steps of the readiness management
process.
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
plan.
2. Tracking
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
project.
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.
A. Integrate
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
project.
F. manage contracts and vendors and procure project
resources.
G. facilitate team and external communications.
H. facilitate the risk management process.
I. 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.
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
to continue.
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
to.
1. Identify
project constraints.
2. Manage trade
offs.
3. Establish
change control.
4. Monitor
project progress.
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
choices.
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,
and features.
Project trade-off matrix, helps identify the features
that are essential, semi essential, and not essential or added to the next
version.
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
include.
1. Creating
version releases.
2. Creating
living documents.
3. Creating periodic
builds, weekly or daily.
1. Version
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
strategy.
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
scheduling.
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.
D. Create
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
developed iteratively.
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.
3. Creating
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
simultaneously.
Daily builds insurer that all code is compatible, an
allows the various sub teams to continue their development and testing
iterations.
Lesson
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.
1. Envisioning.
2. Planning.
3. Developing.
4. Stabilizing.
5. Deploying.
This lesson covers, the past, milestones, and
deliverables, of the envisioning, planning, developing, stabilizing, and
deploying phases of the MSF process model.
30 minutes.
1. Envisioning.
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
milestone.
The milestone indicates that the customer and the team
agree about the purpose and direction of the project.
Envisioning process.
Key tasks.
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 solution.
4. Assessing
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.
6. Defining
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
identified.
8. Assessing
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
corresponding modifications.
Including the general timetable,
Deliverables of the envisioning phase.
1. Vision --
scope.
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
solution.
A vision statement and scope definition.
The solution concept outlining the approach the team
will take to plan the project.
Solution design strategies.
2. Project
structure.
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.
3. Risk
assessment.
A preliminary risk assessment.
A list of the primary identified risk.
Plans for mitigation or eliminating the identified
risk.
2. Planning
phase.
The team determines what to develop, and how to create
the solution.
Functional specifications, create the design of the
solution, and prepares plans, cost estimates, and schedules for the various
deliverables.
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 stages.
Three total.
1. Conceptual
design. You the problem from the
perspective of the users and business.
Define the problem and solution in terms of usage scenarios.
2. Logical
design. You view the solution from
the perspective of the project team, and define the solution as a set of
services.
3. Physical
design. You view the solution from
the perspective of the developers.
Defining technologies, component interfaces, and services of the
solution.
The functional specification describes the behavior in
appearance of each feature of the solution. It describes the architecture and design for all features.
Design process.
The team performs a following key tasks during the
planning phase.
1. Developing
the solution design and architecture.
Identify the business requirements, user requirements, and
technologies in the use of this information to design a proposed
application model.
2. Create the
functional specification. This
describes the requirements that must be met by the solution.
3. Developing
project plans. Consolidate the
plans into a master project plan.
The master project plan includes the approach, dependencies, and
assumptions for the solution.
4. Creating
project schedules. Creation of the
master project schedule. Consists
of milestone based schedules for each of the team roles in the project
team.
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
follows.
1. Technology
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.
2. Functional
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
solution.
3. 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.
4. Master
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.
5. Development
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
phase.
1. Functional
specification.
2. Risk
management plan.
3. Master
project planning master project schedule.
3. Developing
phase.
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.
Development process.
The following key tasks are.
1. Starting the
development cycle. The verification
that all tasks during the envisioning and planning phase's has been
completed.
2. Creating a
prototype application. Verification
of the concept. This environment is
as similar as possible to the production environment. Now actual developing occurs.
3. Developing
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
the solution.
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
process.
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.
2. Internal
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.
2. Installation
scripts in configuration settings for deployment.
3. Finalized
functional specifications.
4. Performance
support elements.
5. Test
specifications and test cases.
4. Stabilizing
phase.
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
release.
All features are complete, all quality levels are
met. The solution is ready for
deployment.
Stabilization process.
Key tasks.
This is after the solution is considered stable.
Two categories.
1. Testing the
solution.
2. Conducting a
pilot. Deployment of the solution
in the staging area and testing of the solution with actual users and real
usage scenarios.
1. Testing the
solution.
The pilot is conducted a test environment, a rigorous
test includes.
1. Component
testing.
2. Database
testing.
3.
Infrastructure testing.
4. Security
testing.
5. Integration
testing.
6. User
acceptance in usability testing.
7. Stress,
capacity and performance testing.
8. Regression
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
usage scenarios.
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.
Interim milestones.
1. Bug
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
release.
3. Release candidates.
4. Golden
release combination of zero of the effects and success criteria matrix
matrics.
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.
1. Final
release.
2. Release
notes.
3. Performance
support elements.
4. Test results
in testing tools.
5. Source code
in executable files.
6. Project
documents.
7. Milestone
review.
5. Deploying
stage.
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.
Deployment process.
Following key tasks.
1. Completion
of deployment in operations procedures.
Formal documentation of deployment operational procedures outline
how the project team intends to perform deployment in transition task.
2. Deployment
and stabilization. Completion of
the actual component and site deployment's.
3. Project
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.
1. Core
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.
2. Site
deployments complete. At this
point, all intended users must be able to access the solution.
Lead developers must confirm that their sites are
operating.
This milestone might not be applicable for project to
do not include clients side deployment.
3. 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
and resolved.
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
this time.
4. Deployment
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
complete.
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
finality.
Deploying phase deliverables.
1. Operations
and support information systems.
A. Procedures and processes.
B.
knowledge base, reports, and logbooks.
2. Documentation
repository for all versions of documents and code developed during the
project.
3. A training
plan.
4. Project
completion report.
A.
final versions of all project documents.
B.
customer satisfaction data.
C.
definition of next steps.
Lesson 3, introducing a case study, adventure work
cycle applications.
Next
session will be place here………………………..thanks. lance
Lesson
3: Introducing the Case Study—Adventure Works Cycles Application
Summary
Review
CHAPTER 2 Gathering and
Analyzing Information
Lesson
1: Gathering Information
Lesson
2: Analyzing Information
Lesson
3: Using Modeling Notations
Lesson
4: Creating Use Cases and Usage Scenarios
Activity:
Gathering and Analyzing Information
Summary
Review
CHAPTER 3 Envisioning the
Solution
Lesson
1: The Envisioning Phase
Lesson
2: Creating a Vision/Scope Document
Lesson
3: Creating the Project Structure Document
Lesson
4: Analyzing Risks
Activity:
Developing a Vision/Scope Document
Summary
Review
CHAPTER 4 Creating the
Conceptual Design
Lesson
1: An Introduction to the Planning Phase
Lesson
2: An Overview of the Functional Specification
Lesson
3: An Overview of the Conceptual Design Process
Lesson
4: Building the Conceptual Design
Lesson
5: Optimizing the Conceptual Design
Activity:
Analyzing Requirements
Summary
Review
CHAPTER 5 Creating the
Logical Design
Lesson
1: An Overview of Logical Design
Lesson
2: Creating a Logical Design
Lesson
3: Documenting Logical Design Output
Lesson
4: Optimizing Logical Design
Activity:
Identifying Objects for the Logical Design
Summary
Review
CHAPTER 6 Creating the
Physical Design
Lesson
1: An Overview of Physical Design
Lesson
2: Physical Design Analysis
Lesson
3: Physical Design Rationalization
Lesson
4: Physical Design Implementation
Activity:
Working on the Physical Design
Summary
Review
CHAPTER 7 Designing the
Presentation Layer
Lesson
1: Basics of User Interface Design
Lesson
2: Designing the User Interface
Lesson
3: Designing User Process Components
Activity:
Creating the User Interface
Summary
Review
CHAPTER 8 Designing the
Data Layer
Lesson
1: Designing the Data Store
Lesson
2: Optimizing Data Access
Lesson
3: Implementing Data Validation
Activity:
Creating a Data Schema
Summary
Review
CHAPTER 9 Designing
Security Specifications
Lesson
1: Overview of Security in Application Development
Lesson
2: Planning for Application Security
Lesson
3: Using .NET Framework Security Features
Lesson
4: Designing Authorization, Authentication, and Auditing Strategies
Activity:
Threat Modeling and Mitigation
Summary
Review
CHAPTER 10 Completing the
Planning Phase
Lesson
1: Incorporating Design Considerations
Lesson
2: Planning for Administrative Features
Lesson
3: Planning for Future Phases
Lesson
4: Creating the Technical Specification
Activity:
Reviewing a Test Plan and Technical Specification
Summary
Review
CHAPTER 11 Stabilizing and
Deploying the Solution
Lesson
1: The MSF Stabilizing Phase
Lesson
2: Testing and Piloting for Stabilization
Lesson
3: The MSF Deploying Phase
Lesson
4: Deploying to a Production Environment
Activity:
Prioritizing Bugs
Summary
Review
APPENDIX A Questions and
Answers
GLOSSARY
INDEX
|