어쨌건간에 흘러가는 者

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

9. Function points
- based on a combination of program characteristics
  1) External inputs and outputs
  2) User interactions
  3) External interfaces
  4) Files used by the system
- A weight is associated. * UFC = ∑(number of elements of given type * weight), UFC means Unadjusted Function point Count.
- Productivity is estimated by functions point per person-month
- can be used to estimate LOC depending on the average number of LOC per FP for a given language. LOC = AVC(language dependent factor) * number of function points
- are very subjective. They depend on the estimator. Automatic function-point counting is impossible

10. Object points
- (alternatively named application points) are an alternative to function points for 4GL
- The number of objects in a program is a weighted estimate of the number of
  1) Seperate screens
  2) Reports that are produced by the system
  3) Program modules that must be developed to supplement the database code
- easier to estimate from a specification than function points. So it is commonly used at a fairly early point in SDLC

11. Factors affecting productivity
- Application domain experience
- Process quality
- Project size
- Technology support
- Work environment (refer to Managing people)

12. Estimation techniques
- No simple way to make an accurate estimate of the effort
- Project cost estimates may be self-fulfilling : The estimation defines the budget and the product is adjusted to meet the budget
- Due to changing technologies, prev estimating experience does not carry over to new systems
- Estimation should be based on several methods
- If these do not return approximately the same result, more information for estimation is required
- Pricing to win is sometimes the only applicable method

13. Technique types
  1) Algorithmic cost modeling : based on historical cost information. Effort = A * Size^B * M (A is an organisation-dependent constant, Size is S/W size or fuction, object points, B reflects the disproportionate effort for larget projects(1 ~ 1.5) and M is a multiplier reflecting product, process, peple attributes)
  2) Expert judgement : Several experts on the proposed S/W development techniques and the application domain are consulted
  3) Estimation by analogy : is applicable when other projects in the same application domain have been completed
  4) Parkinson's Law : estimated via mon-month. The cost is determined by available resources rather than by objective assessment.
  5) Pricing to win : the estimated effort depends on customer's budget and not on the S/W functionality

14. Top-down and bottom-up estimation
- Any of these approaches may be used top-down or bottom-up
  1) Top-down : estimation starts at the system level. Usable without knowledge of the system architecture and the components. It may result underestimation of the cost of soving difficult low-level technical problems
  2) Bottom-up : starts at the component level. Usable when the architecture of the system is known and components identified. It may result underestimate the cost of system level activities such as integration and documentation

15. Project Uncertainty

본 포스트는 개인 스터디 용으로 작성된 Ian Sommerville의 Software Engineering, 8/E의 요약본입니다.

1. Fundamental estimation question
- How much effort is required to complete an activity?
- How much calendar time is need to complete an activity?
- What is the total cost of an activity?

2. Software cost components and pricing
- H/W and S/W costs
- Effort costs (the dominant factor in most projects) : salaries, social and insurance costs.
- Effort costs must take overheads into account : heating, lighting, networking, shared facilities, etc.
- No simple relationship between the development cost and the price charged to the customer
- Broader organisational, economic, political and business considerations influence the price charged

4. Software pricing factors
- Market opportunity
- Cost estimate uncertainty : contingency increase its price
- Source code ownership : to customer or developer or hybrid
- Requirements volatility
- Financial health of the developer

5. Software productivity
- A measure of the rate at which individual engineers produce software and documentation
- Not quality-oriented although assourance is a factor in productivity assessment

6. Productivity measures
- Size related measures : based on some output from the S/W process. e.g LOC, KLOC
- Function-related measures : based on an estimate of the functionality of the delivered S/W. e.g. Function-points, Object-points

7. Lines of code (LOC)
- assumes thate there is a linear relationship between system size and volume of documentation
- The more verbose the programmer, the highter the productivity

8. Productivity comparisons : The lower level the language, the more productive the programmer : More code on lower level language