RobertLGlass / @parkh37t
이책은
- 먼저, 사실에 대해 토의하고, 그다음 이사실과 관련된 논쟁을 제시하며, 마지막으로, 사실과 관련된 정보의 출처, 전경과 배경에 대한 참고문헌을 제시한다.
어떤 자료는 소프트웨어 공학에서도 오래된(그러면서도 자주 잊혀지는)것들이고, 어떤 자료는 최신이다. 물론 둘다 해당하는 것도 있다.
이책은, 55개의 사실을 아래와 같이 몇가지 카테고리로 분류 했다.
1. 관리
2. 생명주기(Life Cycle)
3. 품질
4. 연구
오해 편,
1. 관리
2. 생명주기
3. 교육
뛰어난 관리자가 뛰어난 기술보다 중요하다. 이는 역자 또한 인정하고 싶지 않은 대목이지만, 나 또한 동감하는 것이다.
역자(개발자 출신)가 말하는 것은, 관리자로서 가야 됨이 맞는데도 불구하고 스스로의 기술을 버리고 싶어하지 않는 다는 두가지의 이유를 말한다.
첫째, 나는 내가 직접 하고 싶었지, 다른 사람이 하도록 지시하고 싶지 않았다.
둘째, 나는 내가 마음대로 결정할 수 있는 자유를 원했지, 중간에서 자기 위에 있는 관리자의 결정을 가끔 전달만 하는 관리자가 되고 싶지 않았다.
어떻게 기술자가 관리자 보다 결정을 내리는 데 더 자유로운 위치에 있을 수 있겠는가?
소프트웨어에서 매우 중요하면서도 자주 잊어버리는 것은 관리와 관련된 것이다.
불행하게도, 관리자들은 종종 상식과 식상한 조언으로 인한 복잡한 상황에 처해, 세부적인 문제와 다음과 같이 꼭 기억하고 있어야 하는 매우 중요한 사실에 대한 시각을 잃는다.
[사람]
- 중요한 것은 사람이다. -> 절대 공감이다.
- 어떤 사람은 다른 사람보다 놀라울 정도로 뛰어나다
- 많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.
[도구와 기술]
- 과대 광고는 득보다 해가 된다.
- 새로운 접근방법으로 전환하면, 처음에는 효율이 향상되기보다 저하 된다.
- 최신의 도구나 기술이 실제로 사용되는 경우는 드물다.
[추정(estimation)]
- 우리의 추정은 부정확한 경우가 많다.
- 추정 작업을 위한 프로세스 또한 형편없다.
- 이런 허술한 추정 목표를 달성하는 데 실패한 것과, 이보다 훨씬 중요한 프로젝트의 실패를 동일시 한다.
- 추정을 사이에 두고 경영진(또는 영업자)과 기술자 사이에 단절이 존재한다.
[재사용(reuse)]
- 우리는 오랫동안 재사용을 해왔다.
- 최근 재사용은 거의 진전을 이루지 못했다.
- 일부 사람들은 재사용에 지나치게 큰 기대를 한다.
[복잡성(complexity)]
- 소프트웨어 구축의 많은 문제는 복잡성에 기인한다.
- 복잡성은 매우 빠르게 증가한다.
- 이 복잡성을 극복하기 위해서는 매우 뛰어난 사람들이 필요하다.
[사람]
'꼬마 바보' 꼬마 바보가 가로등 아래서 뭔가를 찾는 것 같았다. 뭘 하고 있냐고 묻자, '열쇠를 잃어버렸어요.'하고 대답했다.
'어디서 잃어버렸는데?' 꼬마 바보는 손가락으로 가리키며 말했다. '저쪽에서요.' '그럼 왜 이 가로등 밑에서 찾는거지?'
꼬마 바보는 대답했다. '이쪽이 더 밝기 때문이죠.'
우리는 모두 마음속으로는 기술자라고 생각하며, 우리의 작업을 쉽게 하는 새로운 기술을 고안하는 것을 더 좋아한다.
마음속 깊은 곳에서는 사람과 관련된 문제가 더 중요하다는 것을 알면서도 말이다.
작업환경은 생산성과 품질에 지대한 영향을 미친다.
- 단단한 것이 부드러운 것을 몰아낸다는 말이 있다. 즉 정확하게 측정 가능한(단단한) 것은 그렇지 못한 (부드러운) 것에 대해 관심을 가지지 못하도록 하는 경향이 있다. 이 자명한 논리가 소프트웨어 분야에만 국한되는 것은 아니지만, 여기서는 특히 의미가 있는것 같다.
사무실 공간은 측정하기 쉽다. 생산성 이득은 측정하기 어렵다. 어떤 것이 이기겠는가?
[도구와 기술]
한 제약회사가 SAP 패키지를 설치한 다음 이로 인한 이득이 즉각적으로 나타날 것이라 생각하고는 몇몇 계약자에게 낮은 가격으로 입찰했다.
학습곡선 기간은 늦었고, 이 회사는 파산과 소송의 소용돌이 속에서 사라졌다. 새로운 접근방법이 처음부터 이득을 준다는 가정은 매우 위험하다는 게 여기서 얻을 수 있는 교훈이다.
소프트웨어 개발자들은 도구에 대해 많은 말을 하지만, 그 중 일부만을 평가해보고, 구입하는 것은 얼마 되지 않으며, 실제로 사용하는 것은 거의 없다.
즉 소프트웨어 개발자들에게 도구는 장난감이다. 그들은 새로운 도구에 대해 배우고, 사용해보고, 구입하는 것을 좋아한다. 그런데 그 다음 재미있는 현상이 발생한다. 이런 도구들이 거의 사용되지 않는다는것이다.
[추정]
프로젝트가 폭주하는 가장 흔한 원인 두가지 중 첫번째는 형편없는 추정이다.
폭주하는 프로젝트란 시간이 지나면서 통제를 벗어나는 프로젝트를 말한다. 많은 경우 아무런 결과물도 많들어내지 못한다.
결과물을 만들어낸다 하더라도 일정과 예산을 초과하는 경우가 허다하다. 이런 경우 회사로 보나 개인적으로 보나 많은 피해가 뒤따른다.
어떤 프로젝트는 '죽음의 행진(Death marches)'이라고 불린다. 또 어떤 프로젝트는 '고난 모드(Crunch mode)' 에서 작업하는 것으로 표현된다.
어떤 식으로 불리든, 결과가 어떻든, 폭주하는 프로젝트는 보기 좋은 광경이 아니다.
소프트웨어 공학 분야에서는 이런 폭주의 원인이 무엇이길까에 대한 질문이 자주 있었다고 한다.
하지만 답하는 사람의 개인적인 주관에 기초하는 경우가 많았다. 어떤 사람들은 적절한 방법론의 부재가 폭주를 야기한다고 하고,(물론 이런 사람은 방법론을 파는 사람일것이다.)
어떤 사람들은 좋은 도구가 없기 때문이라고 말한다. 또 어떤 사람들은 프로그래머들에게 훈련과 주의가 부족하기 때문이라고 말한다.
일정에 의해 관리한다는 것은 여러개의 장기, 단기 Milestone(또는 아주 작은 것은 inch-pebbles)을 구성하고 그 일정상의 어느 시점에 발생하는 상황에 따라 프로젝트가 성공적으로 진행 되고 있는지 아닌지 결정하는 것을 위미한다. 만약 예정보다 늦게 Milestone에 도달 했다면, 프로젝트에 문제가 생긴 것을 의미한다.
소프트웨어 프로젝트를 어떤 방법으로 관리할 수 있을까?
1. 제품에 의한 관리 : 최종 제품을 어느정도 사용할 수 있고 어느정도 작동하는 가에 따라 프로젝트의 성공 또는 실패를 말할 수 있을 것이다.
2. 이슈에 의한 관리 : 프로젝트를 수행하는 동안 항상 발생하는 이슈를 얼마나 빠르게 잘 해결하는가에 따라 프로젝트의 성공 또는 실패를 말할 수 있을 것이다.
3. 위험요소에 의한 관리 : 프로젝트 초기에 확인 된 위험요소가 적절히 해결되었는지를 보여주는 일련의 시험을 통해 프로젝트의 성공 또는 실패를 말할 수 있을 것이다.
4. 비즈니스 목표에 의한 관리 : 해당 소프트웨어가 비즈니스의 능률을 얼마나 향상 시켰는가에 따라 프로젝트의 성공 또는 실패를 말할 수 있을 것이다.
5. 품질에 의한 관리 : 제품의 품질 속성을 얼마나 많이 달성했는가에 따라 프로젝트의 성공 또는 실패를 말할 수 있을 것이다.
<실험 #1>나는 참석자들에게 적은 양의 작업을 수행해 달라고 요청했다.
그리고는 고의로 지나치게 많은 작업을 주고 시간은 충분히 주지 않았다. 나는 참석자들이 이 모든 작업을 제대로 수행하려 노력할 것이기 때문에 시간이 바닥나서 미완성 제품을 만들어 낼 것이라 예상했다. 그러나 그렇지 않았다.
참석자들은 불가능한 일정을 맞추기 위해 무척이나 고생하며 작업했지만, 완성된 것처럼 보이기만 하고 제대로 작동하지 않는 대략적이고 겉만 그럴싸한 제품을 만들어냈다.
이는 오늘날 우리 문화에서 사람들은(불가능한)일정을 맞추기 위해 무진장 노력하느라 목적 달성을 위해 완성도와 품질을 기꺼이 희생시킨다는 것이다. 즉,
동기 자체가 잘못 됐기 때문에 아무렇지도 않게 잘못된 행동을 한 것이다.
<사례 #>소규모의 팀 조직에서 프로젝트 예산과 일정 초과 원래의 추정 규모보다 소프트웨어 및 Firmware 초과 하지만 프로젝트는 성공적으로 완료 됐다?
- 제품은 의도한 대로 잘 작동했다.
- 제품을 개발하는 것은 기술적 도전이였다.
- 팀의 규모는 작았지만 높은 성취도를 보여 주었다.
- 지금까지 같이 일해본 경영진 중 가장 좋았다. 좋은 설계를 만들어낼 수 있는 자유가 있었고, 범위 변경도 없었으며, 일정으로 압박하지도 않았기 때문이다.
<덧붙임(프로젝트가 늦어진 이유에 대한 견해)>
- 일정에 대한 추정이 비현실적이였다!!!!
- 자원, 특히 전문적인 조언이 부족했다.
- 처음에는 범위가 제대로 파악 되지 않았다.
- 프로젝트가 늦게 시작됬다!!!!
이 모든 것이 프로젝트 초기에 대한 사실이라는 것이 흥미롭다.
[재사용]
기존 소프트웨어를 수정하는 것은 어렵다. 그 근본적인 문제는 소프트웨어 유지보수 작업을 연구한 사람들은 소프트웨어 수정 작업을 압도할 정도로 훨씬 어려운 작업이 있다는 것을 알게됐다. 그것은 '기존 솔루션을 이해햐는 것' 이다.
"벤더(vendor)가 생산한 패키지 소프트웨어 시스템을 수정하는 것은 대부분 과오를 범하는 일이다." 나이쓰!!!!!
[복잡성]
문제의 복잡성(Complexity)이 25% 증가하면 소프트웨어 솔루션의 복잡성은 100% 증가한다.
- 왜 그렇게 사람이 중요한가? 복잡성을 극복하는 데는 상당한 사고력과 기술이 필요하기 때문이다.
- 왜 그렇게 추정이 어려운가? 단순해 보이는 문제도 그 솔루션은 훨씬 복잡할 수 있기 때문이다.
- 왜 대규모 재사용은 성과가 좋지 않을까? 복잡성이 다양성을 증대시키기 때문이다.
- 왜 요구사항은 폭박적으로 증가하는가(요구사항을 설계로 옮겨가면 명시적explicit 요구사항은 실제 설계에 필요한 훨씬 더 많은 잠재적im;licit 요구사항을 수반한다.)? 25% qnqnsdptj 100% 부분으로 옮겨가는 중이기 때문이다.
- 왜 하나의 문제에 대한 솔루션을 설계하는데 서로 다른 올바른 접근 방법이 그렇게도 많이 존재하는가? 솔루션 공간(Solution space)은 매우 복잡하기 때문이다.
- 왜 최고의 설계자는 반복적, 경험적(heuristic) 접근방법을 사용하는가? 단순하고 명확한 설계 솔루션이 있는 경우는 거의 없기 때문이다.
- 왜 설계는 최적화되는 경우가 거의 없는가? 상당한 복잡성 때문에 최적화는 거의 불가능 하기 때문이다.
- 왜 100% 테스트 커버리지는 거의 불가능하고, 테스트는 어떤 경우든 부족한 것인가? 프로그램 내의 너무나 많은 실행 경로와 소프트웨어의 복잡성으로 인해 테스트 커버리지가 잡아내지 못하는 오류가 있기 때문이다.
- 왜 검사(INSPECTION)가 오류 제거에 대한 가정 효과적, 효율적인 접근 방법인가? 그 모든 복잡성을 걸러내고 오류의 위치를 찾는 데는 결국 사람의 노력이 필요하기 때문이다.
- 왜 소프트웨어 유지보구에 그렇게도 많은 시간이 소모되는가? 초기 단계에 문제의 솔루션에서 파생될 모든 가능성을 결정하는 것은 거의 불가능하기 때문이다.
- 왜 '기존의 제품을 이해하는 것'이 소프트웨어 유지보수에서 가장 중요하고도 어려운 작업인가? 하나의 문제를 해결하는 데도 적용할 수 있는 접근방법이 매우 많이 때문이다.
- 왜 소프트웨어에는 그렇게 많은 오류가 있는가? 처음부터 소푸트웨어를 올발게 이해하는 것은 매우 어렵기 때문이다.
- 왜 소프트웨어 연구자들은 옹호에 치중하는가? 복잡한 소프트웨어 세계에서, 옹호보다 우선해 필요한 평가적 연구를 수행하는 것이 매우 어렵기 때문이다.
[요구사항]
프로젝트가 폭주하는 가장 흔한 원인 두가지 중 두번째는 불안정한 요구사항 이다.
불안정한 요구사항(낙관적 추정의 쌍둥이 악마)은 폭주하는 프로젝트의 좀더 복잡한 원인이 된다. 이 문제는 소프트웨어 솔루션의 고객과 사용자가 어떤 문제를 해결해야 하는지에 대해 확실하게 알지 못한다는 사실에서 기인한다. 그들은 처음에는 해결하려는 문제를 안다고 생각하지만, 프로젝트가 진행되면서 문제를 지나치게 단순하게 또는 비현실적 으로 봤거나, 풀료고 한 문제가 그들이 기대했던 것이 아니었음을 깨닫게 된다.
초기에 요구사항 오류를 제거하기 위해서는 요구사항 정제기법을 비중있게 사용해야 한다.
[Requirement-cleansing techniques]
1. 요구사항 일관성 검사
2. 요구사항 검토(고객, 사용자와 함께 잘못 전달 됐거나 명확한 실수를 분석하고 정정함)
3. 요구사항에서 파생되는 초기 테스트 케이스 설계
4. 테스트 가능한 요구사항 고려
5. 초기 요구사항의 타당성 검사를 위한 모델링, 시뮬레이션, 프로토타이핑
6. 정형명세 기술(이것을 믿는다면, 정형성은 명세를 정의하는 데 있어 엄격함을 요구하기 때문)
누락 된 요구사항은 가장 수정하기 힘든 오류다.
'가장 제거하기 어려운 소프트웨어 오류(모든 테스트 프로세스를 빠져나가 제품으로 출시된 소프트웨어에서도 존재하는)는 누락된 로직 오류다. 누락된 요구사항은 누락된 로직을 초래한다.'
[테스트]
프로그래머가 완전히 테스트 했다고 믿는 소프트웨어도 보통은 로직 경로의 55~60%만 테스트 된 경우가 많다. 커버리지 분석기와 같은 자동화 도구를 사용하면 이 비율을 대략 85~90%까지 높일 수 있다. 소프트웨어 로직 경로를 100% 테스트 하는 것은 거의 불가능 하다.
1. 요구사항 중심의 테스트
2. 구조적 테스트
3. 통계적 테스트
4. 위험요소 중심의 테스트
[유지보수]
소프트웨어 유지보수에 얼마나 많은 비용과 시간이 소모되는지에 대한 것이다. 평ㄱㄴ적인 소프트웨어 제품의 구축에 드는 시간과 비용은 20~60% 정도다.
그 외의 40~80%는 유지보수가 차지한다. 즉, 소프트웨어 유지보수는 소프트웨어 생명주기의 대략 60%를 차지한다.
[품질]
소프트웨어 품질 정의 속성
1. 이식성(portability)은 다른 플랫폼으로 쉽게 이식할 수 있도록 소프트웨어를 구축하는 것에 대한 것이다.
2. 신뢰성(reliability)은 소프트웨어 제품이 원래 의도대로 작업을 믿을 수 있게 처리하는가에 대한 것이다.
3. 효율(efficiency)은 소프트웨어 제품이 실행 시간과 사용 공간에 있어 얼마나 효율적인지에 대한 것이다.
4. 인간공학(human engineering, 사용 편의성'usability'이라고도 함)은 소프트웨어 제품이 얼마나 사용하기 쉽고 편리한지에 대한 것이다.
5. 테스트 용이성(testability)은 소프트웨어 제품을 쉽게 테스트 할 수 있는지에 대한 것이디ㅏ.
6. 이해 용이성(understandability)은 유지보수하는 사람이 소프트웨어 제품을 이해하기 쉬운지에 대한 것이다.
7 수정 용이성(modifiability)은 유지보수하는 사람이 소프트웨어 제품을 수정하기 쉬운지에 대한 것이다.
'신뢰성 - 오류는 뭉치는 경향이 있다.'
소프트웨어 제품 내의 오류는 분명 뭉텅이로 발견되는 경향이 있다. 왜 오류는 뭉치는 것일까?
이는 위험요소가 결국 현실화 된것을 뜻하며 연관된 모든 프로세스가 뭉치는 것을 말한다.
[오해의 몇가지]
Tom DeMarco 의 저서에는 '측정할 수 없는 것은 통제할 수 없다. 고 했는데 이것이 그의 추종자들에 의해' 측정할 수 없는 것은 관리할 수 없다.' 로 곡해 됬다.
논쟁 : '측정할 수 없는 것은 관리할 수 없다.'는 말은 틀리다. 우리는 늘 측정할 수 없는 것을 관리한다.
그러나, 이말이 오해라고 해서 그 밑바닥에 있는 메시지의 진실까지 거부해서는 안된다. 데이터를 가지고 관리하는 것은 데이터 없이 관리하는 것보다,
훨씬 쉽고 효율적이다. 사실, 뭔가를 이해하는데 숫자의 도움을 활용하는 것은 관리자의 본성이자 인간의 본성이다.
다시 정리하자면 '측정할 수 없는 것은 통제할 수 없다' 이며 '측정할 수 없을 관리한다' 이다.
'보는 눈이 많으면, 모든 버그는 그 깊이가 얕다' ? 즉, '충분히 많은 사람이 코드를 보면, 모든 오류가 발견될 것이다.' 라는 뜻인데,
오류의 깊고 얕음은 그것을 찾고자 하는 사람의 수와는 관계가 없으며, 검사(inspection)에 대한 연구에 따르면, 검사에 참가자의 수가 늘어남에 따라 발견되는 버그 수는 급격히 줄어들기 때문이라고 주장한다.
"현실의 여러 가지 까다로운 사실로 인해 아름다운 이론들이 무참히 짓밟힌다."
