Back to home Page

 

Email Lawson

 

Microsoft Certification Exam 70-300 Microsoft Solutions Framework

 

Summary………below,

Voice activation applied, sorry for any mistakes.


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

Table of Contents

 

CHAPTER 1 Introduction to Designing Business Solutions

     Lesson 1: overview of the Microsoft solutions framework.

     Lesson 2. Phases in the Microsoft solution framework      process model.  MSF.

     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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Back to home Page

 

Email Lawson