[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

 Systems ProductsBusiness ProductsShrink-Wrap Products
System Size

(lines of code)

Schedule

(month)

Effort

(man-month)

Schedule

(month)

Effort

(man-month)

Schedule

(month)

Effort

(man-month)

10,00010 48 6 9 7 15
30,00016 185 9 37 11 59
50,00020 360 11 71 14 115
100,00026 820 15 160 18 270
200,00035 1,900 20 370 24 610
300,00041 3,000 24 600 29 1,000
500,00051 5,500 29 1,100 35 1,800

< Sources : Derived from data in
Software Engineering Economics (Boehm 1981),
"An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987),
Applied Software Measurement (Jones 1991),
Measures for Excellence (Putnam and Myers 1992),
Assessment and Control of Software Risks (Jones 1994)>

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

PhaseEffort and SizeSchedule
OptimisiticPessimisitcOptimisiticPessimisitc
Initial product concept0.25 4.0 0.60 1.60
Approved product concept0.50 2.0 0.80 1.25
Requirements specification0.67 1.5 0.85 1.15
Product design specification0.80 1.25 0.90 1.10
Detailed design specification0.90 1.10 0.95 1.05

< Source : Adapted from "Cost Models for Future Software Life Cycle Processes : COCOMO 2.0" (Boehm et al. 1995) >

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

 Systems ProductsBusiness ProductsShrink-Wrap Products
System Size
(lines of code)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
Schedule
(month)
Effort
(man-month)
10,0008 24 4.9 5 5.9 8
30,00013 97 8 20 9 32
50,00016 190 10 40 11 67
100,00022 450 13 93 15 160
200,00029 1,300 17 210 20 360
300,00034 1,650 20 345 24 590
500,00042 3,100 25 640 29 1,100

< Sources : Derived from data in
Software Engineering Economics (Boehm 1981),
"An Empirical Validation of Software Cost Estimation Models" (Kemerer 1987),
Applied Software Measurement (Jones 1991),
Measures for Excellence (Putnam and Myers 1992),
Assessment and Control of Software Risks (Jones 1994)>

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

Comparison of Motivators for Programmer Analysts vs. Managers and the General Population.

Programmer AnalystsManagers of ProgrammersGerneral Population
1. Achievement 1. Responsibility 1. Achievement
2. Possibility for growth 2. Achievement 2. Recognition
3. Work itself 3. Work itself 3. Work itself
4. Personal life 4. Recognition 4. Responsibility
5. Technical-supervision opportunity 5. Possibility for growth 5. Advancement
6. Advancement 6. Interpersonal relations, subordinate 6. Salary
7. Interpersonal relations, peers 7. Interpersonal relations, peers 7. Possibility for growth
8. Recognition 8. Advancement 8. Interpersonal relations, subordinate
9. Salary 9. Salary 9. Status
10. Responsibility 10. Interpersonal relations, superior 10. Interpersonal relations, superior
11. Interpersonal relations, superior 11. Company policies and administration 11. Interpersonal relations, peers.
12. Job security 12. Job security 12. Technical-supervision opportunity
13. Interpersonal relations, subordinate 13. Technical-supervision opportunity 13. Company policies and administration
14. Company policies and administration 14. Status 14. Working conditions
15. Working conditions 15. Personal life 15. Personal life
16. Status 16. Working conditions 16. Job security

< Sources : Adapted from Software Engineering Economics (Boehm 1981) and "Who Is the DP Professional?" (Fitz-enz 1978).>

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

From rapid development (Steve McConnell)

* PEOPLE
- Undermined motivation.
- Weak personnel : "Should be suitable person (Not available person!)"
- Uncontrolled problem employees.
- Heroics : Always shouting "Can do" and don't report risk till last stage of project.
- Adding people to a late project.
- Noisy, crowded offices.
- Friction between developers and customers.
- Unrealistic expectations.
- Lack of effective project sponsorship.
- Lack of stakeholder buy-in.
- Lack of user input.
- Politics placed over substance.
- Wishful thinking.

* PROCESS
- Overly optimistic schedules.
- Insufficient risk management.
- Contractor failure.
- Insufficient planning.
- Abandonment of planning under pressure.
- Wasted time during the fuzzy front end.
- Shortchanged upstream activities.
- Inadequate design.
- Shortchanged quality assurance.
- Insufficient management controls.
- Premature or overly frequent convergence.
- Omitting necessary tasks from estimates.
- Planning to catch up later.
- Code-like-hell programming.

* PRODUCT
- Requirements gold-plating.
- Feature creep.
- Developer gold-plating.
- Push-me, pull-me negotiation.
- Research-oriented development.

* TECHNOLOGY
- Silver-bullet syndrome.
- Overestimated savings from new tools and methods.
- Switching tools in the middle of a project.
- Lack of automated source-code control.

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

ActivitySmall Project
(2,500 lines of code)
Large Project
(500,000 lines of code)
Architecture/design10% 30%
Detailed design20% 20%
Code/Debug25% 10%
Unit test20% 5%
Integration15% 20%
System test10% 15%

< Source : Adapted from Code Complete (McConnell 1993) >

+ Recent posts