Bottom up estimating [Technique]
A method of estimating a component of work. The work is decomposed into more detail. An estimate is prepared of what is needed to meet the requirements of each of the lower, more detailed pieces of work, and these estimated are then aggregated into a total quantity for the component of work. The accuracy of bottom up estimating is driven by the size and complexity of the work identified at the lower levels
Friday, June 13, 2008
Project managment
What is Analogous Estimation?
An estimating technique that uses the values of parameters, such as scope, cost, budget and duration or measures of scale such as size , weight , and complexity from a previous, similar activity as the basis for estimating the same parameter or measure for a future activity. It is frequently used to estimate a parameter when there is a limited amount of detailed information about the project. Analogous estimating is form of Expert judgment. Analogous estimating is the most reliable when the previous activities are similar in fact and not just in appearance and the project team members preparing the estimates have the needed expertise
An estimating technique that uses the values of parameters, such as scope, cost, budget and duration or measures of scale such as size , weight , and complexity from a previous, similar activity as the basis for estimating the same parameter or measure for a future activity. It is frequently used to estimate a parameter when there is a limited amount of detailed information about the project. Analogous estimating is form of Expert judgment. Analogous estimating is the most reliable when the previous activities are similar in fact and not just in appearance and the project team members preparing the estimates have the needed expertise
Thursday, June 12, 2008
Estimation Techniques
Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on a project. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.
Estimates can be roughly divided into three types:
Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.
Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.
Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.
Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.
Order of magnitude estimate
This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the best estimate we can provide.Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on.
Estimates can be roughly divided into three types:
Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.
Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.
Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.
Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.
Order of magnitude estimate
This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the best estimate we can provide.Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on.
Wednesday, June 11, 2008
Defect Finding Techniques
- Static techniques
–Deliverable is examined (manually or by a tool) for defects
–Examples: reviews, walkthroughs, inspections - Dynamic techniques
–A deliverable is used to discover defects
–Example: testing - Operational techniques
–An operational system contains a defect found by users, customers, or control personnel.
–Found as a result of a failure
What is Triple constraints in Project Managment
Scope, Time and cost together called as Triple constraint, A delta change in any of the three other two will have impact. ie: we have to revisit the other 2 factors for accomplishing the project with in dead lines and cost. if Qulaity is added to these constraints then it is known as Extended triple constraint
What is Project Management
Project Managment is the application of Knowledge, skills, tools and techniques to project activities to meet project requirments.Project managment in accomplished with the managment process of Initiation, planning, execution,, monitoring , Control and Closing.
Difference btw Project and operations
Project:
A project will be of temporary in nature, with a end date and will have a uniqueness.
operations:
Operations are which will occur on a periodicity basis[ Daily, monthly] for example railway reservations and bank day to day activities with computers are called operations
A project will be of temporary in nature, with a end date and will have a uniqueness.
operations:
Operations are which will occur on a periodicity basis[ Daily, monthly] for example railway reservations and bank day to day activities with computers are called operations
Subscribe to:
Posts (Atom)