Homes
Content
Homework Title/No.: 2 Course Tutor: Mrs. Amandeep Date of Allotment: Student’s Roll No.: B38
Course Code: CAP 412
Date of Submission: Section No.: D3801
Declaration I declare that this assignment is my individual work. I have not copied from any other student’s work or from any other source except where due acknowledgment is made explicitly in the text, nor has any part been written for me by another person. Student Signature: DIPTI MITTAL Marks Obtained: Out of:
PART A Q1:-What is the difference between waterfall model, iterative waterfall model, prototyping model and spiral model? Ans: - the difference between waterfall model, iterative waterfall model, prototyping model and spiral model are:Water fall Model: when the customer requirements are clear and complete. Good when requirements are well understood and have low technical risk.
Prototype Model: when the customer requirements are not clear ambiguous or our project team is following this model with sample first.
But iterative waterfall models give us more flexibility through giving chance to revisit early phases.
Spiral model is an adaptive model. When the requirements of the customer are enhausing. This is an adaptive SDLC that cycle over and over again through development activities until project is complete. Here we go through some major steps, 1. Plan 2. Analyze and Design 3. Construct prototype 4. Test and integrate these steps iterate till completion of the project.
Q2:-what is step wise project planning? Draw a diagram for an overview of stepwise planning. Ans: - Step Wise covers only the planning stages of a project and not monitoring and control. In order to illustrate the Step Wise approach and how it might have to be adapted to deal with different circumstances, two parallel examples are used.
Let us assume that there are two former Computing and Information Systems students who now have several years of software development experience under their belts.
Q3:-What incentive is there for the team to go through the task of creating a WBS? It looks like a lot of work and some of them won't see why it needs their involvement. Ans:-An important motive for creating Work Breakdown Structures is giving the team members responsible for doing the work some confidence that management understands the true scope of that work. Who wants to commit to a project timeline only to find out later that the work was misunderstood and grossly underestimated? The WBS can actually be used as a crucial component of protecting team morale. There is nothing worse for team members starting a project than the sinking feeling that once again their management does not understand the work at the team members' level. Once again, management will set incorrect expectations based on a coarse and insufficient understanding of
what actually has to get done at the team members' desks and benches. Once again, management will ask them to do the impossible. Work breakdown structures are simply a way of organizing the work activities necessary to implement the project into a numbered outline form. One of the best advantages that then come from that is a way to provide traceability from then on throughout your project between requirements, project plans, test cases, issue logs, etc. This helps ensure nothing is lost in the cracks. Notice I said traceability between requirements and implementation work in the WBS. That’s an important distinction to make.
PART B Q1:-how the waterfall model and prototyping model can be accommodated in the spiral process model? Ans: - The waterfall model gives us prototyping, and spiral model gives us product, so the set of the waterfall accommodate in the spiral to gives us this product. The waterfall model is accommodated where there is a low specification risk and no need for prototyping etc. for risk resolution. The activities in the 2nd quadrant of the spiral model are skipped. The prototyping model is accommodated when the specification phase is limited and the prototyping phase predominates. The activities in the 3rd quadrant of the spiral model are skipped or reduced in scope. 1. Spiral model can be accommodating in prototyping and waterfall model. It is a model of iterative process as prototyping and also a systematic approach to solve a problem as in waterfall model. 2. Spiral model take problem as a series of step to solve a problem as in waterfall, and take the contribution of users or customers in each phase as in prototyping model. Q2:- How much detail and how many levels should my work breakdown structure go to and how do I know if I'm done?
Ans:-The general answer to this question is to go far enough down in levels and details to be sure your schedule estimates will have a good degree of accuracy. One rule of thumb is to take the WBS down to activity blocks of no more than 2-weeks' duration. But the level of detail, and what constitutes the right degree of accuracy, is ultimately a judgment call for the project manager. There are five common pitfalls to creating a WBS:1. Level of Work Package Detail When deciding how specific and detailed to make your work packages, you must be careful to not get too detailed. This will lead to the project manager to have to micromanage the project and eventually slow down project progress. On the other hand, work packages whose details are too broad or large become impossible for the project manager to manage as a whole. 2. Deliverables Not Activities or Tasks The WBS should contain a list of broken down deliverables. In other words, what the customer/stakeholder will get when the project is complete. It is NOT a list of specific activities and tasks used to accomplish the deliverables. How the work is completed (tasks and activities) can vary and change throughout the project, but deliverables cannot without a change request, so you do not want to list activities and tasks in the WBS. 3. WBS is not a Plan or Schedule The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables. 4. WBS Updates Require Change Control The WBS is a formal project document, and any changes to it require the use of the project change control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep. 5. WBS is not an Organisational Hierarchy The WBS and Organizational Hierarchy chart is never the same thing. Although often similar in appearance, these two documents are very different. The Organizational Hierarchy shows things like chain of command and lines of
communication, but the WBS is restricted simply to a project and shows only the deliverables and scope of that project. We hope that this article has helped you better understand the Work Breakdown Structure's purpose, process, and common pitfalls. The WBS is an extremely valuable tool to the project management methodology. It can make or break a project. It sets the foundation for the rest of the project planning. A solid WBS helps ensure proper project baselines, estimating, resource use, scheduling, risk analysis, and procurement. Q3 Write brief note on the following i) Risk planning ii) Risk management Risk management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attacks from an adversary. Several risk management standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards. Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety. Risk management should:
• • • • • • •
create value be an integral part of organizational processes be part of decision making explicitly address uncertainty be systematic and structured be based on the best available information be tailored
For example:
Risk management is applied inconsistently Even when potential risk events are identified for a project, this process typically occurs early in the project and is never revisited. As a result, the project team may not be prepared to respond to new uncertainties and issues that have not been identified. 2. Risk management is not prioritised The risk planning, analysis, and response planning efforts are rarely integrated into the overall project plan. As a result, risk management is not a priority for the project team, and adequate resources (budget and people) are not allocated to address issues caused by risk events. This "we will deal with those events if and when they occur" mentality leaves little or no room for error on the project. 3. Risk management earns limited buy-in and support In many cases, project sponsors and senior management discount risk management efforts for their projects because the benefits are unclear. Additionally, senior management, hearing the phrase risk management, might say, "We have a group that handles our risk management, so why do we need to have a separate effort on the project. Plus, we are not reducing project costs or delivery time so why should we invest in risk management?" As you have likely discovered, the challenges present in project risk management are just another element to worry about as a project leader. There are three basic tenets you can incorporate that can turn your risk management efforts into a consistent and proactive process 1. Risk planning: Creating the risk management plan for a project
The project risk management plan is a formal document used to initiate and control the risk management process and required for identifying, analyzing, and mitigating risks and threats to current project. The project risk management plan determines actions and activities to plan risk responses and monitor the project. The idea of the project risk management plan is to help project participants obtain better project results in terms of time, cost, scope and performance. Successful implementation and realization of the project risk management plan results in the following:
• • • •
Improved planning, prioritization and decision making. More efficient allocation of both human and financial resources. Minimization of unexpected outcomes and prevention of serious financial losses. Increased probability of successful project plan realization considering time, scope and cost.
The project risk management plan is a mix of all the plans developed on earlier stages of a project. To create such a plan, the project manager together with the project team needs to use the project scope statement, the cost management plan, the schedule management plan, and the communications management plan. By means of group meetings and discussions, the project manager collects, filters out, and analyzes information in order to build the project risk management plan considering existing environmental factors. The project team helps collect and analyze necessary information. One of the most effective ways to address and manage risks is to develop and implement risk management standards that provide guidance on reducing the impact of usual and extreme risk events. If a project comes up on a regular basis, the project manager can use risk management standards.
Course Code: CAP 412
Date of Submission: Section No.: D3801
Declaration I declare that this assignment is my individual work. I have not copied from any other student’s work or from any other source except where due acknowledgment is made explicitly in the text, nor has any part been written for me by another person. Student Signature: DIPTI MITTAL Marks Obtained: Out of:
PART A Q1:-What is the difference between waterfall model, iterative waterfall model, prototyping model and spiral model? Ans: - the difference between waterfall model, iterative waterfall model, prototyping model and spiral model are:Water fall Model: when the customer requirements are clear and complete. Good when requirements are well understood and have low technical risk.
Prototype Model: when the customer requirements are not clear ambiguous or our project team is following this model with sample first.
But iterative waterfall models give us more flexibility through giving chance to revisit early phases.
Spiral model is an adaptive model. When the requirements of the customer are enhausing. This is an adaptive SDLC that cycle over and over again through development activities until project is complete. Here we go through some major steps, 1. Plan 2. Analyze and Design 3. Construct prototype 4. Test and integrate these steps iterate till completion of the project.
Q2:-what is step wise project planning? Draw a diagram for an overview of stepwise planning. Ans: - Step Wise covers only the planning stages of a project and not monitoring and control. In order to illustrate the Step Wise approach and how it might have to be adapted to deal with different circumstances, two parallel examples are used.
Let us assume that there are two former Computing and Information Systems students who now have several years of software development experience under their belts.
Q3:-What incentive is there for the team to go through the task of creating a WBS? It looks like a lot of work and some of them won't see why it needs their involvement. Ans:-An important motive for creating Work Breakdown Structures is giving the team members responsible for doing the work some confidence that management understands the true scope of that work. Who wants to commit to a project timeline only to find out later that the work was misunderstood and grossly underestimated? The WBS can actually be used as a crucial component of protecting team morale. There is nothing worse for team members starting a project than the sinking feeling that once again their management does not understand the work at the team members' level. Once again, management will set incorrect expectations based on a coarse and insufficient understanding of
what actually has to get done at the team members' desks and benches. Once again, management will ask them to do the impossible. Work breakdown structures are simply a way of organizing the work activities necessary to implement the project into a numbered outline form. One of the best advantages that then come from that is a way to provide traceability from then on throughout your project between requirements, project plans, test cases, issue logs, etc. This helps ensure nothing is lost in the cracks. Notice I said traceability between requirements and implementation work in the WBS. That’s an important distinction to make.
PART B Q1:-how the waterfall model and prototyping model can be accommodated in the spiral process model? Ans: - The waterfall model gives us prototyping, and spiral model gives us product, so the set of the waterfall accommodate in the spiral to gives us this product. The waterfall model is accommodated where there is a low specification risk and no need for prototyping etc. for risk resolution. The activities in the 2nd quadrant of the spiral model are skipped. The prototyping model is accommodated when the specification phase is limited and the prototyping phase predominates. The activities in the 3rd quadrant of the spiral model are skipped or reduced in scope. 1. Spiral model can be accommodating in prototyping and waterfall model. It is a model of iterative process as prototyping and also a systematic approach to solve a problem as in waterfall model. 2. Spiral model take problem as a series of step to solve a problem as in waterfall, and take the contribution of users or customers in each phase as in prototyping model. Q2:- How much detail and how many levels should my work breakdown structure go to and how do I know if I'm done?
Ans:-The general answer to this question is to go far enough down in levels and details to be sure your schedule estimates will have a good degree of accuracy. One rule of thumb is to take the WBS down to activity blocks of no more than 2-weeks' duration. But the level of detail, and what constitutes the right degree of accuracy, is ultimately a judgment call for the project manager. There are five common pitfalls to creating a WBS:1. Level of Work Package Detail When deciding how specific and detailed to make your work packages, you must be careful to not get too detailed. This will lead to the project manager to have to micromanage the project and eventually slow down project progress. On the other hand, work packages whose details are too broad or large become impossible for the project manager to manage as a whole. 2. Deliverables Not Activities or Tasks The WBS should contain a list of broken down deliverables. In other words, what the customer/stakeholder will get when the project is complete. It is NOT a list of specific activities and tasks used to accomplish the deliverables. How the work is completed (tasks and activities) can vary and change throughout the project, but deliverables cannot without a change request, so you do not want to list activities and tasks in the WBS. 3. WBS is not a Plan or Schedule The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables. 4. WBS Updates Require Change Control The WBS is a formal project document, and any changes to it require the use of the project change control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep. 5. WBS is not an Organisational Hierarchy The WBS and Organizational Hierarchy chart is never the same thing. Although often similar in appearance, these two documents are very different. The Organizational Hierarchy shows things like chain of command and lines of
communication, but the WBS is restricted simply to a project and shows only the deliverables and scope of that project. We hope that this article has helped you better understand the Work Breakdown Structure's purpose, process, and common pitfalls. The WBS is an extremely valuable tool to the project management methodology. It can make or break a project. It sets the foundation for the rest of the project planning. A solid WBS helps ensure proper project baselines, estimating, resource use, scheduling, risk analysis, and procurement. Q3 Write brief note on the following i) Risk planning ii) Risk management Risk management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attacks from an adversary. Several risk management standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards. Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety. Risk management should:
• • • • • • •
create value be an integral part of organizational processes be part of decision making explicitly address uncertainty be systematic and structured be based on the best available information be tailored
For example:
Risk management is applied inconsistently Even when potential risk events are identified for a project, this process typically occurs early in the project and is never revisited. As a result, the project team may not be prepared to respond to new uncertainties and issues that have not been identified. 2. Risk management is not prioritised The risk planning, analysis, and response planning efforts are rarely integrated into the overall project plan. As a result, risk management is not a priority for the project team, and adequate resources (budget and people) are not allocated to address issues caused by risk events. This "we will deal with those events if and when they occur" mentality leaves little or no room for error on the project. 3. Risk management earns limited buy-in and support In many cases, project sponsors and senior management discount risk management efforts for their projects because the benefits are unclear. Additionally, senior management, hearing the phrase risk management, might say, "We have a group that handles our risk management, so why do we need to have a separate effort on the project. Plus, we are not reducing project costs or delivery time so why should we invest in risk management?" As you have likely discovered, the challenges present in project risk management are just another element to worry about as a project leader. There are three basic tenets you can incorporate that can turn your risk management efforts into a consistent and proactive process 1. Risk planning: Creating the risk management plan for a project
The project risk management plan is a formal document used to initiate and control the risk management process and required for identifying, analyzing, and mitigating risks and threats to current project. The project risk management plan determines actions and activities to plan risk responses and monitor the project. The idea of the project risk management plan is to help project participants obtain better project results in terms of time, cost, scope and performance. Successful implementation and realization of the project risk management plan results in the following:
• • • •
Improved planning, prioritization and decision making. More efficient allocation of both human and financial resources. Minimization of unexpected outcomes and prevention of serious financial losses. Increased probability of successful project plan realization considering time, scope and cost.
The project risk management plan is a mix of all the plans developed on earlier stages of a project. To create such a plan, the project manager together with the project team needs to use the project scope statement, the cost management plan, the schedule management plan, and the communications management plan. By means of group meetings and discussions, the project manager collects, filters out, and analyzes information in order to build the project risk management plan considering existing environmental factors. The project team helps collect and analyze necessary information. One of the most effective ways to address and manage risks is to develop and implement risk management standards that provide guidance on reducing the impact of usual and extreme risk events. If a project comes up on a regular basis, the project manager can use risk management standards.
