importance of resources allocation in formal method of software engineering ? & 2 What are the software risk issue?
Download as DOCX, PDF0 likes76 views
This document discusses key concepts related to project management including resource allocation, software risks, differences between products and projects, discount factors, net present value, and net profit. The main points are: 1) Resource allocation in project management is important for planning, scheduling, and controlling workload to improve team effectiveness. It involves identifying and tracking resources like budget, tools, and time. 2) The top five software risks are inherent schedule flaws, requirements inflation, employee turnover, specification breakdown, and poor productivity. Agile methods aim to mitigate these risks through practices like iterative planning and prioritization. 3) The key difference between a product and project is that a product is manufactured and sold while a project is built to
importance of resources allocation in formal method of software engineering ? & 2 What are the software risk issue?
- 1. 1 Importance of resources allocation in formal method of software engineering Project management is a very wide area of work, particularly in business. It covers many different topics which can be broken into even smaller particles. Work of a project manager is not only about giving people orders and telling them what to do. Many people limit their work of a project manager to supervising their employees and making sure everyone meets their deadline. But a good project manager knows it’s more than that. Resource allocation in project management is one of those particles which make work of a good PM effective and significant. And even though it may seem simple, it is actually crucial in delivering a great project. Resource allocation in project management is concerned with creating a plan which can help achieve future goals. There are many resources which have to be allocated when managing a project, beginning from budget to equipment and tools, to data and the project’s plan. How To Allocate Resources Resource allocation in project management is so important because it gives a clear picture on the amount of work that has to be done. It also helps to schedule ahead and have an insight into the team’s progress, including allocating the right amount of time to everyone on the team. Resource allocation allows to plan and prepare for the project’s implementation or achieving goals. It is also possible to analyze existing threats and risks to the project. But above all, resource allocation in project management helps to control all the workload. This, as a result, contributes to team’s effectiveness at work and what follows later is a satisfying and exhaustive project. Since resources refer to quite an extensive list of things and aspects of project management, it may be confusing when trying to properly allocate them all. But it’s not difficult and requires certain dedication and involvement. Here’s what you can do to allocate resources in the right way when managing a project: know the scope – to know what is your project about, what you will need to achieve it, and to be able to properly allocate resources; identify resources – to know which tools, equipment, etc. you will need it completing the project; track time – to have a deep analysis of the progress and current situation as well as be able to control it in the real-time; don’t look only at the big picture – the process of working on a project is not done with task allocation. Once youallocate resourcesyouhaveto keeptrack ofall of them. If you lose at least one tiny detail, your project may fail; don’t over-allocate – because your team will experience burnout and their productivity will significantly drop.
- 2. 2 What are the software risk issue? SOFTWARE RIKS ISSUE THE TOP FIVE SOFTWARE PROJECT RISKS Risk management (or more precisely risk avoidance) is a critical topic, but one that is often dull to read about and therefore neglected. One of the few useful and entertaining books on the subject is Waltzing with Bears: Managing Risk on Software Projects by Tom Demarco, Timothy Lister, authors of the ever popular Peopleware. This post provides a useful summary of their top five software project risks. While not an agile focused book, I find it interesting that of the top five software project risks identified in Waltzing with Bears, all have suggested solutions rooted in agile methods. Demarco and Lister rate the top five risks and their mitigation strategies as: Risk 1: Inherent Schedule Flaws Explanation: Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule. Waltzing…Solution: Get the team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders. Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP's planning game and Wideband Delphi workshops.Byworking in shortincrements, thetrue velocity ofthe team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, the true progress is hard to hide and quickly revealed, giving feedback to the stakeholders. Risk 2: Requirements Inflation Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines. Waltzing…Solution: Constant involvement of customers and developers. Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilizing change-suppression mechanisms, prioritization sessions are scheduled that allow worthwhile changes to
- 3. proceed and initially envisioned features to be superseded if the business gives their authorization. It has never been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages. Risk 3: Employee Turnover Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project. Waltzing…Solution: Increased collaboration and information sharing on the team. Agile Practice: Agile projects practice information sharing techniques such as pair programming, common code ownership, and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small. Also, often overlooked, is the fact that when working in an engaging, rewarding, empowered, collaborative environment such as agile projects, people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced. Risk 4: Specification Breakdown Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements. Waltzing…Solution: Use a dedicated Product Manager to make critical trade off decisions. Agile Practice: Agile projects utilise the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions ontheproject. Traditional projectssufferspecification breakdownwhen no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion. Risk 5: Poor Productivity Explanation: Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained.
- 4. Waltzing…Solution: Short iterations, right people on team, coaching and team development. Agile Practice: Agile methods recognise Parkinson's Law and the Student Syndrome apply to software projects. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly here before starting work." By having short iterations, work is time- boxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on team, coaching and team development, but these are core leadership roles applicable to both agile and traditional projects. On Agile Solutions It should really be no surprise that agile methods have techniques built right into them to address each of the top software project risks. They were created out of the experience ofwhat worked well forpractical software development.Given that these problemsoccur time and time again on software projects it is natural that their solutions should become baked into the DNA of agile methods.
- 5. 3 Product vs Project || Definition, Differences & Risks Involved What is a Product? The product is like ‘manufactured or ready to use’ which is developed by the company and sold to different consumers (or) setup as open source.If a customer requires any amendments to color, title, these changes, and some extra functionality to be added, then customization is done to the product. General Example: Purchasing a flat after construction is completed – In this case, You can only do minor changes like paints and interiors. Industry Ex: Google products like Gmail, and Oracle products like Databases etc, Finacle by Infosys, Office 365 by Microsoft… What is a Project: The project is ‘taking a wish from customer to build a solution’. The requirements are gathered from a particular client outside the company. General e.g.: Purchasing a flat before construction. You can construct it as per your need and wish. Industry e.g: Indian Railways Project by TCS (including Broadvision and CRIS), Crosscues Project by Navyug, etc. Some difference b/w Product and Projects: Product Risks: The risk involved in software or system, the possibility that software or system may fail to satisfy end user/consumers expectations is known as product risk. There may be the possibility that the software or system does not have the functionality specified by the customer or the stakeholders which leads to unsatisfactory software. The low-quality software can have many problems like functionality, reliability, usability or performance. Examples of Product Risks are: Complex features affecting multiple areas of the existing product, like an upgrade/migration of the system. New Technologies used in the product; for example, a new DB server, a new programming language, a new integration, etc. New Developers or Development Teams, who may lack experience and thus pose a higher risk to the existing product.
- 6. Tight Schedules, that make people work in a rush and commit more mistakes. Project Risks: Risks associated with the testing activity which can endanger the test project cycle is known as a project risk. In order to deal with project risks, we need to apply concepts like identifying, prioritizing and managing the project risks. Examples of Project risks are: Delay in the test build to test team. Unavailability of the test environment. Delay in fixing test environment due to lack of system admin. Delay in fixing defects by the development team. Organizational problems which can be like shortage of staff. Required skills etc. Major changes in the SRS which invalidate the test cases and requires changes in the test case. As testers, one of our tasks is to manage Product Risks. We are paid (at least in part) to be aware of all Product Risks, to make sure the rest of the project team is also aware of them, and to coordinate this information with Project Management to make sure our schedules are taking these risks into account. In addition, we are expected to plan our testing strategy based on these risk, scheduling more tests (and earlier tests) on areas with higher risks in order to find these issues faster. Most of the task related to Risk Management is not complex but they require a good understanding of the project and product as well as the strict discipline required to keep following and managing these risks throughout the whole lifecycle of the project. Discount Factor he discount factor of a company is the rate of return that a capital expenditure project must meet to be accepted. It is used to calculate the net present value of future cash flows from a project and to compare this amount to the initial investment. The discount factor used in this calculation is the company's weighted average cost of capital. Calculation of Weighted Average Cost of Capital A company's weighted average cost of capital is made up of the firm's interest cost of debt and the shareholders' required return on equity capital. Consider the following data from the balance sheet of the Hasty Rabbit Corporation: Total amount of long-term debt: $200,000 Interest on long-term debt: 5 percent Total amount of equity capital: $300,000 Stockholders' required return on capital: 11 percent Percentage of long-term debt: $200,000/($200,000 + $300,000) = 40 percent Percentage of equity capital: $300,000/($200,000 + $300,000) = 60 percent
- 7. Weighted average cost of capital = 40 percent x 5 percent + 60 percent x 11 percent = 8.6 percent The company will use 8.6 percent as its discount factor in the net present value method to evaluate projects. NPV (Net Present Value) The difference between the present value of the future cash flows from an investment and the amount of investment. Present value of the expected cash flows is computed by discounting them at the required rate of return. For example, an investment of $1,000 today at 10 percent will yield $1,100 at the end of the year; therefore, the present value of $1,100 at the desired rate of return (10 percent) is $1,000. The amount of investment ($1,000 in this example) is deducted from this figure to arrive at net present value which here is zero ($1,000-$1,000). A zero net present value means the project repays original investment plus the required rate of return. A positive net present value means a better return, and a negative net present value means a worse return, than the return from zero net present value. It is one of the two discounted cash flow techniques (the other is internal rate of return) used in comparative appraisal of investment proposals where the flow of income varies over time. Net Profit Net profit, also called net earnings, net income and informally ‘the bottom line’, is calculated by adding up a business’ total expenses, and subtracting that from its revenue – this shows what the company has either earned or lost over a specific accounting period, which could be one month, one quarter, six months, or one year. The net profit of a company, organization or any individual or entity that does business, is its profit after operating expenses and all other charges including depreciation, interest, and taxes have been deducted from total revenue. If total expenses and charges are greater than revenue, the business incurs a net loss, if expenses and charges are less than total revenue, it has made a net profit. Expenses are what the company spends.