cost estimator | can estimate time by making 3 separate estimates - optimistic, likely and pessimistic - to come up with a global estimates of the best-case, typical case and worst-case cost for the project | |
can use cost estimation technique | |
is a subtopic of 11.3 - Cost Estimation | |
is a kind of software developer | |
makes inaccurate estimate if he or she tries to estimate the entire cost of a project as a single number | |
may underestimate the total amount of work required by not understanding the amount of work involved in certain activities or omitting them entirely | |
must include extra time into a time estimate to account for typical delays | |
should avoid making only a best-case estimate | |
should compare the results of several different cost estimation techniques | |
should consider differences when making an estimate for a new project:- different software developers with different skill levels
- different development processes and maturity levels
- different types of customers and users
- different schedule demands
- different technology
- different technical complexity of the requirements
- Different domains
- Different levels of requirement stability
| |
should divide the project up into individual subsystems, and then divide each subsystem further into the activities that will be required to develop it, then make a series of detailed estimates for each individual activity, and sum the results to arrive at the grand total estimate for the project | |
should revise estimates because- As you gather requirements and begin specifying details, you will be able to increase the accuracy of your estimate
- As you move into the design phase, you can again increase the accuracy of your estimates
- You will adjust your estimates as requirements change, or features are dropped in order to meet a budget or deadline
- As you encounter problems during design and implementation, you will be able to adjust your estimates to take these into account
| |
should use cost estimation principles | |
software developer | asks several evaluators to independently perform heuristic evaluations | |
develops software | |
has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise | |
is part of software development team | |
maintains software | |
may be judged on when they deliver product, not on its quality level | |
may be reluctant to develop new libraries, APIs and frameworks because- developing anything reusable is seen as not directly benefiting the current customer
- If a developer has painstakingly developed a high-quality reusable component, but management only rewards the efforts of people who create the more visible 'final product', then that developer will be reluctant to spend time on reusable components in the future
- Efforts at creating reusable software are often done in a hurry and without enough attention to quality. People thus lose confidence in the resulting components, and in the concepts of reuse and reusability
| |
may refuse to reuse components in which they lack confidence | |
most often works on custom software | |
must ensure that the set of use cases is complete and that they are expressed consistently and unambiguously | |
must inform the project manager about any problems | |
must understand the customer's business environment, their problems and the available technology which can be used to solve the problems | |
often fails to adequately involve users in the development process | |
often has significantly less knowledge about modelling than about design and programming | |
performs cost estimation | |
reuses libraries and APIs delivered with a programming language | |
should be rewarded for developing reusable components | |
should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value | |
should identify all the use cases associated with the software product | |
should not document a design only after it is complete | |
should not omit design documentation | |
should only reuse technology that others are also reusing | |
should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them | |
should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence | |
should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs | |
should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software | |
wants software that is easy to design and maintain and which has parts that are easy to reuse | |
stakeholder | must agree on requirements | |