Archive for the ‘Facts and Fallacies of Software Engineering’ tag
소프트웨어 공학의 사실과 오해 4 – 복잡성, 요구사항
http://www.yes24.com/24/goods/1418676
복잡성
여러분이 이 책을 읽고 아무것도 기억하지 못하더라도 이것만은 기억하기 바란다. 문제의 복잡성이 25% 증가하면 소프트웨어 솔루션의 복잡성은 100% 증가한다. 이 문제를 극복하기 위한 어떤 해결책도 없다는 것 또한 기억하기 바란다. 소프트웨어 솔루션은 복잡한데, 그게 그 녀석의 타고난 본성이다.
p.118
절망적인 얘기 같지만 한 가지 분야로서 존재하려면 복잡성은 필수인 것 같다. 복잡하지 않으면 답이 바로 나오고, 답이 이미 나왔다면 이렇게 많은 사람들이 연구하고, 매번 새로운 솔루션을 개발할 필요는 없지 않을까.
누락된 요구사항
누락된 요구사항은 가장 수정하기 힘든 오류다. – 중략 – 요구사항이 없으면 명세서(specification)에도 나타나지 않을 테고, 명세서로부터 나오는 검토나 검사(inspection)에서도 확인되지 않을 것이고, 요구사항을 만족하는지 검증하기 위한 테스트 케이스도 작성되지 않을 것이다. 따라서 요구사항 누락은 가장 기본적인 오류 제거 방법에서 발견되지 않는다.
p.139, 141
책을 읽기 전에는 한 번도 생각해 본적이 없던 문제다. 테스트 커버리지가 100%가 되어도 누락된 요구사항은 테스트가 안되니 말이다. -_-;; 아래는 저자가 근무하던 우주 항공사의 오류 데이터를 분석한 결과다.
제거하기 어려운 오류 중 가장 눈에 띄는 것은 내가 누락된 코딩 로직 오류라 부르던 것이었다. 이는 제거하기 어려운 오류 카테고리 중 가장 두드러진 것으로 30%를 차지했다. 그 다음으로 중요한 카테고리는 회귀 오류(regression error)로 8.5%를 차지해 30%보다 훨씬 적었다. 제거하기 어려운 소프트웨어 오류 중 세 번째 카테고리는 소프트웨어 오류가 아니라 문서화 오류(8%)라는 것이 흥미롭다.
p.143
여기서 “제거하기 어려운 오류”라는 것은 모든 테스트 과정을 거쳐서 출시된 제품에 여전히 남아있는 오류를 의미한다.
소프트웨어 공학의 사실과 오해 3 – 재사용
http://www.yes24.com/24/goods/1418676
재사용
소규모 재사용(서브루틴 라이브러리)은 거의 50년 전부터 시작되어 잘 해결된 문제라고 한다. 다시 말해 유효성이 검증되었다는 얘기. 다만 여기서의 논쟁은 컴퓨터 분야의 많은 사람들이 재사용을 새로운 아이디어라고 생각해서 지나치게 열광한다는 점. (p.91)
반면에 대규모 재사용(컴포넌트)은 중요하고 바람직한 것이라 생각하지만, 거의 대부분의 문제가 해결되지 않은채 남아있다고 한다. 다시 말해 유효성이 검증되지 않았다는 얘기. 이는 소프트웨어의 다양성에 기인한 것으로 단순히 너무 어려워서 풀 수 없는 문제다.(p.95)
대규모 재사용은 한정된 범위의 애플리케이션 도메인에 적용한다면 성공할 가능성이 충분히 있지만, 여러 프로젝트나 여러 도메인에 걸쳐 적용하려 한다면 성공할 가능성이 거의 없다(McBreen 2002)
p.98
인정하기는 싫지만 이 말이 사실이라는 걸 부인할 수가 없다. 라이브러리는 더 많은 기능을 제공할수록, 더 많은 제약을 가질 수 밖에 없다. 즉 범용성이 줄어드는 것. 그래서 라이브러리를 가능한 작은 단위로 나누는 것이 중요하다. 각 라이브러리 당 제공하는 기능이 줄어들면 제약도 함께 줄어드므로 범용성이 늘어난다.
재사용에 대한 두 가지 ’3의 법칙’이 있다. (1)재사용 가능 컴포넌트를 만드는 것은 단일 목적의 컴포넌트를 만드는 것보다 세배는 어렵다. (2)컴포넌트는 재사용 라이브러리로 인정할 만큼 일반적이라 생각하기 전에 서로 다른 세 가지 애플리케이션에 적용해봐야 한다.
p.100
대부분의 경력이 공통 라이브러리 제작이었던 나로서도 상당히 공감이 되는 얘기. 작년에 라이브러리가 아닌 서비스용 애플리케이션을 만들 기회가 있었는데 다른 애플리케이션을 신경 쓸 것도 없고, 작업중인 애플리케이션이 잘 동작하는지만 보장하면 되므로 좀 더 수월하다는 느낌을 받았다. 공통 라이브러리는 코드 한 줄을 바꾸더라도 신경 쓸 것이 많고, 모든 애플리케이션에서 문제가 없는지 확인하기가 어렵다.
디자인 패턴 재사용은 코드 재사용의 본질적인 문제에 대한 해결책 중 하나다.
p.111
설계를 재사용하는 행위를 칭찬하는 것. 저자는 아주 오래전부터 해오던 디자인의 재사용에 디자인 패턴이라는 이름을 붙여서 유명해지고, 사람들이 열광하는 것에 대해서는 회의적인 관점을 가지고 있다.
디자인 패턴 개념은 널리 받아들여진다. 지속적으로 확대되고 있는 패턴의 영역을 조사하고 알리는 데 힘쓰는 열정적인 학회도 있다. 실무자들은 자신들에게 익숙하지 않은 새로운 패턴뿐 아니라 패턴의 체계와 구조를 제공한다는 측면에서 그런 활동을 높이 평가한다.
그러나 이런 활동이 실제로 효과가 있는지는 측정하기 어렵다. 일반적인 애플리케이션 프로그램에서 얼마나 많은 부분이 정형화된 패턴을 기반으로 했는지에 대한 연구는 내가 아는 한 없다.p.114
동의하기는 힘들지만, 적어도 귀 얇은 나에게 저자의 비판적인 자세는 너무 존경스럽다.
소프트웨어 공학의 사실과 오해 2 – 추정
http://www.yes24.com/24/goods/1418676
추정
프로젝트가 폭주하는 가장 흔한 원인 두 가지 중 하나가 형편없는 추정이라고 한다. (다른 하나는 불안정한 요구사항)
소프트웨어 공학 분야에서는 이런 폭주의 원인이 무엇일까에 대한 질문이 자주 있었다. 이 질문에 대한 대답은, 답하는 사람의 개인적인 주관에 기초하는 경우가 많았다. 어떤 사람들은 적절한 방법론의 부재가 폭주를 야기한다고 말한다. 이런 사람들은 보통 방법론을 파는 사람들이다. 어떤 사람들은 좋은 도구가 없기 때문이라고 말한다(이런 사람들은 무엇으로 먹고 사는 사람들일까?). 어떤 사람들은 프로그래머에게 훈련과 주의가 부족하기 때문이라고 말한다(보통 이런 사람들이 옹호하고, 판매하는 방법론들을 사용하기 위해서는 많은 훈련이 필요하다). 각자 그들이 지지하는 개념을 제시하며 그 개념의 부족이 프로젝트 폭주의 원인이라 주장한다.
p.60
많은 주장들이 결국은 자기들 돈벌려고 하는 얘기라는 것. 그나마 아무에게도 이익을 줄 것 같지 않은 객관적인 대답이 “형편없는 추정”과 “불안정한 요구사항”이란다.
마지막으로 다시 한번 상식적으로 생각해보자. 우리가 앞에서 논한 것처럼 부적절한 시점에 부적절한 사람에 의해 만들어지고 잘 변경되지 않는, 정말 그렇게도 부적절한 소프트웨어 추정이라면, 상대적으로 덜 중요하게 다뤄질 것이라 생각되지 않는가? 틀렸다! 사실 소프트웨어 프로젝트는 거의 항상 일정에 의해 관리된다. 그 때문에 적어도 고위 경영진은 소프트웨어(개발)에서 일정을 가장 중요한 요소로 생각한다.
p.76
두번째 문장에 엄청난 함축이 있다. 우선 추정은 부적절한 시점에 수행되고 있다. 보통 프로젝트를 시작할때 소프트웨어 추정을 하는데, 이 때는 풀고자 하는 문제가 무엇인지도 명확하지 않은 단계이다! 무엇을 만들지도 모르면서 비용과 시간을 추정하는 셈이다.(p.66)
다음으로 추정은 부적절한 사람에 의해 수행되고 있다. 대부분의 경우 소프트웨어 추정은 소프트웨어 제품을 원하는 사람들, 즉 경영진이나 마케팅, 고객, 사용자들에 의해 이루어진다(p.69)
마지막으로 이렇게 잘못된 추정은 프로젝트가 진행되면서 거의 조정되지 않는다.(p.73)
일정에 의한 관리대신에 사용할 수 있는 방법이 몇 가지 제시되고 있다.(p.77)
- 제품에 의한 관리 : 사용 가능한 정도, 어느 정도 작동하는가에 의해 프로젝트의 성공/실패 판단
- 이슈에 의한 관리 : 프로젝트 도중에 발생하는 이슈를 얼마나 잘 해결하는 가에 의해 프로젝트의 성공/실패 판단
- 위험요소에 의한 관리 : 위험요소가 적절히 해결되었는지를 통해 프로젝트의 성공/실패 판단
- 비즈니스 목표에 의한 관리 : 비지니스 능률을 얼마나 향상시켰는가에 따라 프로젝트의 성공/실패 판단
- 품질에 의한 관리 : 제품의 품질 속성을 얼마나 많이 달성했는가에 따라 프로젝트의 성공/실패 판단
솔직히 일정에 의한 관리 방식을 버린다는 게 막막하기만 하지만, 저번 글에서 얘기한 것처럼, 단순히 가로등 밑이 밝다는 이유로 가로등 밑에서 열쇠를 찾고 있었던 것은 아닌지 생각해 봐야겠다.
소프트웨어 공학의 사실과 오해 1 – 작업 환경
http://www.yes24.com/24/goods/1418676
작업 환경
유명한 책인데 이제야 기회가 되어서 읽어봤다. 역시나 개발자면 누구나 읽어야 할 필독서라는 생각이 든다. 다시 한 번 훑어보면서 감명받은 부분을 정리하는 중.
“단단한(hard) 것이 부드러운(soft) 것을 몰아낸다.”는 옛 말이 있다. 즉 정확하게 측정 가능한(단단한) 것은 그렇지 못한(부드러운) 것에 대해 관심을 가지지 못하도록 하는 경향이 있다. 이 자명한 논리가 소프트웨어 분야에만 국한되는 것은 아니지만, 여기서는 특히 의미가 있는 것 같다. 사무실 공간은 측정하기 쉽다. 생산성 이득은 측정하기 어렵다. 어떤 것이 이기겠는가?
p.45
충분한 사무실 공간이 업무 효율을 높인다는 점을 대부분 알고 있지만, 사무실 공간을 할당할 때가 되면 가능한 많은 자리를 만드려는 생각으로 되돌아간다면서 나온 얘기다.
내 생각에는 일정과 품질도 비슷한 관계인 것 같다. 일정은 측정하기 쉽지만 품질은 측정하기 어렵기 때문에, ‘품질을 만족했는가?’ 보다는 ‘일정내에 마쳤는가?’와 같은 기준이 주로 사용되고 있다. 열쇠는 다른 곳에서 잃어버리고, 가로등 밑이 밝다는 이유만으로 가로등 밑에서 열쇠를 찾고 있는 바보이야기(p.33)가 남의 이야기가 아니다. -_-;;