Ting 이네 Software 이야기

Schedule in months = 3.0 * power (man-month, 1/3).

65 man-months job : 30 * power(65, 1/3) := 12.
So, in this case, "team with 5~6 members works for 12 months" is ideal.

 
▶ Schedule Compression Factor.
schedule compression factor = desired schedule / initial schedule.

[initial schedule 12 months.]
To advance this to 10 months : compression factor = 0.83 (10 / 12)

 
▶ Compressed Schedule Effort.
compressed schedule effort = initial effort / schedule compression factor.

[initial schedule is 12 months, initial effort is 78 man-months.]
To advance this to 10 month :
compression factor = 0.83 (10 / 12)
compressed schedule effort = 94 man-months (78 / 0.83)
=> To advance schedule by 17%, 21% more effort is required.

 
NOTE :
  It is impossible to make schedule compression factor be below 0.75 or 0.80.
  (Bohem 1981; Putnam and Myers 1992; Jones 1994)
=> This means, no matter how much effort is available, we cannot advance schedule by more than 25%.; In this case, we should cut back on product size itself.

< From "Rapid Development" (Steve McConnell) >

< 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)>

< 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)>

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

< 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.

< 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.

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

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

Ascending Stack : The stack grows upwards, starting from a low address and progressing to a higher address.
Descending Stack : The stack grows downwards, starting with a high address and progressing to a lower one.

Fundamentally, these two are same. But, I prefer descending stack, because when stack is broken, mostly post-stack-section(higher memory address) tends to be broken. So,

- [case1 : current stack has enough free space]
Descending stack is better to detect stack-corruption than ascending stack.

void func_test(void)
{
    (omitted...)
    char a[10]; // ---(*1)
    (omitted...)
    memcpy(a, data, len); // len > 10 ---(*2)
   (omitted...)
}

If stack space after (*1) is not used, then even if stack is corrupted, it is very difficult to detect in ascending stack.
(because, no one uses corrupted area.) So, debugging is more difficult.

- [case2 : current stack is almost pull]
In descending stack, usually, corrupting stack of specific thread(Thread A) affects it's own behavior firstly. So, it is easier to debug - same with [case1].
In ascending stack, corrupting stack may affects to other thread's stack - thread whose stack is just next (higher address) of Thread A - firstly with high possibility (especially, if several stacks are adjacent in memory space). This usually leads to debugging-nightmare