 |
|
난이도 : 초급 Gary Pollice, 교수, Worcester Polytechnic Institute
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 6 월 24 일 
Rational Edge에서: 소프트웨어 개발이 공학이냐 아니냐를 놓고 수십년 동안 논쟁이 계속되어 왔습니다. 소프트웨어 공학 교수가 이 주제에 대해 학생들 의견을 요약 정리했습니다.
The Rational Edge에서 발췌.
 애자일 공동체를 위한 전자 잡지인 애자일 저널 11월호에 Daryl Kulak이 쓴 "소프트웨어 공학이라는 용어를 묻어버리자"
1
라는 기사가 실렸다. 이 기사를 읽고 처음 드는 생각은 다음과 같았다. "여기 또 애자일 광신도가 하나 등장해 모든 가치있는 작업은 애자일뿐이라고 생각하는구만." Mr. Kulak이 쓴 기사에 반박 글을 쓰려고 준비하면서 다시 한번 이 기사를 읽었을 때, 뭔가 생각할만한 내용이 있다는 사실을 찾아냈고, Kulak이 독자에게 전달하려고 마음먹은 내용이 무엇인지 의심하기 시작했다.
여러 독자들이 Kulak이 쓴 기사를 읽고서 떠올리는 관점과 가치가 다양함을 깨달았다. 교사로서 나는 현재 소프트웨어 공학을 배우는 학생들이 어떻게 생각하는지 알고 싶어졌다. 이 달에는 내가 가르치는 학생들이 찾아낸 사실과 이 기사에 대한 반응을 공유해 소프트웨어 공학을 이해하는 데 도움을 주고자 한다.
세부 사항으로 들어가기 앞서, Kulak이 쓴 기사에 대한 내 입장과 이 기사에서 내가 느낀 문제점을 정리하겠다. 그리고 나서 학생들에게 제시한 과제와 이런 과제를 낸 이유에 대해 설명하겠다. 마지막으로 몇몇 학생이 정리한 내용을 보여주겠다. 과제를 파고들다 보면 여러분 관점을 다시 한번 정리할 계기가 만들어질 것이다.
맥락 다지기
Kulak이 자신의 기사 제목을 "소프트웨어 공학의 오해"나 "모든 소프트웨어 개발이 공학을 요구하지는 않는다"라고 붙였다면, 그다지 강하게 반발하지 않았을지도 모른다. 하지만 Kulak은 그렇게 하지 않았고, Kulak이 쓴 기사를 읽다 보면 금세 마음 속에서 붉은 깃발이 여기저기 올라오고 만다. 내 칼럼을 한동안 읽은 독자라면, 내가 소프트웨어 개발에 실용주의 노선을 견지한다는 사실을 알고 있을 것이다. 상식에 기반을 두고 내 의견을 뒷받침하며 오늘날 유행하는 특정 방법론을 종교 수준으로 맹신하지는 않는다.
2
종종 소프트웨어 공학 방법을 가르치는 도중에 많은 학생들이 향후 경력을 밟으면서 결코 사용하지 않을 내용도 다루기 마련이다. 하지만 나는 건전한 공학 방법론을 사용해 프로그램을 분석하고 설계하며, 각자 상황에 맞춰 방법을 수정하는 능력을 심어주려고 노력해왔다.
그래서 Kulak은 첫 단락부터 내 눈길을 끄는 내용을 전개했다. "우리 직업을 묘사하기 위해 공학이라는 단어를 사용함으로써, 우리는 스스로를 정적인 프로세스와 변화를 일상 생활에 스며들게 하는 대신, 변화를 억누르려는 경향이 있는 불안정한 팀 구조에 묶어버린다. Kulak은 기사에서 "공학"이라는 단어가 무엇을 의미하는지 한번도 정의하지 않는다. 대신 이 용어가 의미하는 바를 독자들이 알고 있다고 가정한다. 한 걸음 더 나가 Kulak은 독자들이 자신과 똑같이 "공학"에 대한 개념을 잡고 있다고 가정한다.
물론 소프트웨어 공학과 다른 공학 분야 사이에 차이점이 있음은 사실이다.
3
우리는 소프트웨어 공학을 다양한 방법으로 정의해 왔으며, 이 주제에 대한 학생들의 연구 결과를 보면 알 수 있듯이, 몇몇 정의는 고려 대상에 넣어야 한다. 또한 학문으로서 공학이 여러 세기에 걸쳐 자리잡아 왔으므로, 소프트웨어 공학에 대해 좀 더 보편적인 정의를 내리려면 갈 길이 멀다는 점도 사실이다.
틀림없이 몇몇 공학 분야는 다른 공학 분야와 비교해 변화에 취약하다. Kulak 기사에서 주요 예제로 삼은 교량 건설은 프로젝트 도중에 변화를 허용하지 않으려고 노력한다. 강을 건너는 다리를 절반 정도 건설해놓은 상태에서 고객이 좀 더 하류로 옮기는 편이 좋겠다고 결정하는 상황에 부딪히기를 바라는 사람이 있을까? 변화를 억누르는 이유는 불리한 경제적인 영향력이 변화에 대한 이익을 상쇄하기 때문이다. 물론 군대에서 요구하는 이동식 교량을 만든다면
4
, 고려해야 하는 변경 사항이 상당히 많아 보인다. 내가 상상할 수 있는 몇몇 변경 요소는 다리를 놓은 다양한 지역, 다리를 전개하는 데 사용하는 차량이나 병사 유형 등이 있다. 실제로 이런 교량을 설계하는 공학도라면 재사용, 비용 절감을 위한 외부 부품을 집중 고려하며, 똑같은 부품으로 활용도가 높은 교량 가족을 만들어내는 능력을 보유하고 있을지도 모를 노릇이다. 이는 내게 소프트웨어 프레임워크 생성처럼 들린다.
다음으로 Kulak은 사람들 사이에 존재하는 차이점을 논하는데, 또 한번 이 친구가 검증되지 않은 일반화를 부르짓는 듯이 들린다. Kulak은 "우리 대다수는 제품에 집중하기보다는 사람에 집중한다"라고 말한다. 특히 컨설턴트를 위시해 많은 소프트웨어 개발자가 좀 더 사람에 집중한다는 사실에 동의하지만 내가 일했던 대다수 소프트웨어 개발자는 이런 범주에 얽매이지 않는다. 내가 만난 대다수 훌륭한 소프트웨어 개발자는 사람과 제품 사이에 균형을 잘 잡았다. 내가 만난 훌륭한 토목, 기계, 전자 공학도 대다수도 마찬가지였다.
내가 Kulak 기사를 읽으면서 떠오른 또 다른 쟁점이 있다. Kulak은 공학은 공학 조직 구조(사람)와 프로세스와 상태를 수반하며, 이런 조직은 "작업이 즐겁지 않은 장소"라고 가정한다. 상황이 이 정도라면 엔지니어링 회사에 입사 원서를 넣을 사람이 누가 있겠는가? 실제로 내가 아는 공학자들은 인기도 많았고, 자기 직업도 즐기는 듯이 보였다.
마지막으로 Kulak은 자신의 진짜 의도를 밝히는 힌트를 말한다. "극소수 사람조차도 더 이상 사용하지 않는 용어를 피해야 한다고 도시락 싸들고 다니며 말리는 이유는 무엇일까? 실제로 용어가 우리 팀에 영향을 주는 만큼 용어 자체는 문제가 되지 않는다. 우리가 우리 스스로를 공학도로 생각하면 할수록, 우리 해법과 프로세스와 사람을 공학적으로 만들기 때문이다."
이 기사에서 동의하지 않는 다른 내용도 많으며, 내가 주장하는 바를 찾을 수 있으리라는 생각이다. 하지만 내 학생들이 이 기사에 어떻게 반응할지 궁금해졌다. 정말로 이 기사 결론에 학생들이 동의하는지, 그렇지 않은지는 중요하지 않다. 학생들이 기사를 읽고, 결론을 내리며, 결론을 뒷받침하는 증거를 찾을 수 있는지 보고 싶었다. 내 학생들이 일궈낸 성과에 자부심을 느낀다.
과제
학생들에게 제시한 과제 내용은 다음과 같다.
"소프트웨어 공학이라는 용어를 묻어버리자"라는 기사를 읽고서, 여기에 대한 비평을 써보자. 저자 결론과 동의하는지, 동의하지 않는지 밝히고 이유를 설명하고, 여러분 의견을 뒷받침하는 참고 자료를 제시한다. 보고서를 읽는 독자를 설득하기 위해 다음과 같은 방식을 따르자.
- 기사를 읽고 이해한다.
- 저자가 내린 결론에 대해 충분히 생각하고 논리적으로 주장을 분석한다.
- 이 주제에 대해 연구하고 여러분이 찾아낸 증거를 바탕으로 결론을 내린다.
다른 모든 과제와 마찬가지로, 철자 잘못이나 문법적인 오류가 있을 경우 점수를 깎는다는 사실을 학생들은 알고 있었다. 소프트웨어 개발자와 엔지니어는 말뿐만 아니라 글로도 의사소통이 자유로워야 한다고 믿는다.
결과
41명 학생 모두가 과제를 제출했다. 결론은 상당히 다양하지만 세 범주로 분류해 보았다.
- Kulak에 (거의) 완전히 동의하는 학생
- Kulak이 (소프트웨어 공학이라는 용어가 제대로 이해되지 못하며, 부정적인 내용을 함축한다고) 암시한 메시지에 동의하는 학생
- Kulak의 논쟁과 결론에 거의 대부분 동의하지 않는 학생
절반 이상(21명)이 세 번째 범주에 들었다. 8명은 Kulak에 동의하고, 나머지 20명은 두 번째 범주에 들었다. Kulak에 대해 동의하든 동의하지 않든, 대다수 학생은 기사를 읽고 생각하고 분석하고 분석 결과에 따라 결론을 내린 듯이 보였다. 독자들도 동의하리라 믿는다. 다음에 소개할 내용은 과제에서 발췌한 내용으로, 학생들이 따온 Kulak 기사에서 비슷한 부분에 따라 분류하려고 노력했다. 학생들의 동의를 얻어, 이름과 WPI(Worcester Polytechnic Institute) 졸업 연도를 밝혔다.
명확한 정의 부족
내 학생들은 대부분 기사를 읽고 나서 기반이 위태위태하다고 인식했다. Kulak은 결코 소프트웨어 공학이나 공학에 대한 정의를 내리지 않았다. 기본적인 용어에 대한 정확한 설명없이 어떻게 유효한 결론을 이끌 수 있을까? 따라서 학생 대부분은 이런 용어에 대한 정의를 찾아서 비평 과정에서 기본으로 활용했다.
Dickson McCannell(WPI '09)은 dictionary.com에서 세 가지 항목으로 된 공학 정의를 찾았다.
- 엔진, 교량, 광산, 배, 화학 공장 건설과 같이 물리학이나 화학 같은 순수 과학 지식을 실제 활용하는 기술이나 과학
- 공학자로서 행위, 작업, 직업
- 솜씨가 뛰어난 발명품, 교묘한 솜씨
다른 많은 학생과 마찬가지로 McCannell은 Kulak이 소프트웨어 개발자에게 필요한 덕목은 창의성임을 강조하고 공학은 창의성을 억누른다고 둘러서 말한 사실을 찾아냈다. McCannell은 Kulak이 "뭐라고 부르든 간에 소프트웨어 공학도에게 중요한 덕목은 창의성이라고 계속해서 강조한다. Kulak에 따르면 '창의성은 팀이 변화를 받아들이도록 만드는 유일한 방법'이며, 창의성을 발휘하지 못하는 집단은 변화를 수용하기가 어렵고 심지어 문제를 풀어내는 효율적인 방법을 찾기도 어렵다고 한다. 하지만 '공학'이라는 세 번째 단어 정의에 따르면 '솜씨가 뛰어난 발명품, 교묘한 솜씨'다. 여기에 창의성과 변화를 받아들인다는 의미가 없다면, 도대체 무슨 의미인가?"
Maurice Williams(WPI '08)는 공학 정의에 대해 짧지만 통찰력이 있는 논평을 했다. "'공학'이라는 단어를 어떻게 바꾸든 '설계와 건축'이라는 두 단어는 항상 따라나온다. 소프트웨어 업계에서 '설계와 개발'이라고 아주 잘 알려진 낱말이다."
여러 학생이 찾아낸 공학에 대한 또 다른 정의는 ECPD(Engineers Council for Professional Development)에서 내렸다. 이 단체에 따르면 공학이란 "구조, 기계, 장비, 제조 설비를 설계하거나 개발하기 위해 과학적인 원칙을 창의적으로 이용하거나 이런 원칙을 단독으로 활용하거나 섞어서 활용한다. 설계를 완벽하게 꿰뚫어 동일하게 동작하도록 만들거나 운영한다. 특정 운영 조건에서 동작 방식을 예측한다. 의도된 기능, 운영 경제성, 생명/재산 안전성에 충실한 활동이다"로 요약된다.
5
Galia Traub(WPI '09)은 ECPD 정의를 Kulak이 공학에 대해 내린 정의("정적인 프로세스와 변화를 일상 생활에 스며들게 하는 대신, 변화를 억누르려는 경향이 있는 불안정한 팀 구조")와 비교한다.
세부 지향
몇몇 학생은 소프트웨어 개발 분야에서 자리잡은 창의적인 자유 영혼과 암묵적으로 반대되는 개념인 세부 지향을 공학 특성으로 들고 나왔다.
Aleksandr Ostapenko(WPI '09)는 Kulak이 쓴 기사에서 가정한 공학 특성 중 몇 가지를 따와서 Kulak과 다른 결론을 내린다. Ostapenko는 이 기사가 품고 있는 가정이 교량 건축가는 질서 정연하고 꼼꼼해야 하며, 소프트웨어 개발자는 창의적이고 변화를 좋아하며, 세부 사항에 억눌려서는 안 된다라는 사실을 지적한다.
Ostapenko는 다음과 같이 말한다. "이론적으로 이런 사람들이 실제로 코드를 작성한다면 훌륭한 생각이다. 회사가 사람들을 제대로 다루고 훌륭한 생각이 넘치는 공학도로 꽉 차있다면, 생각을 현실로 구현할 수 있기 때문이다. 또한 개인적으로 질서 정연함은 어떤 분야에서 일하거나 꼭 필요한 기술이라고 생각한다. 질서 정연함은 개인의 창의성을 제약하거나 피상적인 제약을 가하지 못한다. 예를 들어, 일관성 있는 방식으로 정리된 코드를 작성하면 급히 서두느라 주석도 부족하고 적절한 들여쓰기도 되어 있지 않은 코드보다 훨씬 가치가 높다. 결국 소프트웨어 공학도에게 필요한 기술은 다른 분야의 사람들과 마찬가지로 균형이 잡혀야 한다." Ostapenko는 가치 제공 관점에서 공학이 의미하는 바를 이해하고 있다는 생각이 든다.
Greg Kinneman(WPI '10)은 같은 단락을 놓고 다음과 같이 논평했다. "Kulak이 주장한 내용 중 가장 큰 결함은 프로그래머와 달리 공학도는 '엄격하고, 정밀하고, 질서 정연'하다고 주장하는 점이다. 하지만 프로그래머는 어느 누구보다 코드에서 훨씬 더 정밀하다. 점이나 괄호 하나만 잘못 쓰더라도 전체 프로그램이 비정상적으로 종료할 것이다." Rob Wailing은 '결코 세부 사항에 놀랄만한 주의를 기울이지 않는 위대한 소프트웨어 개발자를 본 적이 없다'고 거듭 강조했다.
6
전형적인 공학 예제로 든 교량 건설
물론 공학은 여러 세기를 거쳐오면서 확장된 분야다. 기술이 발전함에 따라, 공학이라는 여러 갈래도 발전을 거듭했다. Kulak이 의문을 제시한 기사는 교량 건설이라는 수 많은 공학 활동 중에서 한 가지 예제만 사용했다. 놀랍지도 않게, 학생들은 이런 사실도 지적했다.
Christopher Smith(WPI '10)는 상당히 큰 변화를 다뤄야만 하는 여러 유형의 공학 프로젝트가 존재한다고 지적했다. Smith는 다음과 같이 말했다. "예를 들어, 전통적인 공학도에게도 새로운 비행기를 설계하거나 처음으로 우주로 날아오를 때와 같이 계속 바뀌는 요구 사항에 직면해 일하는 상황이 생긴다. 간단하게 정리하자면, 소프트웨어 공학이 좀 더 변경 가능성이 높지만, 여전히 공학에 있어 동일한 기본 원칙을 따르고 있다. 유일한 차이점이라고는 소프트웨어 공학도가 좀 더 자주 요구 사항을 다시 평가해 이를 토대로 작업해야 한다는 사실이다."
Billy Hnath(WPI '10)는 교량 건축가를 선택한 문제점에 대해 지적하면서 다음과 같이 말한다. "... 생산성을 위한 방법론과 지침을 고수하면서 틀을 깨는 사고가 가능한 개인은 아주 바람직하다. 이런 특성이 교량 건축가에 해당하지 않을지도 모르겠지만, 전자 공학도나 기계 공학도에게는 완벽한 요구 조건이다. 소프트웨어 개발자는 성공을 위해 이런 두 가지 특성을 모두 갖춰야 하지만, 대다수 공학도 역시 마찬가지다."
Kulak 기사에 대해 가장 핵심을 짚은 친구는 다음과 같이 이야기한 Chris Trufan(WPI '10)이었다. "Kulak은 교량 공학과 소프트웨어 공학이 같지 않다는 사실을 애써 증명했지만, 이는 이미 당연한 사실로 판명난 지 오래다."
하지만 유효한 내용도 있다
심지어 Kulak의 주장과 결론에 동의하지 않는 학생조차도 사람들이 공학도에 대해 생각하는 방식에 문제가 있다고 동의했다. 하지만 정답은 공학이라는 용어를 소프트웨어 개발에 적용하는 관례를 멈추는 선에서 그치는 대신 공학이 정말로 무엇을 의미하며, 공학이 소프트웨어 개발에 어떻게 적용되는지를 사람들에게 자각하도록 만드는 데 있다.
소프트웨어 공학은 틀림없이 오늘날 우리가 이 용어를 사용하는 방식에서 부정적인 어감을 풍긴다. 이는 전혀 새로운 현상이 아니다. 소프트웨어 개발이 공학 부문인지 아닌지를 놓고 여러 세기 동안 논쟁이 벌어져왔다. Jessica Doherty(WPI '09)는 초기 컴퓨팅 아버지인 Edgser Dijkstra가 다음과 같은 통찰력을 발휘했음을 지적했다.
Edsger Dijkstra와 같은 여러 컴퓨터 과학자는 Kulak의 주장에 동의한다(아니면 과거에 동의했다). Dijkstra는 소프트웨어 공학이 공학이 아니며, 단순한 과학임을 주장했다. Dijkstra는 몇몇 회사에서 작업에 대한 책임은 그대로 두면서 이유 없이 모든 "컴퓨터 프로그래머"를 "소프트웨어 공학도로" 승격시킨 상황을 예로 들면서 공학이라는 용어는 무의미하다고 설명했다. Dijkstra는 첫출근부터 프로그래밍 대신에 연필과 종이로 프로젝트를 분석하기 시작한 직원에 대한 문제점을 지적한다. 이런 직원은 "공학도"가 아니라 "프로그래머"를 원했기 때문에 회사가 제시한 보직이 생뚱맞게 되어버렸다. Dijkstra는 일반적으로 직원은 공학도 대신에 프로그래머를 원하며, 공학도를 중심으로 돌아가는 시장은 직원 요구를 만족시키지 못한다고 주장한다.
7
Nelson Nogueria는 소프트웨어 개발 공학으로 부를 수 있는 분야에 대해 의견을 제시한 (한편으로 잘 알려져 있고 다른 한편으로 덜 알려져 있는) 석학을 찾아냈다. "확실히 (IBM® Rational® UP나 RUP®와 같이
8
) 소프트웨어 공학도가 직면한 문제를 풀어낼 특정 방법이 존재하지만, 과업을 달성하는 과정에서 변화는 필수적이다. 실제 공학이 무엇인지를 놓고 벌어지는 논쟁은 끊임없이 일어난다. David Parnas는 소프트웨어 공학은 사실상 공학이라고 말했다.
9
Steve McConnell은 소프트웨어 공학은 공학이 아니지만 실제로 공학이 되어야 한다고 말했다. Donald Knuth는 프로그래밍을 예술과 과학이라고 말했다.
10
나는 소프트웨어 공학이 다양성을 발휘하며 끊임없이 바뀌는 분야이므로, 일어날 모든 가능성을 대비할만한 규칙 집합이 없다고 믿는다." 여기서 Nogueria가 배운 교훈은 소프트웨어 개발 접근 방법에서 프리 사이즈는 없다는 사실이다.
학문적인 접근 방법
몇몇 학생은 열성적으로 숙제를 마쳤으며, 다른 과목에서 배웠던 추론 기법을 활용하려고 노력했다.
Zachary Kleinfeld(WPI '08)는 원래 기사에서 모든 결함을 찾아내어 순서대로 소개하는 방법을 사용했다. Kleinfeld는 다음과 같이 말한다. "... 논쟁은 여섯 가지 측면에서 설득력이 떨어진다. 첫 번째로, '공학'이라는 정의를 임의로 해서 결론을 성급하게 내린다. 두 번째로, 잘못된 비유를 사용해 다른 공학 부문과 비교한다. 세 번째로, 소프트웨어 공학을 토목 공학에만 비교하며, 소프트웨어와 좀 더 비슷한 다른 기존 공학 부문을 무시한다. 네 번째로, 전제를 논리적으로 뒷받침하지 못하는 허깨비를 두고 논쟁을 벌인다. 다섯 번째로, 증거가 뒷받침하지 못하는 가정을 했다. 마지막으로 강력한 반대 증거를 무시했다."
학문적인 접근 방법 중에 내가 가장 좋아하는 예는 로보트 공학을 전공하는 Neal Humphrey(WPI '09)가 제시했다. Humphrey는 Kulak 기사에서 논리적인 오류를 찾아냈다. Humphrey는 다음과 같이 말한다. "Kulak은 (추론자가 논리적 추론을 좀 더 쉽게 공격할 목적으로 고의로 이를 왜곡하는 오류인) 허수아비 논법의 오류로 시작한다. 독자에게 공학과 관련이 있는 뭔가를 제시한 다음, Kulak은 이런 뭔가가 어떻게 소프트웨어 공학에 적용되지 않은지를 보여주려고 시도한다. 이를 허수아비 논법의 오류로 만드는 요인은 Kulak이 쉽게 공격 받을 생각에만 집중하기 때문이다. 그리고 나서 Kulak은 자신이 제시한 내용이 공학이라는 용어와 소프트웨어는 잘 맞지 않는다는 증거라고 말한다. 허수아비 논법을 사용했기 때문에, 공격받을 걱정이 든 Kulak은 양쪽 측면을 보여주는 과정을 생략했다." Kulak 기사가 진짜로 허수아비 논법을 사용한 예가 맞든 아니든 나는 내 학생이 다른 과목에서 배운 논리적인 사유를 통해 당면 문제를 해결하는 모습을 보며 무척 신선하다는 느낌이 들었다.
결론
학생들이 Kulak 기사에 대해 동의하든 동의하지 않든 내게는 그리 중요하지 않다. 나는 학생들이 진짜 문제점에 대해 생각하고 자기 의견을 확고히 하기를 원했다. 나는 항상 개인적인 성향과 생각을 의견이 아니라 사실을 토대로 학생들이 받아들이도록 주의 깊게 강의에 반영하고 있다. 이런 오류를 범하고 있지 않은지 살펴보기 위한 좋은 기회였다는 생각이다. 다행스럽게도, 내가 의견을 표명할 때, 학생들은 단순히 의견으로 받아들이는 듯이 보인다.
"소프트웨어 공학"이라는 용어와 관련해 Ms. Doherty는 가장 중요한 사실을 기술했다. "직원이 '소프트웨어 공학자', '소프트웨어 개발자', '코드 작성자' 중 어떤 감투를 썼든지 상관없이 회사가 훌륭한 방법을 활용한다면 훌륭한 소프트웨어를 성공리에 만들 수 있다."
주석
1
http://www.agilejournal.com/articles/articles/let%27s-bury-the-term-software-engineering.html를 살펴보자.
2 내가 2005년 12월에 쓴 기사인 소프트웨어 개발 대 소프트웨어 엔지니어링을 살펴보자. http://www.ibm.com/developerworks/kr/library/pollice/index.html
3 역시 내가 2005년 12월에 쓴 기사를 살펴보자.
4
http://www.army-technology.com/contractors/engineering/man/man3.html, http://www.baileybridge.com/, http://en.wikipedia.org/wiki/Pontoon_bridge를 살펴보자.
5 ECPD 정의는 http://www.britannica.com/eb/article-9105842/engineering을 살펴보기 바란다.
6 소프트웨어 개발자의 개인적인 특성은 http://www.softwarebyrob.com/2006/08/20/personality-traits-of-the-best-software-developers/를 살펴보기 바란다.
7
E. W. Dijkstra Archive. "There is still a war going on"(manuscript Austin, 1993년 12월 3일). http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html
8
http://en.wikipedia.org/wiki/Rational_Unified_Process
9 Parnas, David L. (1998). "Software Engineering Programmes are not Computer Science Programmes," http://citeseer.ist.psu.edu/parnas98software.html. http://en.wikipedia.org/wiki/David_Parnas
10 Donald Knuth, Computer Programming as an Art, http://faq.ktug.or.kr/faq/LiterateProgramming?action=download&value=knuth-turingaward.pdf
11
http://www.nizkor.org/features/fallacies/straw-man.html
참고자료
필자소개 | 
| | Gary Pollice는 메사추세스 주 우스터에 있는 우스터 폴리테크닉 대학에서 교수를 맡고 있다. Pollice는 소프트웨어 공학, 설계, 테스팅을 비롯해 다른 전산 과목을 가르치며, 학생들 프로젝트도 직접 챙긴다. 학계에 오기 전에, Pollice는 비즈니스 응용 프로그램부터 컴파일러와 각종 도구에 이르기까지 35년 동안 소프트웨어를 다방면으로 개발해왔다. 마지막으로 업계에 몸담은 곳은 IBM® Rational® 소프트웨어로, "RUP 구두쇠"로 알려져 있으며, 원래 Rational Suite 팀 일원이기도 했다. Pollice는 Addison Wesley 출판사가 2004년도에 출간한 Software Development for Small Teams: A RUP-Centric Approach 주요 저자이기도 하다. Pollice는 수학 학사와 전산학 석사를 취득했다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
