practical rules of thumb


아래의 원칙들은 예전부터 알려져 왔지만, 현재까지 잘 지켜지지 않고 있다. 이런 문제의 가장 근본적인 문제는 프로젝트 시간 단축을 시키려고 하는 것과 과도하게 개발자를 바쁘게 하는 것이다. 이 두가지는 프로세스를 의미없게 만드는 적이다.

대체로 culture가 productivity에 상당한 영향을 미친다는 것을 알 수 있다. 아래의 원칙들은 좋은 culture가 없이는 지켜지기 힘든 일이라고 생각한다. 스트라이커에게만 관심을 쏟고 수비수 양성을 게을리하는 팀에서는 골을 많이 넣는 재밌는 경기는 보일 수는 있겠지만, 그 팀이 이기는 경기를 하기는 쉽지 않을 것이다. 그와 유사한 맥락이라고 볼 수 있다.

  1. 재사용된 소프트웨어를 주로 사용한 프로젝트는 신규 프로젝트보다 1/4의 기간이 소요된다.[1,2]
  2. 프로젝트 총 노력의 18%는 specification/requirements, 19%는 design, 34%는 coding, 29%는 test (프로젝트의 평균값이며 plus/minus 10%의 편차가 있음, 125개의 휴렛 팩커드 프로젝트로부터 도출해 낸 결과들)
  3. 50~75%의 모든 design 에러는 inspection에서 발견될 수 있다.[3,4,5,6]
  4. cyclomatic complexity가 10보다 큰 모듈들은 이해하기 어려우며 결함 발생확률도 더 높았다.[8,9,10]
  5. code inspection은 defect를 발견하기 위한 매우 cost-effective한 방법이다.
  6. code coverage측정하지 않고 시험을 하게 되면 보통 55% 커버한다. 측정을 해서 높이려고 하면 80%까지는 쉽게 올라간다. 그 이상은 좀 더 과하게 노력을 해야 한다.[13]
  7. 신규 프로젝트보다 재사용한 코드가 많은 프로젝트의 결함률이 낮다.[1]

Bibliograpgy

1. Grady, R. and D. Caswell, Software Metrics: Establishing a Company-Wide Program, Englewood Cliffs, NJ: Prentice-Hall, Inc., 1987, pp. 34, 65, 111, 112, 113.
2. Card, D., V. Church, and W. Agresti, “An Empirical Study of Software Design Practices,” IEEE Transactions on Software Engineering, Vol. SE-12, no. 2, (Feb. 1986), pp. 264-271. 19
3. Boehm, B., “Industrial Software Metrics Top 10 List,” IEEE Software, (Sept, 1987), pp. 84-85.
4. Fagan, M. E., “Advances in Software Inspections,” IEEE Transactions on Software Engineering, Vol. SE-12, no. 7 (July 1986), pp. 744-751.
5. Jones, C., Programming Productivity. New York: McGraw-Hill Book Co., 1986, p. 179.
6. Myers, G., “A Controlled Experiment in Program Testing and Code Walkthroughs/Inspections,” Communications of ACM, Vol. 21, no. 9, (Sept. 1978), pp. 760-768.
7. Boehm, Barry W., Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981, pp. 40, 64, 150.
8. McCabe, T., “A Complexity Measure,” IEEE Transactions on Software Engineering, Vol. SE-2, no. 4, Dec. 1976, pp. 308-320.
9. Walsh, T. ]., “A Software Reliability Study Using a Complexity Measure,” Proceedings of the 1979 National Computer Conference. New Jersey: AFIPS Press (1979), pp. 761-768.
10. Ward, W., “Software Defect Prevention Using McCabe’s Complexity Metric,” Hewlett-Packard]ournal, Vol. 40, no. 2 (April 1989), pp. 64-69.
11. Curtis, B., S. B. Sheppard, and P. Milliman, “Third Time Charm: Stronger Prediction of Programmer Performance by Software Complexity Metrics,” Proceedings of the Fourth International Conference on Software Engineering, (July 1979), pp. 356-360.
12. Rambo, R., P. Buckley, and E. Branyan, “Establishment and Validation of
Software Metric Factors,” Proceedings of the International Society of Parametric Analysts Seventh Annual Conference, (May 1985 ), pp. 406-417.
13. Herington, D., P. Nichols, and R. Lipp, “Software Verification Using Branch Analysis,” Hewlett-Packard journal, (June 1987), pp. 13-22.
14. Vessey, I., and R. Weber, “Some Factors Affecting Program Repair Maintenance: An Empirical Study,” Communications of the ACM, Vol. 26, no. 2 (Feb. 1983), pp. 128-134.
15. Levendel, Y., “Reliability Analysis of Large Software Systems: Defect Data Modeling,” IEEE Transactions on Software Engineering, Vol. 16, no. 2, Feb. 1990, pp. 141-152.
16. Moller, K. H., “Increasing of Software Quality by Objectives and Residual Fault Prognosis,” First E.O.Q.C. Seminar on Software Quality, Brussels, Belgium, (April 1988), pp. 478-488.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s