Top 50 Microsoft Solutions Framework (MSF) Interview Questions You Must Prepare 29.Mar.2024

An actor is anything that stands out of the system boundary that interacts with the system. An actor is used to define use cases and describe a system’s functionality along with its boundaries.

Every project has a huge number of potential unknowns which can act as barriers to the project. These can be termed as risks. Once a risk has occurred, it's no longer a risk but needs mitigation and a management plan. 

Risks are often assessed once in the initial planning phase and often forgotten. Contrary to this, risk management is and should be an ongoing process throughout the project. An effective approach is to assess risks continuously in use the information throughout the project.

Major risk management approaches include reactive and proactive risk management. Reactive risk management suggests, project members attend and react to the results of the occurrence of a risk as they occur. Proactive risk management on the contrary is all about having a proper managed process for handling risks proactively and managing them iteratively. The proactive risk management process has the following steps: Risk Identification, Risk analysis, Risk Action planning, Risk tracking, and Risk control.

Presentation layer is the lowest layer in any solution architecture. It is responsible for showing information to the end user which could be very different from what the system delivers otherwise. It includes formatting of information, string manipulations, i.e. the way end user would actually see/interact with information.

Microsoft follows daily builds for their projects. This process states that you compile every file and each one of them is combined to single executable program. These daily builds are then put through the smoke test. These daily builds catches the defects at early stages which avoids the problems with integration at later stages.

This is done in combination of daily builds and smoke test. Daily builds is a way for better root cause analysis of the problem because it’s easier to pinpoint the broken point in the product if it is tested on day to day basis than doing it once at the end of a module. Daily builds help in prioritizing tasks based on the risks. It improves the overall quality of the product. Also tracks the overall progress of the product.

Contents of risk management process:

Risk statements: It depicts a causal relationship a real and true project state, and a potential unrealized event. A risk statement has two parts: 

Condition: Provides the description of the project state that might cause a loss.

Consequence: Describes the harm or the loss that’s done by the condition.

Risk List: Is a tabular formatted data about various identified risks along with the root causes, condition and consequences of occurrence of the risk. 

Risk Exposure List: Once risks are identified, they are prioritized using product of 2 measures, likelihood of occurrence and impact of risk. This score is then used to prioritize the risks.

Master Risk List: This is an output of the risk analysis and provides details elated to the identified risks including project condition, context, cause, risk exposure metrics, owner etc.

Risk mitigation plan: This plan details the approach to reduce the likelihood for the risk to occur. Alternatively, mitigation pl may not be available in all projects and hence, contingency planning is used.

Contingency plan: Contingency planning describes alternative pl that must be executed in case efforts to prevent the risk causal event fail. Contingency plan consists of all risks including those that have a mitigation plan. It concentrates on how minimize the impact of the risk once it has occurred and thus become an issue. 

Risk Action forms: This details the implementation of the approach to be taken to handle specific risks. They are then integrated with the project plan and schedule. It enlists, the owners of the risk along with other specific details including risk statement, mitigation strategy, metrics, contingency strategy, risk plan responsibility etc.

Risk status reports: During risk tracking, progress towards the risk actions is monitored and updated continuously depicting the status of each risk.

During this phase it is determined by the team about what is to be developed, how to create a feasible solution for it. Functional specs are created based on the analyzed requirements. After the analysis a design is to be created to provide the solution to the project. Pl are created in order to make the design work. Time estimates, cost estimates and deliverables are all figured out in this phase.

Data is often partitioned to achieve better maintainability and accessibility. For example, in case of a data warehouse, partitioning can help in efficient and effective access to different database segments at different locations based on need. This helps in developing BI solutions which guide the management to better drive their business and achieve customer satisfaction. One could have many facts and dimension tables and perform slicing and dicing of information to achieve predictability or extract business rules. Data warehouses can be huge in volume which makes it necessary to partition data to achieve more robustness and better performance. Partitioning also enhances data availability which is important for critical data needed by some BI users often.

Tasks performed during planning phase:

  • Creation of functional specifications. 
  • Creation of the master plan about how do we go about in successful completion of the project.
  • Figure out the environment in which the product is to be deployed. 
  • Scheduling the tasks to achieve a functional product by the end. 
  • To get a sign-off from the stakeholders to ensure that the team is heading in the right direction before they actually start building the product.

  1. It acts as a repository of all the documents created for the project. So it provides a single reference to all documents. 
  2. It tells developer exactly what is to be built and deployed. 
  3. It describes the product behavior as seen by an external observer. 
  4. It is like a master plan.
  5. It helps to drive a shared vision of the project.
  6. It helps to keep the channels open for communication. 
  7. It ensures that the supplier understands the goals,specifications and expectations.
  8. It locks the scope of the project.
  9. It brings the customer in as a team member.
  10. It provides a basis for change orders later in the project.

Product Management: They are the customers for the team and drive project scope. They need to manage customer requirements and develop business case based on it. They act as a bridge between customer and team managing expectations and relationships. They also create the communication plan for the project.

Program Management: They are responsible to monitor and enforce schedule of the project along with facilitation of communication and negotiation with the team. They drive project schedule and report the status using the project master plan. They are also the owners of risk mitigation and management.

Development: Responsible for design specifications, and estimate time and effort needed for the project. They drive feature development and prepare the product for delivery along with providing technical expertise needed.

Test: Identify issues by testing. Create and plan a test strategy.

User Experience: They manage user requirements and develop performance support systems. They drive usability, performance and robustness of the system. Provide support manual, and are responsible for user training.

Release Management: Provide operation support and a channel for delivery. They are responsible for product deployment and releases.

The planning phase comes after vision and scope of the project has been finalized. Its main purpose is to plan a set of activities to achieve the project goals. It defines the whole conceptual solution in detail including the project schedule and plan.

The planning phase includes a set of major deliverables such as functional specification, preparing architecture and design documents, cost estimates and planning. The work breakdown structure is also prepared in this phase enlisting the major tasks and assigning them to various owners along with their times and cost estimates. This is a very detailed document which also includes details about deployment activities and deployment plan.

The master project plan integrates all these various documents in itself along with various milestones which must be met as per schedule.

Main goals of this phase are:

- Developing the solution design and architecture
- Validating the technology
- Creating the functional specification
- Developing the project pl
- Creating the project schedules
- Setting up the development and test environment
- Close the Planning Phase

  • It is a part that addresses what all is to be included in the product.
  • It discusses one or more alternative scenarios about the requirements in the product. 
  • The focus in conceptual design is the end user. 
  • It is mainly made from user’s perspective. 
  • It is used to execute an idea and then test it.
  • It is design based on the interactions, experiences processes and strategies and is the point at which people, knowledge, products, services, processes, and profitability meet vision and endless possibilities, each acting as a distinct colour on the canvass of the designer.

  1. They should cover both horizontals and verticals of the domains. They should cover all the functional areas.
  2. The user category should range from both IT to non-IT and from armatures to experienced users.
  3. All the members of the team must have accurate understanding of the users belonging to their profiles and should be well versed with their needs.

Tasks during planning phase:

  • Creation of functional specifications.
  • Creation of the master plan about how do we go about in successful completion of the project.
  • Figure out the environment in which the product is to be deployed.
  • Scheduling the tasks to achieve a functional product by the end.
  • To get a sign-off from the stakeholders to ensure that the team is heading in the right direction before they actually start building the product.

  • Functional specification is the summarization of various other documents like requirement document, design document. 
  • The main purpose of creating a functional specification is to provide a strong base on which every developer of the team builds the product.
  • It is a formal document which is used to describe in detail the software developers product intended capabilities, appearance and interaction with the uses.
  • It is a kind of guideline and reference point for the developers.
  • It contains formal descriptions of the user tasks, dependencies on other products and usability criteria.

The main purpose of envisioning phase is to identify the main need of the system to be created. i.e. identify the business problem to be solved. A set of tasks (deliverables) and milestones is created to depict a high level view of project’s goals, problems, and the solution. Some of the tasks can be

  • Set up team
  • Define project structure
  • Define business goals
  • Assess current situation
  • Create vision and define scope
  • Define high level requirements
  • Define user profiles
  • Define concept of the solution
  • Assess risk
  • Close phase

It is a tool to manage project trade-offs. This is kind of a signed agreement with the customer to find the priorities of the variables while making trade-off decisions. This matrix allows categorizing the variables into 3 sections: fixed, chosen, adjustable. Fixed constraints are unchangeable, chosen are desirable priorities and the adjustable ones are to keep a balanced for fixed and chosen ones.

The conceptual design tells about how the system must work. To do so, it is important to consider all the aspects related to the user and we must have a very strong understanding of the needs. The documentation is done to gather as much understanding as possible about the system. To gain a good understanding of the system, it is necessary to thoroughly reviews documents like business requirements, usage scenarios, system requirements etc.

A usage scenario is often customized to suit an organization’s needs. However, the following steps are a standard:

  • Assign a Unique Number to the usage scenario following a decided structure based on various modules/functionalities.
  • Provide a 1-2 line short description about what the usage scenario is for.
  • Mention Events that cause this usage scenario to occur.
  • Mention the steps of usage scenario that are detailed to a nominal level. These steps might also refer to other usage scenarios.
  • Mention a list of Post conditions that occur as a result of this usage scenario.
  • Mention a list of assumptions that are relevant.
  • Mention a list of any other related documents or usage scenarios.

The purpose f the vision statement is to have a mutual agreement between the customer and the team about the purpose of the project. This is to ensure that there would be no problems between the stakeholders in the basic understanding about why was the product needed and about the basic flow of the project.

The performance increases on optimizing tractions because:

  1. An optimized query targets the exact field data are needed. So the unnecessary fields are not fetched.
  2. Use of distinct command removes duplicate or redundant data without changing the actual data.

Waterfall Model: The task in one phase needs to be completed in order to move to the next phase. Waterfall model is beneficial only when the requirements are clearly defined and there are no chances for any changes in the requirements. It is easy to manage the progress of the project in terms of schedule, resources, and budget.

Spiral Model: This is most useful when the requirements are not clearly defined and there is a need of continuous refinement in the estimates. This is best suited for agile development of small projects. The changes take place on the basis of customers or other stakeholder’s feedback at all stages in the project. This might become chaotic and make it difficult to track progress.

This helps is ensuring that the product gets delivered within project constraints like the time frame, budget etc. In MSF the responsibilities of the project manager are enclosed in project manager role cluster.

A use case describes a usage scenario of a system. They are defined to understand system’s functionalities and design them better from an end user perspective. A usage scenario similarly is a short description of how someone might use a system to perform a specific function. They can be however, highly elaborative describing, pre conditions, post conditions, events, assumptions etc. They can be also broken down into further sub usage scenarios if needed.

This is most useful when the requirements are not clearly defined and there is a need of continuous refinement in the estimates. This is best suited for agile development of small projects. The changes take place on the basis of customers or other stakeholder’s feedback at all stages in the project. This might become chaotic and make it difficult to track progress.

Risk Management: It takes care of both proactive and continuous risk assessment. Risks for any system are regularly assessed, mitigation strategies are prepared until they don’t exist anymore or it has already occurred. Risk that has occurred is no more a risk. It becomes an issue. MSF gives certain steps to plan, create and execute mitigation strategies.

They are:

  • Identify the risk
  • Analyze the risk to prioritize them
  • Plan a schedule based on the priority
  • Track what is done to manage the risk didn't harm anything else and the risk has been taken care of. This status should be reported to the stakeholders from time to time.
  • Risk controlling strategy.
  • Note the lessons learnt from the risks that have been found out or even the ones which have become issues.

Readiness Management: It is a measure of current state versus the desired state. It is to track how much have we progressed over the period of time.

Phases of MSF process model:

Envisioning: This phase aims to create teams based on skills, experience, resources and budget. In this phase, we need to create the entire project structure, defining the goals, validations, vision and scope for the project. The definition of requirements, identification of stakeholders, risk assessment is all done here in this phase. This phase ends with a sign off from the stakeholders.

Planning: During this phase it is determined by the team about what is to be developed, how to create a feasible solution for it. Functional specs are created based on the analyzed requirements. After the analysis a design is to be created to provide the solution to the project. Pl are created in order to make the design work. Time estimates, cost estimates and deliverables are all figured out in this phase.

Developing: The created design is implemented in this phase by writing code. In this phase, it is verified that all the planned tasks, designs, specifications, requirements are implemented to achieve the desired result. This phase ends by making sure that all deliverables including the code are all handed over to the client.

Stabilizing: Various testing cycles like integration, load, and beta are done in this phase. The team is responsible for fixing up all the discovered issues in this phase. Issues are prioritized in order to stabilize the application. After this phase, the solution is ready for deployment.

Deploying:  The solution is deployed in this phase and is tested by the client for approval. Customer’s approval and feedback decides the end of the project.

Tasks during planning phase:

  • Creation of functional specifications.
  • Creation of the master plan about how do we go about in successful completion of the project.
  • Figure out the environment in which the product is to be deployed.
  • Scheduling the tasks to achieve a functional product by the end.
  • To get a sign-off from the stakeholders to ensure that the team is heading in the right direction before they actually start building the product.

The conceptual design process involves the following steps:

  1. Define a concept: statement of what the application is all about. What is in the scope and what is not? 
  2. Describe the end user and their needs: List of user categories who would access the system along with what tasks can they do and what they can't. 
  3. Prioritize the tasks based on the measurable objectives and validations.
  4. Design the object model. A list of all the features the user needs. 
  5. Design the task model: List of all the tasks that the user is allowed to perform and how are they to be performed.
  6. Evaluate end result of each phase against the objectives: Verify if we have achieved what we were supposed to or not. If not, then what is missing? This can be done through heuristic evaluation or usability testing.

Various testing cycles like integration, load, and beta are done in this phase. The team is responsible for fixing up all the discovered issues in this phase. Issues are prioritized in order to stabilize the application. After this phase, the solution is ready for deployment.

MSF risk management process follows the following steps:

Risk Identification: It is necessary to first identify the potential risks before we can decide about handling them.

Risk Analysis: The risks are assessed on the basis of likelihood of their occurrence and their impact.

Risk Action Planning: Actions to be taken to handle the risk after it has occurred, prioritizing these actions and coming up with a Master risk management plan.

Risk Tracking: Monitor the risks and the actions that are related to resolve them if risk has occurred.

Risk Control: Risk management merges with Project management to control risk actions and risk plan. Risk control must be done by integrating risk management with project management.

MSF team model is based on 6 roles:

a. Product Management: This team is responsible for identifying the requirement at business level. It also ensures that these needs are met from time to time. Goal of this team is to make sure that the customer is satisfied at all times.

b. Program Management: This team manages the budget, decides the timelines, identifies the risks, and tracks the reporting status for the project. Goal of the project management team is to ensure that the project delivery is made within the project constraints.

c. Development: This team is responsible for implementing the design and preparing the product for deployment. This team’s goal is to create a product based on the product specifications.

d. Release Management: This team tracks the releases based to ensure stability. It is responsible for successful deployment f the product. Efficient product deployment is the sole aim of this team.

e. User experience: This team makes sure that the product meets the user’s needs. It also collects and analyses user’s requirements and prioritizes them and creates the way with which user training is t be conducted. The goal of this team is to understand users better and enhance their performance by training them the correct way.

f. Testing: This team is responsible for product’s stability. They ensure that the major defects are fixed before launching the product into the production environment. They design and develop the test strategy. The aim of this team is to find all the issues before the release.

Benefits of a conceptual design are:-

  1. Helps to create a user interface which is easy to understand and interpret.
  2. Gives a clear idea of what the product can do, intended use.
  3. Considers the users points of view hence actual results are easier to achieve.
  4. Describes the roles of different users and their requirements.
  5. Reduces repetitive tasks.

The task in one phase needs to be completed in order to move to the next phase. Waterfall model is beneficial only when the requirements are clearly defined and there are no chances for any changes in the requirements. It is easy to manage the progress of the project in terms of schedule, resources, and budget.

Microsoft follows daily builds for their projects. This process states that you compile every file and each one of them is combined to single executable program. These daily builds are then put through the smoke test. These daily builds catches the defects at early stages which avoids the problems with integration at later stages. This is done in combination of daily builds and smoke test.

Daily builds is a way for better root cause analysis of the problem because it’s easier to pinpoint the broken point in the product if it is tested on day to day basis than doing it once at the end of a module. Daily builds help in prioritizing tasks based on the risks. It improves the overall quality of the product. Also tracks the overall progress of the product.

Test role is responsible to create test pl based on the high level decisions made about the interactions and integration of the components. This is done to ensure that the in future the testing will be done based on the plan. This ensures that no scenario is missed out.

The main purpose of specifying the project scope is to ensure a clear understanding of the business problem and the proposed solution. It is a must to give a clear understanding about the project and provide a direction. Its intention is to state what is going to be in the project and what is not going to be part of the project i.e. out of scope. It must clearly define a project boundary to minimize the expectation gap between the client and the team.

a. Shadowing: This is done by observing the user with the application. This is done by monitoring a user and noting down the problems and questions they face while working on it. This works properly only when team doesn’t give any input or information on his own, but only wers the asked questions.

b. Interviewing: Interviews are conversation between the team representative and the user. This can be an ad-hoc conversation or a planned one. User responses are recorded to attain the desired information. It takes too much of time as it is one on one interaction.

c. Focus Groups: It involves face-face interaction between the team representative and the user and between the users as well. It is a done in groups, normally of 6-10 people. The discussion amongst the users allows to brain storm the user requirements more clearly.

d. Surveys: It is a way to reach out to a wider audience. This is done by circulating set of simple questions to people for their feedback.

e. User instruction: It allows users to teach you the task that they perform. This way we can learn from user’s way of working and determine what are his/her needs in the new system.

f. Prototyping: It involves building a small model of the entire system that shows some basic functionality. It is done to get an acceptance from the stakeholders to continue with the system.

A basic functional specification should include the following:

  • A summary of the final singed off vision and scope document. It is needed so that the team knows why is the product being developed and what exactly is needed. 
  • Any additional user and customer requirements other than those that were identified in the vision and scope document. 
  • The solution design: This is done for the development team to understand how the architecture has been designed for the product by architecture people. 
  • The functional specification must explain all the functionalities of the solution under development. This is done so that it is clear to the team about what all functionalities have been decided by the stakeholders. 
  • Quantitative measures in terms of times, performance should be mentioned. 
  • The spec must have security requirements. The team needs to know what kind of security level is required in the product. 
  • Any legal requirement that has been decided by the stakeholders should be made clear to the team to avoid issues at later stages. 
  • It should contain the risks that have been analyzed and their impacts on the products. If any risk mitigation strategy has been decided then that should be mentioned as well. 

over the period of time.

It is a 4 step process in case of big projects

  1. Define
  2. Assess
  3. Change
  4. Evaluate

In case, of small projects, it’s enough to assess the skills and then make changes while training.

The purpose f the vision statement is to have a mutual agreement between the customer and the team about the purpose of the project. This is to ensure that there would be no problems between the stakeholders in the basic understanding about why was the product needed and about the basic flow of the project.

The solution is deployed in this phase and is tested by the client for approval. Customer’s approval and feedback decides the end of the project.

The main goal of conceptual design is to describe from end user’s and the organization’s perspective.

UML diagrams offers different views to various phases of SDLC. To understand UML as per different phases, they are often classified into different views:

  • Design/Structural view: This consists of various components of the system .i.e. class diagrams, objects diagrams.
  • Process view: This depicts the behavior of the systems with the help of state-trition diagrams, and sequence diagrams. 
  • Component/Implementation view: Depicts grouped modules of a system with the help of component diagrams.
  • Deployment view: Used to describe deployment modules of a system.
  • User view: Used to view the systems from the perspective of actors, describing functionality of it using use cases.

Projects are very dynamic in nature. This suggests that risks should be re-assessed and re-evaluated to update pl and schedules continuously. Risks should be assessed until they are resolved or turn into issues to be handled. Risks should be assessed using a Master risk list which has the following information for assessment:

  • Priority: Determined based on the Risk exposure.
  • Condition: The state of the project that causes the risk to occur.
  • Consequence: The result and the loss caused by the risk.
  • Probability: The likelihood of the risk occurring.
  • Impact: The effect of the risk.
  • Exposure: Product of Probability and impact.

Waterfall Model: The task in one phase needs to be completed in order to move to the next phase. Waterfall model is beneficial only when the requirements are clearly defined and there are no chances for any changes in the requirements. It is easy to manage the progress of the project in terms of schedule, resources, and budget.

Spiral Model: This is most useful when the requirements are not clearly defined and there is a need of continuous refinement in the estimates. This is best suited for agile development of small projects. The changes take place on the basis of customers or other stakeholder’s feedback at all stages in the project. This might become chaotic and make it difficult to track progress.

Databases indexes are used to improve the speed of operations on database tables. Indexes are created using one or more fields of a table. Indexes take lesser space than the actual tables, however as a result increasing data availability and database operations performance. Once can even create indexes on functions.

Absence of index needs a query to scan through every record of a table to match and retrieve relevant records, whereas, with the help of indexes, the computational cost for providing the same result can be much lesser based on the indexing technique used, e.g.: Balanced trees, B+ trees and hashes.

This phase aims to create teams based on skills, experience, resources and budget. In this phase, we need to create the entire project structure, defining the goals, validations, vision and scope for the project. The definition of requirements, identification of stakeholders, risk assessment is all done here in this phase. This phase ends with a sign off from the stakeholders.

  • Developer might not have a clear picture. 
  • Developer might get confused with the redundant statements in different documents. 
  • Not having a functional specification might result in inefficiency. 
  • Developers might not think of all the situations at once, which might lead to delay in development at future stages.

Low-fidelity design is more like a sketch on a paper or whiteboard. It is mainly used to review the workflow of the system. It is a high-level design of the system.

High-fidelity design is made using proper design tools. It is used t overview all the detailed functionalities. It is the low-level design of the system.