소프트웨어 공학의 사실과 오해

http://www.yes24.com/Product/Goods/1418676?OzSrank=1

인상 깊은 단락

p24

저자의 화려한 경력

p29

많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.

p31

사람 경시 풍조

사람은 빡빡한 스케쥴과 압박 하에서 일을 더 잘 한다고 주장한다.

p33

잃어버린 곳이 아닌 밝은 곳에서 물건 찾기 일화

소프트웨어 분야에 있는 우리는 모두 마음속으로는 기술자라고 생각하며, 우리의 작업을 쉽게 하는 새로운 기술을 고안하는 것을 더 좋아한다. 마음속 깊은 곳에서는 사람과 관련된 문제가 더 중요하다는 것을 알면서도 말이다.

p34

그 문제는 “망약 당신의 생명이 특정 소프트웨어에 의존하게 된다면 어떤 것에 대해 알고 싶습니까?” 였다. Bollinger는 다음과 같이 대답했다. “무엇보다도, 저는 소프트웨어를 작성한 사람이 매우 지적인지, 또 매우 엄격해서 자신이 작성한 프로그램이 정확하게 작동하도록 하려는 광적인 욕구가 있는지 알고 싶습니다. 다른 모든 것은 저에겐 부차적인 것입니다.”

p37

생산성의 개인차에 대한 연구들. 28배, 10배 등의 결과가 있음.

p45

작업공간의 크기와 XP, 짝 프로그래밍 논쟁

p47

Grady에 따르면, 재사용으로 인한 이득은 10~35% 정도로, 10배 이상의 이득을 얻을 수 있따는 최근 컴포넌트 열광자들의 터무니없는 주장(또는 다른 것에 대한 예전의 열광자들의 주장)고 배치된다.

p49

아마 우리 소프트웨어 분야 사람들은 하드웨어의 발전이 너무 부러워서 이런 발전이 우리에게도 일어나고 있다고, 또는 일어날 수 있다고 믿고 싶은 모양이다.

p55

학습곡선을 과소평가할 때의 위험

p58

단언하건데, 여기서 문제는 NIH가 아니다. 문제는 무엇보다도 불가능한 일정을 잡아놓고 이를 따르도록 하는 문화에 있다. 일정을 너무 촉박하게 잡기 때문에 새로운 개념에 대해 배울 시간이 없는 것이다.

p61

폭주의 원인 중 가장 두드러지는 두 가지는 형편없는 (보통은 낙관적인) 추정과 불안정한 요구사항이다.

대부분의 추정이 현실적인 목표라기보다는 희망에 가깝다.

지름길이 선택되고, 좋은 관례는 생략되고, 피치 못할 일정의 폭주는 기술의 폭주로 이어진다.

p62

LOC, FP등의 기준도 문제가 있다.

p63

여기서 중요한 것은, 우리가 21세기에 있지만, 정확한 추정을 위한 요소가 어떤 건지 여전히 모른다는 것이다.

p64

추정 방법에 관심을 가진 사람들은 많은 문제가 있음에도 불구하고 ‘상호보완적(belt and suspenders)’ 접근법이 가장 적절한 타협이라는 결론에 이르기 시작했다. 그들은 추정이 어느 정도 정확한 답을 산출하기 위해서는 (1)문제 영역을 잘 아는 전문가의 의견과 (2)과거와 현재의 설정에 대한 알고리즘의 출력결과를 포함해야 한다고 말한다.

p65

“Why Is Software Late?” 논문

이 연구에서는 프로젝트가 늦어지는 가장 큰 원인은 ‘낙관적 추정'으로 51%를 차지한다고 결론짓는다.

p66

초기 추정의 부적절성

대부분의 소프트웨어 추정은 생명주기의 초기에 수행된다. 요구사항을 정의하기 전에, 즉 문제를 이해하기 전에 추정을 한다는 사실을 꺠닫기 전까지는 아무 문제가 없어 보인다. 따라서 추정은 보통 부적절한 시기에 수행된다.

p68

마케팅 매니저가 제품을 6개월 내에 출시하겠다고 밝힘.

위의 인용문에서 볼 수 있는 것은, 추정이 부적절한 시기에 수행될 뿐 아니라 부적절한 사람들에 의해서 수행되는 경우도 있다는 것이다.

p73

따라서 부적절한 시점에 부적절한 사람들이 산정한 잘못된 추정은 대게 교정되지 않는다.

p79

그것은 오늘날 우리 문화에서, 사람들은 (불가능한) 일정을 맞추기 위해 무진장 노력하느라 목적 달성을 위해 완성도와 품질을 기꺼이 희생시킨다는 것이다.

p83

Jeffery와 Lawrence(1985)는 “추정을 전혀 하지 않은 프로젝트가 생산성 측면에서 가장 성공적이였다.“는 사실을 발견했다. 바로 다음은 기술자들이 추정을 수행한 프로젝트가 차지했고, 괸리가 추정을 수행한 프로젝트는 최악이었다. Lansbaum과 Glass(1992)는 생산성 수준과 통제에 대한 감(feeling of control)사이에 밀접한 관계가 있음을 발견했다. 즉 프로그래머는 그들의 운명을 스스로 통제할 수 있따는 느낌을 가질 때 생산성이 훨씬 높았다.

p89

소규모 재사용(서브루틴 라이브러리)은 거의 50년 전부터 시작되어 잘 해결된 문제다.

p93

만약 여러 프로젝트나 애플리케이션 도메인 사이에 비슷한 문제가 충분히 많이 존재한다면 컴포넌트 기반의 접근 방법은 결국 효과가 있을 것이다. 그러나 많은 사람들이 의심하는 바와 같이, 애플리케이션 도메인의 다양성으로 인해 두 가지 문제가 아주 비슷한 경우가 거의 없다면, 가장 기본이 되는 공통적 기능과 작업만이 일반화될 수 있을 것이고, 이것이 프로그램 코드에서 차지하는 비율 또한 매우 작을 것이다.

p94

즉 앞에서 언급한 다양성 문제 때문에 다수의 애플리케이션(도메인은 말할 것도 없고)에 걸쳐 진정으로 범용적인 컴포넌트를 발견하는 것은 규칙이 아니라 예외다.

p98

대규모 재사용은 한정된 범위의 애플리케이션 도메인에 적용한다면 성공할 가능성이 충분히 있지만, 여러 프로젝트나 여러 도메인에 걸쳐 적용한다면 성공할 가능성이 거의 없다. (McBreen 2002).

p100

재사용에 대한 두가지 ‘3의 법칙'이 있다. (1)재사용 가능 컴퍼넌트를 만드느 것은 단일 목적의 컴포넌트를 만드는 것보다 세배는 어렵다. (2)컴포넌트는 재사용 라이브러리 인정될만큼 일반적이라 생각하기 전에 서로 다른 세 가지 애플리케이션에 적용해봐야 한다.

p109

소프트웨어 시스템을 20~25% 또는 그 이상 수정해야 한다면 처음부터 다시 새로운 제품을 구축하는 것이 비용도 적게 들고 작업도 쉽다는 것이다.

(“소프트웨어 작업은 인류가 지금까지 해온 것 중 가장 복잡한 작업이다.“라는 Fred Brooks의 유명한 말(1995)는 두말할 필요도 없다.)

p112

디자인 패턴은 설계의 재사용

p121

분류 결과 소프트웨어 개발 작업의 80%는 지적인 작업으로, 20%는 사무적인 작업으로 분류되었다.

p113

“Runaway Projects - Causes and Effects” 논문

이 연구는 ‘완전히 명시되지 않은 프로젝트의 목표'가 폭주하는 프로젝트의 주요원인으로 51%나 차지한다는 것을 밝혔다. (48%는 ‘잘못된 계획과 추정’)

p139

누락된 요구사항은 가장 수정하기 힘든 오류다.

p143

제거하기 어려운 오류

• 누락된 코딩 로직 30%
• 회귀 오류 8.5%
• 문서화 오류 8%

p150

소프트웨어 문제에 대해 최상의 솔류션이 하나인 경우는 거의 없다.

p152

소프트웨어 공학 컨퍼런스에서 “최고의 설계자들이 모인 방에서 두 명의 설계작 동의한다면 그게 다수 의견이다.” 라는 말을 한 사람은 Bill Curtis였다.

p154

전문 설계자들은 설계 작업에서 핵심을 파악할 때 경험적, 시행착오적 접근방법을 사용한다는 것이다.

p155

설계는 예측 가능한, 구조화할 수 있는, 규격화할 수 있는 프로세스와 거리가 멀고, 너저분하고 시행착오적인 것임을 알 수 있다.

p160

나는 이 사실 때문에, 설계와 코딩을 분리하는 것은 좋지 않다고 생각한다. McBreen(2000)도 “소프트웨어 개발에서 전통적인 작업 분할 방식은 적절하지 않다.“며 동의했다.

p162

COBOL이 처음 등장할 때 “슈퍼마켓 점원도 작성할 수 있고, 관리자도 읽을 수 있다.“고 했다.

p167

오류 제거는 생명주기에서 가장 시간이 많이 소모되는 단계다.

p168

즉 요구분석에 20%, 설계에 20%, 코딩에 20%(대부분의 프로그래머는 직관적으로 이 단계에서 가장 많은 시간을 소모할 것이라 생각하지만, 이 직관은 틀린 것이다), 그리고 오류 제거에 40%를 사용한다.(Glass 1992)

p170

테스트의 종류

• 요구사항 중심의 테스트
• 구조적 테스트
• 통계적 테스트
• 위험 요소 중심의 테스트

p173

여기서 알 수 있는 것은, 수많은 종류의 테스트 방법이 존재하지만 소프트웨어 제품의 복잡성 때문에 완벽한 테스트는 불가능하다는 것이다.

p191

엄격한 검사(inspection)은 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거할 수 있다.

p202

그러나 그가 말한 뜻은, 빠르게 성장하는 소프트웨어 분야에 새로 입문하는 살마들이 폭발적으로 증가하고 있으므로, 기존 사람들의 경험 수준이 증가하더라도 경험 수준이 낮은 떼거리의 초보자들로 인해 결국 상쇄된다는 것이다.

소프트웨어 분야는 지혜(wisdom)은 증가하지 않는다.

p205

동료 검토(peer review)는 기술적인 측면과 사회적인 측면을 모두 가진다. 한쪽을 무시하고 다른 한쪽에만 치우치면 큰 실패를 초래한다.

p209

유지보수는 보통 소프트웨어 비용의 40~89%(평균 60%)를 차지한다. 따라서 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다.

p213

소프트웨어 유지보수 비용에서 약 60^는 개선 작업에 쓰이는 비용이다. 오류 정정은 약 17% 정도다.

p211

유지보수 생성주기에 따른 비율 (Fjelsted와 Hamlen(1979))

p226

더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은게 아니라) 유지보수가 필요하다.

이런 시스템은 더 많은 수정이 가해지기 때문에 다른 시스템보다 더 오래 유지된다. 그리고 이런 잘 구축된 시스템은 개선하기가 쉽기 때문에 더 많은 수정이 가해진다.

p233

품질 속성

• 이식성(portability)
• 신뢰성(reliability)
• 효율 (efficiency)
• 사용편의성(usability)
• 테스트 용이성(testability)
• 이해용이성(undertandability)
• 수정용이성(modifiability)

p243

‘편향적 오류'와 ‘사고의 덫'에 대한 논문

p244

오류는 뭉치는 경향이 있다.

p246

소프트웨어 오류 제거에 단 하나의 최상의 방법은 없다.

p284

프로그래밍은 비아자적(egoless)이 될 수 있고, 또 되어야 한다.

비자아적이라는 말이 영혼이 없다는 말보다는 비판에 개방적으로는 방향으로 해석되어야겠다.

p292

소프트웨어 분야에는 더 많은 방법론이 필요하다.

대신, 대부분의 사람들은 당명한 상황에 맞게 방법론을 병형시켜 적용했다.

p298

LOC 논쟁