대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 PSP로 나도 SW 개발 전문가 III - 결함, 시간이 지나면 시간을 축 내는 버그다
등록일 조회수 5905
첨부파일  

PSP로 나도 SW 개발 전문가 III

결함, 시간이 지나면 시간을 축 내는 버그다



연재 순서

1회 개발자인가 소프트웨어 엔지니어인가?
2회 내가 계획한 일정, 관리자도 인정한다
3회 결함, 시간이 지나면 시간을 축내는 버그다
4회 나만의 프로젝트, 프로젝트 매니저로 가는 지름길이다
5회 열심히 일한 당신 떠나라! 당신의 미래를 위해서

한용수 | yshan@psptsp.com

현재 사단법인 소프트웨어공학협회 PSP/TSP 분과위원장으로 수회에 걸쳐 정통부의 지원으로 PSP/TSP 세미나 및 교육과정을 진행했고, 다양한 세미나를 통해서 국내 보급에 심혈을 기울이고 있다. 최근 비트교육센터에서 네트워크 전문가 과정에 PSP/TSP 과목을 강의하고 있으며, 또한 PSP/TSP 강사를 양성하기 위해 과정 설계 중이다

소프트웨어가 개발되면 반드시 통합 테스트나 인수 테스트를 하게 된다. 통합 테스트와 인수 테스트가 비교적 쉽게 끝나는 경우도 있겠지만 반드시 그렇지만은 않다. 이런 테스트 과정은 피를 말리는 과정인데 그 하나하나를 자세히 살펴보면 이번 시간의 제목과 같이 왜 결함이 시간을 축 내는 버그가 되는지 알 수 있을 것이다.

테스트 현장에서는

일반적으로 결함이 많으면 많을수록 개발 시간이 많이 걸린다. 개인적인 차이는 있겠지만 일반적으로 엔지니어, 초보자, 경험자 구분 없이 매 1000라인마다 평균 약 100개 가량의 결함이 생성된다. 많은 양의 결함이 컴파일과 단위 테스트에서 제거되지만 제거할 수 있는 비율(약 75%)은 제한되어 있다. 단위 테스트까지 작업은 엔지니어 자신이 책임지는 부분으로 문제가 없지만 단위 테스트에서 제거되지 않은 결함은 통합 테스트에서 엄청난 파장을 불러올 수 있다.


개발은 병렬, 테스트는 직렬

팀으로 개발할 때 처음에 여러 엔지니어가 자신의 프로그램만 집중한다. 그리고 목표 지점에 이르러선 늦게 오는 사람을 기다려야 한다. 늦게 오는 사람은 숨이 차서 허덕이고 있지만 도와주기 어렵다. 내용을 파악하고 있지 못하기 때문에 어떻게 도와 줄 수가 없다. 설계서가 있다면 참조할 수 있지만 바쁜 사람 불러 물어보진 못하고, 코드를 비슷하게 만들었다면 시간이 걸려도 확인해서 지원해 줄 수 있지만 그도 여의치 않다. 그냥 기다리는 수밖에 없다.

모든 엔지니어가 목적지에 도착하게 되면 이제는 통합 테스트를 시작하게 된다. 통합 테스트에선 여러 엔지니어가 작업한 결과를 모아서 하나하나의 기능을 테스트하게 된다. 테스트에서 결함이 발견되었다면 어떻게 되는가? 더 이상 테스트를 진행할 수 없는 경우가 종종 있다. 이 기능이 테스트를 통과해야 다른 기능들도 계속 테스트할 수 있지만, 다음 기능을 테스트할 수 없는 상황이 벌어지면 담당 엔지니어는 급하게 수정작업을 하게 된다. 빨리 수정이 될 수 있다면 다행이지만, 늦어지는 경우 다른 엔지니어는 무엇을 할 수 있을까? 아무것도 하지 못한다. 그렇다고 마음 편하게 쉴 수 있는 상황도 아니다. 그리고 수정작업이 완료되는 상황까지 기다려야 한다. 수정사항이 자신의 코드에도 영향을 미치는 요소인지 늘 관심을 가지고 지켜봐야 한다. 그렇지 않으면 자신의 프로그램과 충돌이 일어나는 경우도 있다.


앞으로 뒤로 수정의 반복

복잡한 시스템의 경우라면 테스트 과정의 수정에서 소프트웨어 기능들이 서로 충돌하는 경우는 더욱 큰 문제를 파생시킨다. 맨 마지막 부분을 테스트하는 과정에서 앞서 여러 엔지니어들이 프로그램 또는 자료를 수정하는 바람에 마지막 부분에서 수정 내용을 처리할 수 있도록 코드를 모두 수정해야 하는 상황이 벌어질 수도 있고, 마지막 부분의 프로그램은 정상인데 테스트 과정에서 수정한 다른 프로그램이 잘못된 것임이 확인되는 경우도 있다. 많은 노력을 들여서 수정했던 것을 복구하는 작업을 해야 한다면, 완벽하게 복구하고 결함을 정확하게 수정하기 위해선 몇 시간 혹은 며칠 전의 상황으로 되돌아가야 한다면 얼마나 억울한가! 되돌아가고는 싶지만 정확하게 어떤 상태였는지 기억할 수 없고, 설상가상으로 필요한 소스코드가 백업되어 있지 않다면 얼마나 시간을 더 투자해야 그리운 그 때로 되돌아 갈 수 있겠는가. 이 정도 되면 시간은 자정을 넘고 “오늘 마치고 아침에 다시 시작합시다”라는 이야기가 나오게 된다.


시스템 결함은 조직 결함으로

결함이 다른 결함을 만들어 낼 가능성은 시스템이 커질수록 더욱 증가한다. 결함으로 인해서 앞으로 수정, 뒤로 수정이 이루어지면 팀원들의 체력은 떨어지고 조직의 결합력은 급격하게 저하된다. 초기에 농담으로 할 수 있었던 이야기를 이제는 날카롭게 반응하게 된다. 소프트웨어 결함은 조직의 결함으로 작용하게 되면서 의욕을 상실하게 되고 쉽게 해결될 수 있는 일도 시간이 걸리고 소프트웨어는 체계를 잃어버리고 누더기가 되기 시작한다. 마무리가 되더라도 고객이 사용상 불편한 점이 있어도 개선하기 힘들고 유지보수 비용도 증가하게 된다. 엔지니어도 고객의 지속적인 요청사항을 견디지 못하고 이직을 고려하는 상황도 벌어진다. 이러한 조직결함이 생기는 것이 최근 소프트웨어 결함을 다루는 이유 중에 하나일 수도 있다.


엔지니어에게 품질은 시작과 끝

필자는 오랫동안 프로그램을 만들어 왔지만 소프트웨어에서 품질이라는 측면이 얼마나 중요한 역할을 하는지 구체적으로 알게 된 것은 놀랍게도 얼마 되지 않는다. 그렇다고 이전에 소프트웨어 품질이 나쁜 것은 아니다. 지금과 동일한 수준으로, 차이점은 좀 더 소프트웨어 특성을 정확히 파악할 수 있게 되었고 적용할 수 있었다는 것이다.


품질은 작업의 시작 조건이다

소프트웨어 개발을 요구하는 사람이 본인일 수 있지만 대개 타인으로부터 의뢰를 받게 된다. 직접 의뢰받기도 하지만 팀원으로서 참여하는 과정 자체가 의뢰를 받는 상황이 된다. 소프트웨어의 만족도는 내 자신의 기준이 아니라 타인의 기준에서 만족될 필요가 있다. 사용자의 눈높이에 맞는 소프트웨어를 만들어야 제품이 완전해질 수 있다. 초등학생 대상의 소프트웨어라면 그에 맞는 눈높이로 만들어야 하고, 전문가가 사용할 것이라면 그 수준에 맞춰야 한다. 소프트웨어에 맞춰 사람이 길들여질 수 있는 경우는 없다고 봐야 한다. 대개 커다란 변화를 원하지 않기 때문이다. 사용자의 환경과 이용 가능한 수준에 맞는 소프트웨어를 만들어야 최상의 품질을 갖출 수 있다.


품질은 개발 중에 계속돼야 한다

이런 요구사항에 맞춰 소프트웨어 개발은 거의 대부분 엔지니어의 수작업을 통해서 만들어진다. 엔지니어가 코드를 만들지 않으면 소프트웨어가 만들어지지 않는다. 이는 첨단 기술이 대신할 수 없다. 이러한 개발은 엔지니어가 인간이기 때문에 필연적으로 실수를 범할 수밖에 없고 예측하지 못한 기술적 문제나 환경적 제약을 극복해야 할 상황이 벌어지기도 한다. 개발완료까지 산을 넘고 물을 건너는 험난한 여행과도 같다.

이러한 소프트웨어 개발과정에서 수많은 결함이 생성되고 제거되면서 고객에게 인도될 소프트웨어가 만들어지게 된다. 잘못된 요구사항 혹은 설계를 가지고 개발하는 경우가 있다면 이러한 소프트웨어는 수많은 컴파일과 테스트를 거쳐서 완성되지만 결국은 무의미한 작업이 전 단계 작업 결과를 적용한 현재 단계의 결과를 만들고 현재 단계의 결과가 충분한지 검사해야 한다. 짧은 주기로 검증작업이 이루어져야 한다.


품질은 소프트웨어 폐기까지 따라 다닌다

어려운 산고 속에 만들어진 소프트웨어는 이런저런 사정으로 더 이상 사용하지 않을 때까지 계속 문제가 발생하는지 살펴봐야 한다. 폐기하는 단계에서도 종종 말썽을 부리는 경우도 있기 때문이다. PC라면 그냥 내놓기만 하면 끝날 것을 소프트웨어는 그 단순한 흔적조차 없이 깨끗이 정리될 때까지 독자들을 괴롭힐 것이다. 다양한 소프트웨어를 PC에 설치하고 제거작업을 하면 여러분의 PC는 대부분 성능저하 현상이 발생할 것이다. 경우에 따라선 며칠 동안 운영체제를 다시 설치해야 하는 경우도 발생할 수 있고, 때로는 더 이상 사용하지 않을 것 같은 소프트웨어라도 어떤 사용자는 사활을 걸고 찾아 나설 수도 있다. 우주선, 비행기 등 소프트웨어를 많이 사용하는 기계들은 비교적 오래된 하드웨어를 아직도 사용하고 있고 이러한 현상은 최근 선풍적인 임베디드 기기가 활성화되면서 폐기도 만만하지 않을 것이다.


Every bit, big trouble

신뢰할만한 소프트웨어는 모든 비트(bit)를 계획하고 원하는 방향으로 설정돼야 한다. 어떤 자료든지 코드가 완벽해야 한다. 그러나 소프트웨어는 점점 그 크기가 증가하고 개발자는 크기를 따라잡기 힘들다. 그래서 높은 생산성을 위해 다양한 툴과 상용 제품을 이용한다. 엔지니어 자신이 만든 코드에서 결함이 없어야 하겠지만, 상용 제품에서도 마찬가지로 결함이 없어야 한다. 간혹 이런 상용 제품에서도 오류를 경험하는 경우도 있다. 비트 하나가 잘못된 값이 들어가는 경우라도 여지없이 소프트웨어는 오류가 나타날 것이다. 그렇다고 모든 자료를 검증할 수 있는 방법도 없다. 일반적으로 고객에게 양도되는 소프트웨어는 1000라인 당 4개 이하의 결함이 있다고 한다. 운에 좋아서 결함이 나타나지 않기를 바랄 뿐이고 해결책을 찾지 못하고 임시방편으로 문제가 생기기지 않도록 시스템을 정기적으로 재가동시키는 사례도 흔하게 볼 수 있다.

<표 1> ISO9126 소프트웨어 품질 특성


품질은 고객 만족이다

소프트웨어 품질은 사업을 지속할 수 있는가를 결정하는 중요한 요소다. 사업을 시작하기 위한 요소로서 품질이 대두되는 것이 아니라 기업이 소프트웨어로 충분한 수익을 낼 수 있을 만한 좋은 제품이냐를 결정할 때 품질이 매우 중요한 요소로서 작용을 한다. 같은 노력을 해서 양질의 제품을 제공하게 되면 A/S가 줄고 고객만족도가 높아 시장 확대가 가능하다. 그러나 반대로 품질이 좋지 않은 것으로 인식된다면 비즈니스가 어렵다. 기업들은 품질을 제일 중요하게 생각하고 많은 비용을 들이고 있다. 품질을 중요시 여기는 기업의 공통적인 특징이 무조건 좋은 품질의 제품을 만들기 보다는 직원이 감동할 수 있으면 고객도 감동하는 제품을 만들 수 있다고 생각하고 있고 실제로 이런 생각은 많은 성과를 얻기도 했다.


소프트웨어 품질

소프트웨어의 품질은 다양한 내용을 담고 있다. 소프트웨어는 단순히 소프트웨어로서 이용되는 부분만 강조하지 않고 하드웨어와 네트워크를 포함하기도 한다. 그리고 운영체제와 타 소프트웨어까지 고민할 필요가 있다. 다양한 외부 장비를 지원해야 하는 경우는 더더욱 많은 것을 고민해야 한다. 소프트웨어 품질은 크게 두 가지로 구분된다. 기능적 측면과 비기능적 측면이다. 기능적 측면은 소프트웨어의 기능이 원하는 작업을 정확히 수행하는가를 표시하고 비기능적 측면은 기능을 수행하면서 응답은 빠른지, 항상 동일한 결과가 제공되는지, 안정성이 있는지 등 시스템적인 사항을 표시한다.

항상 기능성과 비기능성 품질요소를 완벽하게 모두 만족시킬 수는 없다. 예를 들어 보안성을 높이기 위해 데이터를 모두 암호화해 버린다면 암호화 처리에 많은 시간이 소비되어 응답 시간은 현저하게 저하될 것이다. 품질에 관련된 상세한 사항은 참고자료 ?을 보기 바란다.


어디까지 관심을 가져야 하는가?

소프트웨어 엔지니어는 많은 품질요소를 고려해야 하지만 모든 품질요소를 모두 만족시키는 시스템을 설계하기 위해선 많은 지식과 기술을 배워 적용해야 하기 때문에 몇 년간 필요한 기술을 익히느라 시간을 보내야 한다. 그러나 소프트웨어 엔지니어로서 가장 중요한 부분은 기능 부분의 품질에 집중할 필요가 있다. 그리고 소프트웨어의 성격에 의해서 핵심적인 부분이 선정될 것이다. 예를 들면 원자력 발전을 관리하는 소프트웨어라면 신뢰성을, 비행기와 같이 급변하는 환경을 다룬다면 응답성을, 업무용 프로그램이라면 사용성을 우선으로 고려해야 한다. 이러한 비기능성에 사용자가 관심을 가지는 시점은 소프트웨어의 기능이 정상적으로 작동할 때이다. 비기능성 품질 사항은 시스템 설계에 반영할 필요가 있고, 코드 개발에선 완벽한 기능을 구현할 수 있도록 초점을 맞출 필요가 있다.


어느 정도 완벽해야 할까?

일반적으로 고객에게 전달되는 소프트웨어의 품질은 1000라인 당 4개 이하의 결함이 있을 때 가능하다. 우주선을 발사하기 위한 프로그램은 Defect-free(무결함)가 확인되어야 하고 업무용 프로그램의 경우는 필요한 시기에 필요한 기능을 충분히 적용할 수 있겠다고 생각되면 고객에게 인도되어 바로 사용하게 된다. 그리고 나서 6개월 혹은 12개월 동안 고객과의 합의에 의해 발생하는 결함을 처리하고 유지보수할 수 있도록 계약을 한다. 패키지형 소프트웨어는 결함이 생기면 엔지니어가 결함을 수정하여 인터넷을 통해 패치 프로그램을 공급하면 문제를 해결할 수 있지만 내장형(임베디드) 소프트웨어는 업무용보다 높은 품질이 요구된다. 결함이 생기면 하드웨어를 가지고 가든가 아니면 엔지니어가 방문해서 수정을 해 줘야 한다. 제품의 특성에 따라서 다양한 결정을 할 수 있지만 엔지니어는 최선을 다해서 결함이 없도록 해야 한다.


결함을 제거하는데 한계가 있는가?

결론부터 이야기한다면 결함을 완벽하게 제거한다는 것은 불가능하다. 인간이 만든 제품에서 완벽하다고 평가된 제품은 없다. 소프트웨어 같이 복잡하고 다양한 기능은 눈에 보이지도 않기 때문에 결함이 있을 가능성은 매우 높아진다. 오랫동안 소프트웨어를 자동차나 건축물과 같이 일목요연하게 설계도나 모형을 통해서 그 세부 사항을 확인할 수 있는 방법을 찾고 있지만 워낙 복잡하고 표현이 어려워 이렇다 할 방법을 찾아내지 못했다. 이러한 한계는 엔지니어들이 겪는 일상적인 문제점을 들여다보면 더욱 확실하다.

신은 없다

프로그램을 만든다든가, 책을 저술한다든가, 계획을 수립한다든가 하는 경우 사람이 한 곳에 집중을 할 수 있는 시간은 얼마 되지 않는다. 한 시간 이상을 하나에 집중하는 경우는 매우 드물 것이다. 무언가 하고 있지만 머리에 스쳐가는 수많은 생각들은 우리의 생각을 흐트러 놓을 수 있다. 며칠 이상 작업이 지속되면 처음부터 일관성 있게 진행하는 것도 어렵다. 시간이 지나면서 새로운 내용을 학습하고 새롭게 적응하는 변화가 지속적으로 이루어지기 때문에 일관성을 유지한다는 것은 노련한 경우가 아니면 쉽게 이룰 수 없다. 망각이라는 것도 한몫을 한다. 관련된 모든 사항을 기억하고 있다가 필요한 시기에 완벽하게 적용할 수 있다면 결코 틀리는 일이 없겠지만 인간인 관계로 어쩔 수 없이 망각하고 다시 생각한다. 때로는 잘못된 기억an class="Sub2"> 미지의 세계

소프트웨어 기술과 적용 분야는 무궁무진하다. 동일한 소프트웨어를 만들어 본 엔지니어는 없을 것이다. 항상 새롭고 낯선 내용을 적용하는 엔지니어는 탐험가이기도 하지만 무모한 사람일 수도 있다. 개발과정에서 가능한 초기에 필요한 기술과 적용방법을 충분히 숙지하려고 하지만 실제 적용에 들어서면 생각 외로 많은 문제에 봉착하고 만다. 특히 신기술을 접목하는 경우 해법을 발견할 수 없는 상황이 많다. 이런 경우 다른 방법을 찾거나 우회를 하지만 그러는 과정에서 엔지니어는 많은 차선책을 찾고 적용하다 보면 개발 흐름이 흐트러지고 일정이 촉박하게 되어 다음 작업에 충분한 시간을 배려할 수 없는 상황이 발생한다.


찾고 싶은 것만 찾는다

프로그램을 작성하거나 글을 쓰고 나서 잘못된 부분을 스스로 찾으려고 노력했던 경험들을 대부분 가지고 있을 것이다. 그러한 노력으로 많은 문제점을 찾아내고 수정할 수 있다. 그러나 잠시 후 다시 찾아보면 또 수정할 것들이 계속 나타나고 더 이상 찾을 것이 없다고 생각(사실은 포기)하고 다른 사람에게 보여주면 그 사람은 여지없이 새로운 것, 그렇다고 어려운 것도 아닌 것을 너무나도 쉽게 찾아내고 만다. 사람은 항상 자신의 시각으로 문제를 바라보기 때문에 이처럼 글이나 프로그램에서도 역시 자신이 찾고 싶은 것만 확인할 수 있고 결함을 찾을 수 있다.


집단적 실수

여러 사람이 함께 결함을 찾는다고 모두 찾아낼 수 있을까? 이도 역시 아니다. 많은 사람의 손에 걸쳐 확인된 책들을 보자. 그 책들은 아무런 문제가 없는 것 같아 보이지만 시간이 지남에 따라서 한 개 두 개 결함들이 눈에 띄게 된다. 수학과 같이 계산식으로 일괄 적용될 수 있는 대상이라면 정확한 결과를 얻을 수 있지만 프로그래밍 언어(C/C++, 자바, 파스칼 등)도 하나의 언어로 분류한다면 책에서 오자가 생기듯이 결함이 발생할 수밖에 없다. 이러한 오류는 대부분 상대가 검토를 했으니까, 혹은 어느 정도 수준이 되니까 쉽게 보는 것만으로도 충분하다고 생각하는 경우가 많다.


의사소통, 커뮤니케이션

소프트웨어 규모가 커지면서 혼자 개발을 하는 것은 힘든 작업이 되고 있다. 그래서 대부분 팀을 갖춰 작업을 하게 되고 각자 개발 내용을 분담하게 된다. 주어진 개발 내용에 따라 개발을 완벽하게 하면 모든 일이 잘 될 것이라고 생각하지만 많은 경우 서로 다른 방법으로 해석해서 전혀 엉뚱한 결과를 만들 수 있다. 때로는 아주 기본적인 사항이라 언급하지 않았던 문제가 나중에 서로 다르게 인식하고 있던 문제로 판가름 나는 경우 엄청난 설전을 거친 후에 비로소 문제를 해결할 수 있는 실마리를 찾는 경우도 발생한다.


가면무도회

소프트웨어는 복잡한 움직임을 가지고 있기 때문에 결함이 다른 문제로 보여지는 경우가 있다. 그 실례로 지난 1997년 화성탐사선인 패스파인더에서 성공적으로 화성 사진을 보내왔다. 때때로 수신된 자료에서 일정 부분의 자료가 누락되는 현상을 발견했다. 발사 전 몇 번 동일한 문제를 발견했지만 단순히 기계적 오류로 생각하고 소프트웨어에 대해선 검토를 하지 않았다. 이 문제는 3개의 쓰레드가 서로 버스를 점유하면서 발생한 문제였다. 이렇듯 때로는 제어상의 문제가 기계적 문제로 착각하게 만들어진 경우도 있지만 다양한 소프트웨어 제품을 사용하는 컴퓨터에서도 종종 이러한 문제가 발생하면 그 원인을 찾지 못하고 임시 조치만 하는 경우도 있다. 이러한 결함을 극복하고 얼마전 화성 탐사 로봇인 스피릿이 활동할 수 있게 된 것이다.


결함은 얼마나 제거할 수 있나?

신이 아닌 인간이 직접 만들기 때문에 얼마만큼의 결함은 필연적이다. 완벽하게 만들고 싶지만 완벽하게 만들 수 있는 것은 거의 없다. 다른 것에 비교하여 좋다고 표시할 수밖에 없다. 결함을 완벽히 제거할 수는 없지만 거의 완벽하게 제거할 수 있는 방법을 찾을 수 있다면 시간의 한계가 주어진 만큼 완벽한 소프트웨어를 만들 가능성이 높아진다. 일반적으로 결함을 줄이기 위한 다양한 방법들이 얼마나 효율적인지 살펴보자.


컴파일러, 실행코드를 만드는 도구다

엔지니어는 구문(Syntax) 결함을 제거하기 위해서 컴파일러를 사용한다. 최근 컴파일러는 매우 정교하게 만들어졌고 다양한 문제를 미리 확인할 수 있도록 되어 있다. 그러나 컴파일러가 실행코드를 만들기 위해서 소스코드가 잘 되어 있는지 검사하는 과정을 마치 코드의 결함을 모두 찾는다고 생각한다면 큰 실수를 범할 수 있다. 최근 컴파일러는 엔지니어가 인위적으로 코드를 재배치하게 되는 경우 이를 오류로 취급하여 실행코드를 만들어 주지 않은 예가 있어 기본적인 부분만 검토하도록 하는 경우도 많다. C를 사용하는 경우 “if (c=0) { ; }” 와 “if (c==0) { ; }”라고 표시한 문장을 각각 어떻게 해석하는지 확인해보자

C 언어 구문상 두 가지 모두 올바른 표현이지만 그 결과는 전혀 다르게 나타나게 된다. 일부 연구 결과에 의하면 컴파일러가 구문상의 오류조차도 약 10% 정도는 잘못 해석할 수 있다고 한다. 컴파일 과정에서 대체로 전체 결함의 50% 정도를 제거할 수 있다.

테스트는 모든 가능성을 테스트할 수 없다

테스트는 결함을 확인하는 가장 중요한 방법으로 인식한다. 현장에서 결함이 생기면 충분한 테스트를 하지 않아서 생긴 문제라고 한다. 그리고 테스트는 계층적으로 단위 테스트부터 통합 테스트, 시스템 테스트, 인수 테스트 혹은 베타 테스트를 거치게 된다. 테스트의 각 과정은 아무리 철저하게 한다고 해도 50% 이상 결함을 찾지 못한다(참고자료 ?). 즉 1000개의 결함이 있으면 최대 500개는 찾지만 500개는 찾지 못한다는 것이다. 만일 100개의 결함이 있다면 역시 최대 50개만을 찾는다는 것이다.

그래서 엔지니어가 테스트하면서 일부는 확인이 되지만 통합하면서 다시 새로운 문제들이 발생하고 시스템과 인수 테스트에서도 역시 결함이 나타날 수밖에 없다. 혹시 모든 가능한 변수를 고려해서 다양한 경우를 모두 테스트하려고 한다면 수십 만, 수백 만 라인에 대한 소프트웨어를 테스트하기란 불가능하다. 테스트는 매우 비효율적이다. 단위 테스트의 경우 하나를 제거하는 데 16분 정도가 소요되고, 통합 테스트의 경우 120분, 시스템 테스트의 경우 414분이 든다.


검사, 여러 사람이 함께 보지만 완벽하진 않다

결함을 찾아내는 과정으로 효율적이고 좋은 방법이라고 추천되지만 많은 엔지니어가 이러한 과정을 거치고 싶어 하지 않는 것이 현재 상황이다. 검사(Inspection)는 결함을 찾아낼 가능성이 80%까지 높다. 검사는 개발된 코드를 실행코드로 만들기 전에 여러 사람이 모여 문제가 없는지를 검증하는 과정이다. 발견된 결함은 담당자가 수정하여 완료 여부를 다시 확인받도록 되어 있는 과정으로, 자신의 코드를 보여주기 싫어할 뿐 아니라 타인에 대한 간섭으로 생각해서 많이 실행되지 않는다.

또한 정확한 검사를 이해하고 진행하는 경우도 드물다. 여러 엔지니어가 하나의 코드를 놓고 씨름한다고 생각하여 비효율적이라고 하지만 실제 이러한 과정을 통해서 소프트웨어 개발기술이 자연스럽게 전파되고 결함 가능성이 최대한 배제된 코드는 테스트 과정에서 비효율적인 측면이 완전히 보상된다. 그렇지만 이 과정은 테스트와는 달리 한 사람이 15분에 1개씩 결함을 찾아 수정할 수 있다는 커다란 장점이 있다.


검토, 자신의 것을 확인하는 과정은 어렵다

검토(Review) 과정 역시 숙달된 사람의 경우 최고?하게 추천하는 품질관리 방법이다. 자신이 작성한 코드를 스스로 검증하고 이를 수정할 수 있도록 하고 있다. 앞서 설명한 검사는 타인이 검증하는 과정에서 요구사항 설계를 모두 이해하고 참여하게 되지만 검토 과정은 자신이 작성한 코드에 대해서 정확하게 이해하고 있으므로 이를 이용한 검증 역시 매우 효과를 발휘하고 있다. 검토는 스스로 하게 됨으로써 검토 목록(checklist)을 이용하여 하나씩 검증할 수 있도록 되어 있다. 검토는 자신의 코드를 직접 검토하는 방법이기 때문에 결함을 찾아내는 시간이 무척 빠르다. 보통 한 개의 결함을 찾는데 1분이 소요되지 않는다.

엔지니어로서 결함을 줄이는 방법

엔지니어에게 품질이 주는 영향을 하나씩 차례로 살펴볼 필요가 있다. 품질이라는 문제가 단순히 프로젝트 차원에서 관리되어야 하는 문제가 아니라는 점을 분명하게 파악할 수 있다면 앞으로 소프트웨어 전문가로서 어떠한 자세로 개발에 임해야 할지 마음의 준비가 되고 실제 그러한 자세로 임하게 될 것이다.


결함은 다른 사람이 만들어 놓은 것이 아니다

프로젝트가 시작되면 바로 작업을 할 수 있을 것이라는 기대를 하는 초보 엔지니어도 있지만 대부분의 프로젝트에서 바로 개발 작업을 수행하는 경우가 드물다. 만일 바로 개발 작업을 하는 경우라면 이미 앞선 프로젝트에서 만들어진 결과를 수정 보완하거나 재개발하는 경우가 대부분이다. 프로젝트를 시작한 시점에서 엔지니어들은 딱히 주어진 업무가 확실하지 않아 우왕좌왕하는 경우가 비일비재하고 시간은 흘러간다. 시작할 수 있는 준비가 된 상태에선 이미 많은 시간이 흘러갔다. 프로젝트 계획에 따르면 이미 많은 프로그램이 만들어져야 하는 상황이지만 아직 만들어진 것은 없다. 이 때 관리자는 급한 목소리로 작업진행을 요청한다. 그에 부응하여 엔지니어는 전광석화와 같이 소프트웨어를 만들어 나간다.

이 시점에서 여러분은 이미 실수를 범하고 있다. 코드에는 이미 많은 결함이 들어 있고 아직 부족한 요구사항에 따라 개발은 지속된다. 이렇게 개발된 모듈 혹은 기능은 실적으로 잡힌다. 그러다 보면 계획을 따라잡았다. 그러나 이때 계획목표를 달성한 것이 맞을까? 이제는 일정에 따라 개발을 진행한다. 약간 여유가 있는 것처럼 보인다. 그러나 문제점들이 서서히 불거지기 시작한다. 앞서 불충분한 요구사항에 따라 작성했던 많은 코드를 함께 수정하고 신규 코드에 적용해야 하는 부담감이 점점 가중된다. 이러한 가중은 더더욱 신규코드에 결함이 생길 수밖에 없도록 만들고 이러한 문제는 뒤로 갈수록 눈덩이처럼 불어나 일정 시점에 가면 매일 밤샘을 하게 된다. 특히 완료 일정은 중요한 휴일인 설, 추석, 휴가, 연휴를 끼는 경우가 비일비재하다. 마무리하고 휴식을 갖기 위해서, 혹은 휴일동안 기존에 사용하던 시스템 데이터를 새로운 시스템에 적용할 수 있도록 하기 위한 것인데 이 때까지 혹은 사용자가 시작하는 시간까지 악전고투를 겪으면서 소프트웨어를 개발하는 상황이 비일비재하다.


[ 제거 방법의 비교 ]

다양한 결함제거 방법들은 엔지니어가 어떻게 하는 것이 적절한 방법인지를 예상할 수 있도록 도와준다. <그림 1>은 실제 결함을 어떻게 줄여나가는 것이 효율적인지 가시적으로 확인할 수 있는 모형이다. 10만 라인의 소프트웨어의 경우 대체로 1만 개의 결함이 발생하고 이를 다양한 단계에 걸쳐 제거하게 된다. 세 가지 형태의 전략을 비교하면 다음과 같다.

1. 컴파일-단위 테스트-통합 테스트-시스템 테스트
2. 컴파일-검사-단위 테스트-통합 테스트-시스템 테스트
3. 컴파일-검토-검사-단위 테스트-통합 테스트-시스템 테스트

첫 번째 경우는 일반적인 개발에서 사용되는 절차다. 검토와 검사를 하지 않으면 소프트웨어가 최종적으로 1,050개 결함이 남아 있고 그 동안 16,683시간을 사용한다. 그런 반면 검토와 검사 과정을 수행한 세 번째 경우 2,452시간 만에 126개 결함만 남기고 모두 제거할 수 있다. 고객에게 인도되는 소프트웨어가 1,000라인 당 4개 이하여야 한다면 이 소프트웨어의 경우 400개 이하일 때까지 계속 수정을 해야 고객에게 인도될 수 있다. 아직 수정해야 할 결함은 650개에 달하기 때문에 450개를 처리했던 시스템 테스트 시간인 10,350시간보다 더 많은 시간이 필요하다. 절차가 복잡하고 학습이 필요하지만 세 번째 전략이 더 생산성과 품질이 높아지는 방법이다.


<그림 1> 결합 제거 전략 비교


시작 단계에선 엔지니어만으로 안된다

‘나는 엔지니어니까 고객이 요구하는 사항은 몰라도 돼’라며 고객이 모든 요구사항을 잘 만들어 줄 것이라고 생각하지만 어떤 고객도 엔지니어가 만족할 만한 요구사항을 만들어 주지 않는다. 엔지니어 스스로 가능한 많은 정보를 찾고 이를 검증해서 개발에서 적용할 수 있도록 정리를 해야 한다. 엔지니어가 직접 고객을 만날 수 없는 경우는 작업 내용을 설명해줄 담당자에게 열심히 물어보고 이해를 할 수 있어야 한다. 그리고 이러한 요구사항을 어떻게 소프트웨어로 만들 것인가를 구상해야 한다. 고객은 100마디의 이야기를 1마디로 줄여서 이야기하기 때문에 엔지니어는 의심나는 사항은 계속 확인하고, 필요하다면 관련 내용을 참조해서라도 빨리 이해할 필요가 있다.

고급 엔지니어는 고객의 업무나 지식을 많이 가지고 있고 때로는 고객에게 현실적인 대안을 제공할 수 있는 능력이 있다. 현장에서 고급 엔지니어를 선호하는 것은 아무리 요구사항이 완벽하게 구성되어 있다고 해도 암묵적으로 교환하는 정보에 대해선 초보 엔지니어가 파악하는데 무리가 있기 때문에 효율적인 의사소통이 안 되기 때문이다.


요구사항이 부족하더라도 완전한 코드를 만들어라

코드를 개발해야 하는 시기엔 자신이 해야 할 업무의 전체를 이해하는 것이 중요하다. 그리고 효과적으로 적용하기 위한 방법을 구상하여 세부사항을 고객에게 확인받는 것도 중요하다. 이러한 상태에서 비록 일정에 쫓기고 있더라도 현재 하고 있는 작업을 나중에 다시 수정하고 결함을 찾는 시간을 대폭 줄일 수 있다는 믿음을 가져야 한다. 때론 정확한 요구사항을 파악할 수 없는 경우도 있다. 이러한 경우 불완전한 부분에 대해선 남기고 나머지 부분에 대해서 할 수 있는 모든 작업을 완료할 필요가 있다. 추가적인 요구사항을 받아서 마무리 지으려고 미완성인 상태로 두어서는 안 된다. ‘요구사항 부족’이라고 오류 메시지라도 달아서 그 부분을 완성해야 한다. 즉 하나의 프로그램으로서 완벽하게 만들어야 한다.

그렇지 않으면 시간이 지난 후에 어떤 부분에서 미완성이 되었는지 조차 파악되지 않기 때문에 메시지라도 적어 놓는다면 나중에 본인이든 다른 사람이든 이 부분에 대해선 어떤 사유가 있어서 완결되지 않은 부분이란 것을 정확히 파악할 수 있다. 그렇지 않으면 정상적인 처리를 할 수 있는 부분이라고 생각하여 다른 부분에서 문제가 생긴 것으로 오해하고 많은 시간을 허비하는 경우가 자주 발생하게 된다.


개발 중에 자주 겪는 결함이 있다

엔지니어가 설계나 코드를 만들다 보면 결함이 만들어지는 패턴이 있다. 무조건 컴파일을 먼저 하고 나서 나중에 테스트에서 해결해보자고 하는 형태, 설계가 없이 바로 수백 라인의 프로그램을 만드는 경우, 충분한 테스트를 거치지 않고 적용하??드 1바이트를 고치고 나도 꼼꼼하게 문제가 없는지 확인하는 경우, 모든 가능성을 고려하여 필요 이상으로 코드를 확장하는 경우, 필요 이상의 코딩 규칙에 따라 코드를 정리하고 필요 이상의 코멘트를 붙이는 경우, 빈번하게 컴파일과 테스트를 반복하면서 개발하는 경우 등이 있다.

이러한 패턴의 문제점을 빨리 파악하고 이를 개선할 필요가 있다. 이러한 습관들은 다음과 같은 문제를 야기시키는 경우가 많다. 컴파일에 의존하면 발견하지 못한 알고리즘 오류는 테스트에서 어렵사리 발견되는 경우가 많고, 테스트에 의존하게 되면 바쁘게 손놀림을 가져가지만 결국은 많은 시간을 낭비하게 되고, 설계를 하지 않는 경우는 적용해야 할 다양한 요구사항을 누락하여 통합 테스트에서 다시 수정하게 되고, 너무 꼼꼼하게 보는 것은 불필요하게 시간을 낭비하는 형태가 되고, 필요 이상의 코드를 추가하는 것은 노동력 낭비고, 필요 이상의 코딩 규칙은 규칙을 따르느라 중요한 알고리즘이나 데이터를 놓질 수 있고, 코멘트가 많으면 요구사항이 변경되어 수정한 후에 관리되지 않으면 오해를 불러일으킬 수 있고, 빈번한 컴파일과 테스트는 열심히 하는 것처럼 보이지만 개발보다는 컴파일과 테스트에 거의 모든 시간을 할애하는 상황이 된다.

그냥 스쳐 지나갈 수 있는 습관이지만 자신의 습관을 자세히 들여다보고 다른 엔지니어와 비교하면 장점과 단점을 쉽게 찾아 볼 수 있다. 그리고 각 결함에 얼마나 많은 시간이 소비되고 있는지 기록하면서 확인해 보면 차이점을 확연하게 찾아 낼 수 있다.


작업 시간을 정해라

개발 작업 과정에서 마무리 단계에 접어들게 되면 자신이 하고 있는 작업이 어느 정도 어렵고, 얼마나 시간이 걸릴지 가늠하기 쉬워진다. 만일 시간을 기록하고 관리하고 있다면 더욱 쉽게 예측할 수 있을 것이다. 작업 시간을 무조건 짧게 잡아서도 안 되지만 무조건 길게 잡는다고 더 좋은 결과를 기대할 수 없다. 일반적으로 시간이 많다고 해도 그 마지막 시간에 가서 있는 힘을 다해 작업을 하게 되는 것이 일반적인 사실이다. 마무리 단계는 작업에 익숙해서 처음 작업할 때와는 전혀 다른 능숙함을 보인다고 하더라도 실제 새로 개발되는 코드량은 많지 않다. 앞서 개발한 코드를 변경된 요구사항에 맞추거나, 아니면 잠자고 있던 결함이 발견되어 수정작업을 해야 하기 때문에 처음과 크게 틀리지 않는다.

이 때 초기에 결함을 없도록 만들었다면 비교적 여유를 찾을 수 있지만 그렇지 않고 ‘날림’으로 만들었다면 그 책임은 밤샘으로 보완해야 할 것이다. 물론 턱없이 짧은 개발기간과 부족한 엔지니어로 인해서 밤샘하는 경우가 대부분일 수 있지만 자세히 들여다보면 하루 밤만 새면 끝날 일을 결함이 나타나 이틀 밤을 새는 경우가 더 많다는 것을 확인해 볼 필요가 있다.


PSP에서 적용

PSP에서 결함을 관리하는 방법으로 짾 코딩 표준(Coding Standard)을 작성하는 것이다. 일관된 코딩 형태를 유지하기 위한 목적도 있지만 결함이 발생할 수 있는 가능성을 줄이기 위해서 이용된다. 예를 들어 모든 변수는 한 줄에 하나씩 선언하고 반드시 초기화를 해야 한다는 규칙은 가독성을 높일 뿐 아니라 혹시 발생할 수 있는 변수에 엉뚱한 결과가 생기지 않도록 하기 위해서다. 짿 그 다음으로 하는 과정은 개발 과정에서 발생하는 결함을 상세하게 기록해야 한다. 어떤 결함이 발생했고 그 결함을 발견한 단계(설계/코드/컴파일/테스트)와 그 결함이 만들어지게 된 단계(계획/설계/코딩/컴파일/테스트)를 구분해야 한다. 그리고 마지막으로 그 결함을 수정하는데 얼마나 시간이 들어갔는지 확인해 줘야 한다.

이렇게 정리한 결함이 쌓이면 쨁 어떤 결함에 시간을 많이 사용했는지 확인한다. 이러한 결함을 가능한 발생하지 않도록 처리방법을 모색할 필요가 있다. 코딩 표준에 적용하여 사용하면 효과가 날지, 아니면 설계나 코딩이 끝나면 그러한 내용들이 있는지 스스로 확인해 볼 수 있는 방법이 나은지, 아니면 다른 방법으로 이러한 부분을 확인하는 것이 좋은지 결정하게 된다.

만일 설계에서 자주 발생하는 오류라면 그러한 문제를 설계가 끝나면 혹시 그런 문제가 없는지 확인할 수 있도록 디자인 검토 목록(Design Review Checklist)을 만들어 사용할 수 있고, 코드에서 발생하는 문제라면 코드 검토 목록(Code Review Checklist)을 만들어 활용할 수 있다. 이런 과정을 거치게 되면 기존에 컴파일에서 발생하던 결함 수도 현저하게 줄어들게 되고 단위 테스트도 쉽게 마무리 된다. 이런 소스는 나중에 통합 테스트와 시스템 테스트에서 별도 결함이 나타나지 않고 쉽게 끝낼 수 있게 되는 것이다.

<표 2> 결함 유형 표준

이때 사용되는 결함의 범위는 <표 2>와 같은 표준화된 결함 분류를 가진다. 표에서 살펴보면 번호 10에서 40까지는 대체로 코딩 작업에서 발생할 수 있는 결함들이고, 나머지는 디자인 작업에서 발생할 수 있는 결함들이다. 이러한 결함들은 앞서 이야기한 ISO9126 품질 요소와는 많이 다르다. 결함이 적은 프로그램에서 있을만한 결함들만 표시하고 있고 대형 프로그램에서 관심이 되고 있는 사항들은 누락되어 있다. 예를 들어 성능에 관련된 문제나 보안에 관련된 문제가 대두되는 경우, 시스템 구조적인 문제를 다뤄야 하기 때문에 굳이 단위 모듈 혹은 컴포넌트를 개발할 때 이러한 문제를 거론할 필요가 없는 것이다. 단지 기능성에 초점을 맞추고 진행하는 것만으로도 충분한 효과를 얻을 수 있기 때문에 넓은 범위를 다루지 않고 있다.

아직까지 국내에서 엔지니어들이 단위 프로그램 개발마다 적용해야 하는 불편함, 거시적인 안목의 결함이 아닌 단순한 코드 위주의 결함 관리, 모든 결함을 기록해야 하는 불편함, 좀 더 깊이 생각하면 상세한 설계서의 작성, 부가적인 작업을 수반하게 됨으로써의 시간 낭비 등 많은 장벽이 있어서 사용을 꺼리고 있다. 이러한 현상은 국내뿐만 아니라 해외에서도 마찬가지다. 하지만 자신의 습관에서 더 이상 문제점을 발견하지 못할 때는 좀 더 자신의 문제점을 명확하게 찾고 자신의 능력을 향상시키는 방법으로 이용해 보면 놀랄만한 결과를 가지고 올 것이다. 만일 현재 전혀 문제점을 찾을 수 없다면 바로 실행해 보는 것도 좋을 수 있다.

PSP 교육을 받고 실습을 했던 많은 엔지니어들에게 공통점은 PSP 교육을 이수한 것만으로도 이미 결함의 50% 정도가 감소한다는 놀라운 결과가 있다. 실제 교육을 받고 실습을 함으로써 그 능력이 향상되었는가라는 질문엔 확실한 답을 할 수 없다. 사람의 성격이나 습관이 며칠 사이에 변하기는 어렵기 때문이다. 필자의 경험에 의하면 첫 실습 후 결함을 기록하고 관리하는 것이 귀찮아져서 설계와 코딩 작업에서 결함이 생기지 않도록 세심하게 배려를 하게 됨으로써 줄어들었다.

이와 비슷한 예로, 난해한 부분의 코드는 생각만큼 많은 결함이 발생하지 않고 오히려 단순한 부분의 코드에서 결함이 발생하는 경우를 많이 접했다. 어떤 사람은 기술에 의해서 생산성이나 품질이 좋아지기 보다는 주의와 관심을 가짐으로써 좋은 결과를 얻을 수 있다는 호손효과라고 말하는 사람들도 있다.

[ 코드 검토를 해 봅시다 ]

코드 검토 체크리스트 사용방법

1. 체크리스트 상에 있는 각 항목에 관해 프로그램을 전체적으로 검토한다. 예를 들면 체크리스트의 “모든 디자인 요소를 코드로 만들었는가?”를 확인하기 위해 전체 프로그램을 검토한다. 이렇게 검토하는 동안 다른 결함을 발견했다면 그 결함을 고쳐야 한다. 그러나 “모든 디자인 요소를 코드로 만들었는가”를 점검하는 것이 원래의 목적이다. 이 검토가 끝나면 그 체크리스트 상에 있는 다음 항목을 검토한다.

2. 검토하는 동안 결함을 발견하면 오른쪽 첫 번째 칸에 ‘正"으로 개수를 표시한다.

3. 검토를 했지만 결함을 찾을 수 없었다면 ‘正" 대신에 대신 ‘X" 표를 한다.

4. 프로그램의 여러 기능, 객체 또는 절차 등을 검토하는 경우 각 항목에 대해서 각각의 기능이나 객체 절차를 구분하여 기록하는 것이 좋다. 즉 “함수 호출의 형식을 확인한다” 항목을 검토할 때 여러 객체인 경우 각 객체별로 함수 호출 형식을 확인한다.

5. 예기치 못한 그런 문제나 시스템 또는 사용자와 관련된 문제 등을 찾아내기 위해 항상 마지막에 자세히 살펴봐야 한다.


자바 코드 검토 체크리스트(code review checklist)



프로그램 파일명:
날짜:

구분 목적 효율적인 코드검토 지원 # # # #
일반 각 단계를 수행하면 오른쪽 "#" 란에 발견된 결함의 개수를 "正"으로 표시한다. 없으면 "X"를 표시한다.
다음 항목을 검토하기 전 해당 프로그램, 클래스, 메쏘드 목록을 만들어 각각을 검토한다.
완결성 모든 디자인 요소가 코딩되었는가?
Includes import문에 오류가 없는가?
초기화 변수 및 내용을 모두 초기화 처리했는가?
- 프로그램 시작부분에서 처리는
-각 반복문에 있어서
-클래스/메쏘드 도입부에서
호출 함수호출의 형식을 확인한다.
- 리턴 값에 대해서
- 전달 값에 대해서
- 예외처리 (excption handle)
각 이름 각 이름의 철자와 용도를 확인한다.
- 명칭의 일관성이 유지되는가?
- 목적한 의향대로 사용되고 있는가?
출력형식 출력 형식을 확인한다.
- 각 라인의 출력이 적절한가?
-공간은 적절한가?
{} 짝 확인 "{}" 이 적적히 사용되고 정확히 일치하는가?
논리 연산자

"==", "=", "||" 등이 적절히 사용되고 있는가?
모든 로직 처리가 적절한가?

행 단위 검토 모든 라인에 대해서 다음을 확인한다.
- 지정된 syntaxㄹ르 사용하고
- 적절한 구두점 (puctuation)을 사용하는가?
코딩 표준(coding standards)에 따라서 작성했는가?
파일 처리 모든 파일처리에 다음을 확인한다.
- 정확히 읽기와 쓰기, 공유가 선언되었는가?
- 열기와
- 닫기가 확실한가
전체 확인 시스템 이상 여부와 예기치 못한 문제들이 있는지 전체 프로그램을 확인했는가?
합계


이제는 자신의 잘못된 습관을 바꿔야 할 때

소프트웨어 결함의 대부분은 엔지니어에 의해서 만들어진 결과물이다. 그렇기 때문에 이러한 문제를 해결하기 위해서 밤을 새워야 한다. 아무리 많은 시간을 투자해서 일을 한다고 그 결과가 좋아지지는 않는다. 각자 자신에게 맞는 신발을 신고 달리기를 해야 좋은 기록을 얻을 수 있는 것과 같이 소프트웨어 개발에 있어서 자신에게 맞는 틀을 갖춰야 한다. 그 동안 맨발로 혹은 맞지 않은 신발을 신고 발이 부르트도록 달려 봤지만 아직 발에 맞는 신발을 찾아보지 못한 죄로 아직도 자신의 능력을 충분히 발휘하지 못하는 상황이다.

세계적인 육상 선수들이 무조건 달리기 연습만으로 세계기록을 갱신하진 못한다. 그들의 달리기 자세에서부터 태어나면서 배웠던 숨쉬기까지 다시 배워야만 세계기록을 갱신할 수 있는 것이다. 자신의 습관을 살펴서 무엇이 문제가 되는지를 살피고 그러한 문제가 해결되면 자신감이 생기고 그 자신감은 더 넓은 세상을 볼 수 있는 눈을 뜨게 해 줄 것이다.


프로젝트를 관리하자

다음 시간에는 프로젝트에 관련된 내용들을 이야기하려 한다. 프로젝트는 반복적인 일이 아니라 매번 그 특수한 사항을 이해하고 적용해야 하기 때문에 쉽사리 관리하기 어렵다. 이미 시간과 품질까지 논의하면서 프로젝트를 보는 시각이 상당히 높아졌다. 소프트웨어 프로젝트를 진행하기 위해선 독자들이 알아야 할 상식과 현장에서 어떻게 진행되는지를 알고 적절한 자신의 프로젝트 모형을 설계하고 적용할 수 있게 되면 지속적으로 안정된 관리 방식을 마련하게 될 것이다.



참 고 자 료

1. ISO9126, “Information Technology - Software Product Evaluation - Software Quality Characteristics and Metrics,” Geneva, Switzerland: International Organization for Standardization.

2. Humphrey, W. “Winning with Software: An Executive Strategy”. Addison-Wesley, 2001.


정리 | 박준상 | zenith@korea.cnet.com

출처 : 마이크로소프트웨어 2004년 2월호