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:
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
Tasks during planning phase:
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
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:
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:
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:
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:
The conceptual design process involves the following steps:
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:-
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:
over the period of time.
It is a 4 step process in case of big projects
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:
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:
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.
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.