'development'에 해당되는 글 26건

  1. 2008.05.22 [Dev][Excerpt] Using interpreted language...
  2. 2007.11.25 [Dev] Let's make schedule-history-table!
  3. 2007.08.11 [Dev] Required comments in change list.
  4. 2007.06.17 [Dev] 요약 [extream programming installed].
  5. 2007.06.15 [Dev] XP에서 말하는 code branch 관리에 대한 의문점...
  6. 2007.03.12 [Dev][Excerpt] Typical Architectural Components
  7. 2007.03.09 [Dev][Excerpt] Software Schedule/Effort Equations.
  8. 2007.03.09 [Dev][Excerpt] Shortest Possible Schedules.
  9. 2007.03.05 [Dev][Excerpt] Requirement change ratio
  10. 2007.03.03 [Dev][Excerpt] Nominal Schedules

[Dev][Excerpt] Using interpreted language...

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

Developers working in interpreted languages tend to be more productive than those working in compiled language (Jones 1986a).
신고
tags : development
Trackback 0 : Comment 0

[Dev] Let's make schedule-history-table!

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

In general, there is a table to help estimate schedule and this table usually categorize software according to software type(system product, business product and so on) and size(line of code - 10,000/20,000/.../500,000/... ). It is definitely very useful.
Now it's time to make table for me, my team and our company for more accurate estimation!! (We can use more customized categorization.)
신고
tags : development
Trackback 0 : Comment 0

[Dev] Required comments in change list.

Essay/Software 2007.08.11 20:38

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

In case that several branches are maintained at the same time, 'change list'(ex. bug fix) tends to be patched to several different code branches. General way to apply 'change list' is code-merge. In this case, the guy who merges 'change list' may not know enough about change. So, there should be information about checking patch result - to verify that patching is successful or not - as a comments of 'change list'.

One of good example is something like this.
* before patch : title string is "xxxx" in screen A.
* after patch : title stringis "yyyy" in screen B.

신고
tags : development
Trackback 0 : Comment 0

[Dev] 요약 [extream programming installed].

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

* XP의 한계

저자가 이야기한 바와 같이 XP는 대규모 Project (여기서 말하는 대규모란, project를 하기 위해 필요한 사람 숫자가 많은 Project를 의미하는 것처럼 보인다 - 사람 숫자가 많다 = 필요한 Communication 양이 많다.)에는 적합하지 않은 것 같다. 이 점을 명확히 하고 XP를 적용하자.

* Test Oriented Development의 장점.
일단 Test Oriented로 하게 되면, Test를 위한 Interface를 가장 먼저 생각하게 된다. 즉 자연스럽게 "Interface Oriented Development"를 하게 된다. 또한 개발된 Program을 검증하기 용이할 확률이 높다. 중요한 것은 Auto Test란 것 자체가 논리적인 오류를 잡아낼 수는 있어도, User experience쪽에 부적합한 내용같은 부분은 잡아내는 것이 사실상 불가능 하다는 점이다. 또한 논리적인 오류 역시, 어느 정도 큰 Module을 대상으로 Auto Test를 돌리게 되면, 모든 경우를 Test하는 것이 상당히 어렵게 된다. 따라서 Auto Test는 작은 Unit Test에 적합한 것으로 보인다. (이렇게 하면, Test종류는 늘어나겠지만... )

* 고객의 역할.
고객은 business의 가치를 높이는 것이 무엇인지 파악하고, 무엇을 먼저 하고 무엇을 나중에 할 것인지를 결정하고, 시스템이 제대로 작동하는지 확인할 수 있는 test를 정의한다.

* 관리자의 역할.
관리자는 고객과 개발자를 한데 모으고 서로 융화시켜, 팀이 순조롭게 운영되도록 도와준다. 관리자는 process를 수행하는 것이 아니라, 단지 process가 원활하게 진행되도록 하는 것이다.
-> 훌륭한 관리자의 일은 처음부터 끝까지, 작업을 하고 있는 사람들 앞에 놓인 장애물을 치우는 일이다.

* XP 프로그램 작성.
- 코드의 공동 소유 : 누구든 현재 Project의 코드를 원하는 대로 수정할 수 있다.
- 단순한 설계 : 모든 test를 실행하고, 모든 idea를 표현하며, 최소한의 Class와 Method를 가지지만, 중복된 code를 포함하지 않는다.
- 지속적인 Refactoring: 기존 코드를 바꾸지 않는 이유는 잘못되는 것을 두려워해서이다. 따라서, 거의 100%가동되는 모든 단위 Test를 가지고 있다면 Refactoring은 두려워할 만한 일이 아니다.
- 지속적인 통합 : 지속적인 통합은 항상 releasable한 상태로 유지하고, 통합시에 나타날 수 있는 문제를 최대한 빨리 찾아낼 수 있다는 측면에서 중요하다. 통합이 늦어지면, debugging시 드는 비용은 늦어진 시간만큼 증가한다. 기하급수적으로...
- 코드작성표준
- 주당40시간 : 한 주 이상의 과도한 시간외 근무는, 코드의 질을 떨어뜨리며, bug를 양산하는 주범이다.

* 짝 Programming.
두 사람이 하나의 컴퓨터 앞에서 같이 Programming을 한다. "역동적인 2인조는 개별 Play를 하는 3명보다 낫다"
(=> 일단 XP에서는 이렇게 이야기하고 있는데... 난 여기에는 아직까진 동의할 수 없다. 이건 분명히 case by case..이다.!)
코드 공동 소유 vs. 코드의 건전성 유지.

신고
tags : development
Trackback 0 : Comment 0

[Dev] XP에서 말하는 code branch 관리에 대한 의문점...

Essay/Software 2007.06.15 22:03

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

XP(Extream programming)에 따르면, code branch는 항상 release가능한 상태를 유지해야 한다. 그런데 이는 XP에서 마찬가지로 주장하고 있는, "누구나 수정할 수 있고, 누구나 test가능한 code"의 개념과는 상반된다. 누구나 수정할 수 있고, 누구나 test가능하다면, 그 code branch는 언제든 깨어질 수 있다. 따라서, 항상 releasable할 수는 없다.

"누구나 수정할 수 있고, 누구나 test할 수 있다"는 것과 "코드는 항상 release가능한 상태를 유지해야 한다." 는 것을 어떻게 같이 가져갈 것인가????
나의 XP에 대한 지식이 짧아서 그런것 같은데...
(XP에서 어떻게 표현했는지, 그 정확한 영어 표현이 생각나지 않아서 한글로 적는다...)

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Typical Architectural Components

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

From ( "Code Complete", McConnell )
  - Program organization
  - Change strategy
  - Buy-vs.-build decisions
  - Major data structures
  - Key algorithms
  - Major objects
  - Generic functionality
  - User interface.
  - input/output
  - Memory management
  - String storage (optional)
  - Error processing
  - Over-enginerring
  - Assertions
  - Fault tolerance
  - Performance
신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Software Schedule/Effort Equations.

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

▶ Software Schedule Equation.

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

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Shortest Possible Schedules.

Excerpt 2007.03.09 21:49
[[ 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,0006 25 3.5 5 4.2 8
30,0009 110 5.5 22 7 37
50,00011 230 7 46 8 79
100,00015 540 9 110 11 190
200,00020 1,250 11 250 14 440
300,00024 2,100 14 420 16 725
500,00030 3,900 17 780 20 1400

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

신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Requirement change ratio

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

A study at IBM found that the average project experiences a 25 percent change in requirements during development (Boehm 1981).
신고
tags : development
Trackback 0 : Comment 0

[Dev][Excerpt] Nominal Schedules

Excerpt 2007.03.03 21:35
[[ 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)>

신고
tags : development
Trackback 0 : Comment 0