반응형

커맨드 패턴 (Command Pattern)
커맨드 패턴은 객체의 행위(메서드)를 클래스로 만들어 캡슐화 하는 패턴
  
객체(A)에서 객채(B)의 메서드를 실행하려면 객체(B)를 참조함으로 의존성이 발생
이를 커맨드 패턴을 적용하여 제거할 수 있음.
  
의존성이 제거 되므로 기능에 대한 변경이 일어날시  기능에 대한 클래스만 정의하면 되므로 확장성이 유연해 짐.
  
커맨드 패턴에는 명령(command), 수신자(receiver), 발동자(invoker), 클라이언트(client) 네게의 요소로 이루어짐

Switch 클래스는 요청에 대한 구체적 기능을 구현하는 대신
외부에서 전달된 캡슐화된 명령을 호출하는 역활을 수행.
미리 약속된 Command 인터페이스의 execute 메서드를 호출하는 역활

Light 클래스로 요구 사항을 수행하기 위해 구체적 기능이 구현된 객체

Command 인터페이스를 구현하고, execute() 메서드를 구현함으로써
Receiver에 있는 메서드를 호출하여 요청된  작업을 수행하는 역활

 

클라이언트 객체는 어느 시점에서 어떤 명령을 수행할지를 결정한다.
수행할 명령을 발동자 객체로 커맨드 객체를 전달

 

 

 

반응형
서비스 지향 아키텍처(Service Oriented Architecture, SOA) 
"서비스 지향 아키텍처는 비지니스 프로세스와 그것을 지원하는 IT기반 구조를 안전하고 표준화된 컴포넌트-서비스로 통합하기 위한 프레임워크이며,
이들 서비스는 변화하는 비지니스 우선순위를 해결하기 위해 재사용하고 결합된다."
-Service-Oriented Architecture Compass(2006, Norbert Bieberstein 외, IBM press)-

위키: http://ko.wikipedia.org/wiki/%EC%84%9C%EB%B9%84%EC%8A%A4_%EC%A7%80%ED%96%A5_%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98
이해자료: http://blog.naver.com/image07?Redirect=Log&logNo=60023998658

비지니스 프로세스 관리(Business Process Management, BPM)
미리 정의된 사람 , 정보 자원과 업무의 흐름을 통합적으로 관리, 지원해주는 업무처리 자동화 기법.

이해자료: http://wizim.blog.me/70096695829

(Simple Object Access Protocol, SOAP) 
일반적으로 널리 알려진 HTTP,HTTPS,SMTP등을 사용하여 XML기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜
위키: http://ko.wikipedia.org/wiki/SOAP

기업 응용프로그램 통합(EAI, Enterprise Application Integration)
DW, ERP, CRM, SCM, B2B 등 기업에서 운영하는 서로 다른 Application 및 System 을 통합하는 것을 말합니다. 
EAI Solution은 이를 통해 업무의 효율성, 확장성을 높이고 유지보수시간 및 비용 절감, 편의성을 높이는 Solution.

위키: http://ko.wikipedia.org/wiki/EAI
이해자료: http://blog.naver.com/PostView.nhn?blogId=mingo74&logNo=140010287276&redirect=Dlog&widgetTypeCall=true
          http://www.mobilejava.co.kr/bbs/view.jsp?id=262&code=dic
          

전자 문서 교환(Electronic Data Interchange, EDI)
기업간에 정형화된 문서를 표준화된 자료표현 양식에 준하여 전자적 통신매체를 이용해 교환하는 방식
위키: http://ko.wikipedia.org/wiki/EDI

전사적 자원 관리(Enterprise Resource Planning, ERP) http://www.terms.co.kr/ERP.htm
 ERP는 소극적으로 구매와 생산관리, 물류, 판매, 회계 등의 기업 활동 전반에 걸친 업무를 통합한 
 기업정보시스템의 패키지 소프트웨어를 말한다. 
 다시말해 “기업 전체 경영자원을 계획적으로, 동시에 최적으로 활용한다.”는 것을 의미한다.

사업 제안 요청서(Request For Proposal, RFP) http://intempus.tistory.com/1363
기업체에서 IT 시스템을 도입하고자 할 때 시스템을 구축해 줄 수 있는 곳에서 어떻게 구축할 것인가를 요청하는 문서이다. 실은 IT 뿐만 아니라 기업체 내에서 아웃소싱할 수 있는 모든 분야에 다 사용할 수 있다. 


SAP

CRM 

ERP, PDM, EDM

BPEL, ESB

ROA

반응형
<출처: http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33152 >
 마소 홈페이지에서 패턴이란 단어로 PDF 서비스를 검색하면 총 42개의 콘텐츠가 뜬다. 그럼에도 패턴은 꾸준히 기사거리가 되고 있다. 왜 그런 것일까? 널리 알려진 것처럼 철학에서 수학이 분리되었고, 수학은 다시 과학으로 나누어졌다. 이처럼 많은 사람들이 관심을 가지고 참여하는 학문들은 진화할수록 세분화된다. 패턴 역시 1995년 GoF가 『Design Patterns: Elements of Reusable Object-Oriented Software』란 책을 내면서 널리 알려지기 시작했다. 그 이후 세분화되어 분석영역의 패턴(Analysis Pattern), 구현 패턴(Implement Pattern), 테스트 유닛 패턴(Test Unit Patterns) 등 각각의 도메인 특화된 패턴들이 계속해서 나오고 있다. 혹자들은 이제 패턴의 홍수로 인해 패턴 사용이 오히려 더 힘들어지는 시기라고 이야기한다.

필자는 많은 영역의 패턴 중에서 GoF의 디자인 패턴만큼이나 일찍(1996년 Pattern-Oriented Software Architecture) 소개되어 해외에서는 많이 전파되었으나, 아직까지 우리나라에서는 확산되지 않은 아키텍처 패턴에 대해 이야기하고자 한다.

소프트웨어 아키텍처란?
족보(?)를 거슬러 올라가듯이 아키텍처 패턴은 소프트웨어 아키텍처에 대한 내용이고 소프트웨어 아키텍처의 유래는 많은 IT 용어들이 그렇듯이 건축의 아키텍처에서 유래되었다. 그 족보 순서대로 아키텍처란 무엇인지부터 살펴보자.

아키텍처의 영문 어원은 Architecture = archi(first, chief, govern) + tect(build)이다. 해석해보면 건물을 구축(build)할 때 전체적인 구조를 관리(govern)하는 것을 의미한다. 라틴어의 어원을 찾아보면 Architectura = Arch(큰, 우두머리) + Tectura(기술), 즉 큰 시스템을 구축할 때 구조를 관리하기 위한 기술을 의미한다. 그렇다면 소프트웨어 아키텍처란 무엇을 의미하는가?

‘소프트웨어 시스템을 구성하는 서브시스템과 컴포넌트, 그리고 그것들의 관계를 나타내는 용어이다.’
- Pattern-Oriented Software Architecture, Volume 1: A System of Patterns

‘아키텍처는 컴포넌트로 구체화된 시스템의 기본적인 조직이며 환경에 대한 관계이고 디자인과 진화를 이끄는 원리이다.’
- IEEE1471

‘소프트웨어 구성요소와 그들이 지니고 있는 특성 중에 외부에 드러나는 요소의 특성, 그리고 구성요소들 간의 관계를 표현하는 시스템의 구조나 구조체를 말한다’
- Software Architecture in Practice

몇몇 책에서 나온 소프트웨어 아키텍처에 대한 정의이다. 정의가 조금씩 다르지만 공통적으로 언급하고 있는 것은 소프트웨어 아키텍처란 시스템을 구성하는 구성요소(서브시스템, 컴포넌트)와 그들(구성요소) 간의 관계를 나타낸다는 점이다.

좀 어렵다면 더 쉽게 예로 <그림 2>를 들어보자. 좌측 그림은 학창시절 좋아했던 프라모델의 조립설명서이고, 우측은 스트럿츠의 아키텍처를 표현한 그림이다. 좌측 조립설명서에는 조립부품에 대한 정보(부품번호)와 서로 연결되는 정보(화살표)를 표기하고 있다. 우측에 익숙한 스트럿츠 아키텍처도 역시 다를 바가 없다. 구성요소에 대한 정보(명칭)와 연관된 구성요소끼리의 관계를 표시하고 있다. 이제 소프트웨어 아키텍처가 어떤 것인지 감이 왔을 것이다. 그렇다고 소프트웨어 아키텍처가 그림이라고 생각하면 안 된다. 구성요소와 관계를 설명하기 위한 텍스트, 표 등 어떠한 형태로든 가능하며 거의 모든 경우 혼합되어 사용된다.

왜 소프트웨어 아키텍처를 알아야 하는가?

드라마나 영화에서 연인들이 <그림 3>과 같은 퍼즐을 사서 함께 머리를 맞대고 맞추는 모습을 본 적이 있을 것이다. 만약 좌측의 16조각 퍼즐이라면 완성된(구성요소와 연관 관계를 표시한) 그림 없이 쉽게 해낼 수 있다. 너무 빨리 끝나 다른 놀이도 준비해두지 않으면, 자칫 연인이 지루해 할 수도 있다. 그러나 우측같이 5,000조각의 퍼즐이라면 사정은 달라진다. 완성된(구성요소와 연관관계를 표시한) 그림은 필수인 것이다. 잘못하면 서로에게 ‘퍼즐하나 못 맞추나’라는 식의 실망감을 안겨줄 수도 있으니 조심해야 한다. 소프트웨어 아키텍처 역시 규모가 작은 프로그램에서는 필요하지 않다. 그러나 복잡한 시스템이라면 성공적인 구축과 유지보수를 위해 반드시 필요하다.

아키텍처 패턴이란?

아키텍처 패턴이란 디자인 패턴과 마찬가지로 특정 문제를 해결하기 위해 반복되어 사용되는 솔루션을 문서화한 것이다. 단지 문제의 영역이 설계(디자인)가 아닌 아키텍처라고 생각하면 된다. 나무를 보느냐, 숲을 보느냐의 차이인 셈이다.

아키텍처 패턴은 소프트웨어 시스템의 구조를 체계적으로 구성하기 위한 기본적인 스키마를 제시한다. 아키텍처 패턴에는 미리 정의된 서브시스템을 제공하고 각각의 아키텍처 패턴간의 책임을 명시하며 패턴들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함하고 있다.

즉, 소프트웨어 시스템의 전체 구조를 나타내는 조감도이면서 구성요소들에 대한 설명서이기도 하며, 구성요소들 사이의 관계를 조직화하는 규정집이기도 하다. 아키텍처 패턴은 아키텍처는 아니나 시스템의 유용한 이미지를 전달해준다. 패턴의 또 다른 유용한 측면은 품질 속성을 명확히 보여준다.

왜 아키텍처 패턴을 알아야 하는가?

아키텍트(아키텍처를 총책임지는 사람)는 곧 잘 오케스트라의 지휘자와 비교된다. <그림 5>는 유명한 지휘자 카라얀의 지휘 모습을 보여준다. 카라얀은 원래 피아니스트로서의 길을 가려 했다. 그러나 그는 그 분야에서 성공할 가능성이 희박하다는 것을 느끼고 있던 차에 은사였던 파움가르트(BernhardPaum gartner)의 조언으로 지휘자의 길을 택한다.

카라얀이 지휘를 공부하면서 그의 인생엔 많은 행운이 잇따르는데 다름 아니라 당시 빈 국립가극장의 건물 관리자 겸 감독관이었던 사람이 바로 카라얀의 숙부였다. 숙부는 조카에게 유명한 지휘자의 연주회나 비공개 연습을 들을 수 있도록 해주었다. 거장들의 모습을 가까이 보면서 그는 많은 것을 배울 수 있었다.

여러분들이 아키텍처 패턴을 알고 사용한다는 것은 카라얀의 경우처럼 좋은 숙부가 없이도 훌륭한 아키텍트의 노하우를 배울 수 있다는 것이다. 다시 말하면 거장들이 이미 사용해 구축한 시스템이 존재하는 검증된 아키텍처를 이용할 수 있는 것이다. 개발에서 설계를 하게 되고 그러면서 디자인 패턴을 공부했듯이, 전체적인 소프트웨어의 시스템을 다루고자 할 때 아키텍처 패턴은 큰 도움이 될 것이다.

음악계에 재미있는 에피소드가 하나 있다. 또 다른 유명한 지휘자안 프란츠 샬크(F. Schalk 1863-1931)가 오케스트라를 객석에서 감상할 때의 일이었다. 연주가 무르익어가자 무의식적으로 눈을 감았다. 그랬더니 옆에 앉아있던 한 남자가 가만히 속삭였다. "그것은 현대 회화를 볼 때만 그렇게 하는 것입니다. 여기서는 귀를 막아야 해요."

모두가 아키텍처 패턴을 상세히 알아야 할 필요는 없지만, 최소한 다른 사람과의 대화나 전체 시스템에서 자신이 맡은 바를 이해할 수 있는 정도는 알고 있어야, 귀를 막거나 눈을 감는 사람이 되지 않는다.

[아키텍처 패턴의 장점]
- 검증된 아키텍처이다.
- 구축 전에 시스템의 특성에 대해 시뮬레이션할 수 있다.
- 기존 시스템을 쉽게 이해할 수 있다.   

아키텍처 패턴과 디자인 패턴
앞에서부터 디자인 패턴과 아키텍처 패턴을 계속 묶어서 이야기해왔다. 이쯤에서 명확히 서로간의 관계를 정리하도록 하자. 두 가지 모두는 소프트웨어 개발에 있어서 반복되는 문제들에 대한 해법이라는 점에서 동일하다.

하지만, 디자인 패턴이 프로그램의 설계에서 나타나는 반복적인 문제를 다루는 반면 아키텍처 패턴은 소프트웨어 시스템 전체적으로 영향을 미치는 사안들에 대한 해결 방법이다. <표 1>로 간단히 둘의 차이점을 정리해보았다.

예를 들면 ‘파이프&필터’라는 아키텍처 패턴이 있다. 이 패턴의 장점 중 하나는 동시 개발이 가능하다는 점이다. 필터 또는 파이프 단위로 나누어 개발 가능하기 때문에 병렬적 개발이 가능하다. 하지만 디자인 패턴 중에는 이런 장점을 가진 패턴이 존재하지 않는다.

이는 디자인 패턴은 설계 문제에 있어서의 해결책이기 때문이고, 아키텍처 패턴은 소프트웨어 시스템 전반에 관한 문제 해결이기 때문이다. 따라서 아키텍처 패턴은 디자인 패턴과 달리 조직의 구조나 개발 프로세스의 효율성까지도 포함한다.

둘은 이렇게 다루는 문제의 영역이 다르지만, 곧 잘 어울려 다닌다. 아키텍처 패턴의 구성은 디자인 패턴들로 이뤄지는 경우가 많다. 그래서 둘 사이의 관계를 Composit Pattern으로 표현할 수 있다. 아키텍처 패턴의 구성요소와 구성요소 사이의 관계를 반드시 디자인 패턴으로 해야 하는 것은 아니다. 하지만 앞으로 나올 예제에서도 볼 수 있듯이 둘은 함께 사용되는 경우가 많다.

아키텍처 패턴과 디자인 패턴간의 관계 예제
『Head First Design Patterns』에 나오는 예제로 아키텍처 패턴과 다지인 패턴 간의 관계를 설명하고자 한다. 예를 들어 보자. 한 개발회사에서 묘하게 DJ오디오 시스템과 심장 박동기의 공통점이 많음을 발견하고 MVC 패턴을 이용해 두 가지를 동시에 개발하기로 했다.

DJ오디오 시스템에서는 아이팟이 모델 역할을, 스크래치가 컨트롤러 역할을 맡고 뷰 컴포넌트의 역할은 스피커이다. 심장 박동기에서는 모델은 내부적으로 아날로그(박동)를 디지털(화면에 보이는 수치, 그래프)로 바꾸어주는 부분이고, 컨트롤러는 측정 대상과 연결되는 입력단자가 될 것이다.


이제 두 가지 시스템을 전체적인 UML 그림으로 보자.

MVC 중 VIEW와 Model 관계는 모델의 변경에 따라 자동으로 화면을 바꿔주기 위해 Observer Pattern으로 이뤄져 있다. 플레이어는 작동하는데 음악이 안 나오는 DJ오디오 시스템이나 심장 박동수가 표시되지 않는 심장 박동기를 누가 사겠는가?

같은 시스템이 설정에 따라서 DJ오디오 시스템일 수도 있고, 심장 박동기가 될 수도 있다. 그 때마다 원하는 기기로 사용하기 위해 모델 컴포넌트를 교체할 수 있어야 한다. 그래서 모델에는 Strategy Pattern이 적용되어 있다.

뷰 컴포넌트는 복합적인 화면을 쉽게 구성하기 위해 Composite Pattern을 사용해 구현되어 있다.

하나의 MVC 패턴의 구성요소인 모델과 뷰는 각각 Strategy Pattern과 Composite Pattern을 이용했고 뷰와 모델의 연결에는 Observer Pattern을 사용했다. 이렇듯 아키텍처 패턴에서 이야기하는 구성요소나 구성요소 간의 관계에 대한 규칙을 만족시키기 위해 디자인 패턴을 이용하는 경우가 많다.

이제까지 아키텍처 패턴에 대해 설명했다. 왜 우리가 아키텍처 패턴을 알아야 하는지를 따져보고 디자인 패턴과의 공통점과 차이점에 대해 살펴봤다. 큰 건물을 지을 때처럼 큰 시스템을 구축할 때는 아키텍처가 필요하다. 시스템의 요구사항에 맞는 아키텍처를 찾기 위해 아키텍처 패턴을 사용한다. 아키텍처 패턴은 실제 구현을 완료하지 않고도 시스템의 특성을 예측 가능하게 해주는 유용한 지식이다. 아키텍처의 세부 설계는 디자인 패턴을 이용할 수 있고, 많이 그렇게 사용한다. 디자인 패턴이 여러분의 많은 고민을 해결해주었듯이, 아키텍처 패턴도 그럴 수 있기를 기원한다.

MVC 패턴이란?
대표적인 아키텍처 패턴의 하나로 시스템 전체를 Model과 View, Controller 세 개의 컴포넌트로 나누어서 각 부분의 변경 영향도를 최소화하기 위한 패턴이다. Model 컴포넌트는 핵심 데이터와 기능을 캡슐화한다. 모델은 특정 출력 표현 방식이나 특정 입력 동작에 영향을 받지 않는다.

뷰 컴포넌트는 사용자에게 정보를 디스플레이한다. 뷰는 모델로부터 데이터를 얻는다. 모델로부터 제공된 데이터는 다양한 뷰를 통해 표시될 수 있으며, 각 뷰마다 컨트롤러 컴포넌트 하나씩 연결된다. 컨트롤러 컴포넌트는 사용자의 입력, 특정 이벤트 등을 서비스 요청으로 변환한다. 사용자는 오직 컨트롤러를 통해서만 시스템과 상호작용한다.

 

 

DJ오디오 시스템과 심장 박동기에 적용된 디자인 패턴
본문 예제에 등장하는 디자인 패턴에 대해 간단하게 설명하고자 한다. 각 패턴에 대한 자세한 내용은 참고자료에 나오는 「Design Patterns: Elements of Reusable Object-Oriented Software」 또는 「Head First Design Patterns」을 참고하면 된다.

Observer Pattern
두 객체 사이의 의존성 때문에 한 객체의 상태가 변경되면 자동적으로 관련된 객체들에게 알려주기 위한 설계이다. 우리가 다른 사람의 블로그를 매일 같이 들어가서 새로운 아티클이 등록되었는지 살펴볼 필요 없이 RSS를 등록하면 새 글이 올라왔을 때, 자동으로 알려주는 것과 같다. 여기서는 아이팟에 의해 다음 음이 해석되면 스피커에게 자동으로 알려주는 용도로 사용하고 있다.

Strategy Pattern 

같은 알고리즘들을 각각 캡슐화해 서로 호환 가능하게 만드는 설계이다. 클라이언트에 따라서 독립적으로 원하는 알고리즘을 사용할 수 있다. 전투기 게임에서 파워를 먹을 때마다 한 번에 발사되는 미사일의 개수와 모양이 달라진다. 이렇게 동일한 행위(미사일 발사)를 다른 방법(개수와 모양)으로 선택 가능하게 해주는 설계이다. 여기서는 음의 해석을 음악으로 볼 것인지, 심장 박동으로 볼 것인지 선택 가능하도록 하기 위해 사용되고 있다.

Composite Pattern
부분과 전체 구조가 트리 형식으로 표현되는 조립 객체를 Composite Object라고 한다. 클라이언트가 조립 객체나 개별 객체나 모두 동일하게 취급할 수 있도록 해준다. 문서를 작성하게 되면 글상자를 이용하기도 한다. 글상자는 문서와 동일하게 안에 텍스트나 그림을 넣을 수 있다.

이렇게 워드프로세서를 사용자 입장에서는 글상자가 문서의 부분이지만 문서와 동일하게 취급할 수 있게 해준다(글 상자 안에 텍스트를 입력하거나 그림을 삽입하는 방법이 다르다면 얼마나 불편하겠는가). 여기서는 사용자 UI를 구성함에 있어 모든 UI 파트를 Graphics라는 유형으로 단일 취급할 수 있게 사용하고 있다.


참고자료
1. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, Frank Buschmann, WILEY, 1996. 8
2. Software Architecture in Practice (2/E), Paul Clements, Addison-Wesley Professional, 2003. 4
3. IEEE 1471 국제표준(IEEE Recommended Practice for Architectural Description of Software-Intensive Systems)
4. Head First Design Patterns, Kathy Sierra, 2004. 10 
5. Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems, Sherif M. Yacoub
6. Design Patterns: Elements of Reusable Object-Oriented Software, JOHN VLISSIDES, 1995. 8
7. [GoF] 패턴 이야기 - GoF Pattern Overview (손영수) -
http://www.devpia.com/NET2/EvaCast/Lecture/?cu=view&r=122



반응형
<출처: http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33150 >
 새로운 것을 접하고 활용하는 과정에는 일정한 캐즘(chasm)이 존재한다. 캐즘이란 초기에 접하는 시점에서 그것을 활발히 사용하는 시점으로 넘어갈 때 느끼는 과도기적 현상을 설명한 마케팅 용어로, 흔히 일정하게 진행이 정체되거나 진행이 후퇴되는 것처럼 느껴지는 진행 단절 현상으로 나타난다.

프로그래머는 새로운 언어를 학습하는 과정과 새로운 프레임워크를 배우는 것 사이에서 비슷하지만 다른 캐즘을 느끼고, 그로 인한 스트레스를 받는다. 언어를 학습할 때는 대부분 몇 개의 기본적인 키워드와 확장 라이브러리, 컴파일러 및 코드 작성 환경에 대해 적응한 후 학습하고 있는 주 교재의 연습 문제나 자신이 잘 알고 있는 문제를 풀어보는 것으로 시작한다. 처음엔 대부분의 기본 키워드의 동작이나 확장 함수에 익숙하지 않아 느리게 학습이 진행되고 거기에 캐즘이 존재하게 되지만 두세 번 같은 유형의 문제를 반복하게 되면 해당 키워드나 함수에 대해 곧 원활히 사용할 수 있는 능력을 갖게 된다. 훗날 다른 부분을 학습할 때도 원활하게 기존에 배웠던 내용을 응용해 사용할 수 있으며 구현을 자유자재로 부릴 수 있게 된다.

프레임워크를 처음 학습할 때는 언어를 학습할 때처럼 예제부터 다루는 방법을 사용하기도 하지만, 먼저 프레임워크가 커버하는 문제 해결 범위와 용도에 대해 살펴본 후, 아키텍처와 내부 디자인, 프레임워크의 기능 중 수정하거나 첨부할 수 있는 부분과 없는 부분, 그리고 다양한 상황에 맞는 예제를 보게 된다. 그 다음 간단한 예제를 만드는 기능을 설명해 놓은 도움말과 장문의 레퍼런스 설명문, 그리고 마법사가 만들어 놓은 코드에 대한 이해를 먼저 한 다음 예제를 작성하는 순으로 접근하게 된다. 이러한 과정은 프레임워크에 대한 감을 잡기 전까지 캐즘으로 나타나게 되며, 프레임워크 학습을 저해하고 기피하게 되는 원인이 되기도 한다.

프레임워크는 일반적으로 문제를 풀기 위한 재사용 가능한 구현뿐 아니라 코드 구조와 재사용 가능한 디자인이 포함되어 있다. 따라서 전통적인 애플리케이션을 개발하는 방법과는 달리 프레임워크 기반으로 애플리케이션을 개발하기 위해서는 풀고자 하는 도메인 문제를 프레임워크의 구조를 이용해 풀어야 하며, 그러기 위해서는 애플리케이션의 구조를 프레임워크에 맞추기 위해 프레임워크의 기능과 디자인을 학습하는 과정이 반드시 필요하게 된다. 반대로 프레임워크를 개발할 때는 프레임워크의 기능을 쉽게 확장하고 이용할 수 있도록 해야 하며, 디자인을 쉽게 학습할 수 있도록 문서 및 레퍼런스를 제공해야 한다.

프레임워크 기반 애플리케이션의 과정을 도식화해 보면 <그림 1>과 같이 나타낼 수 있는데, 프레임워크 개발자는 프레임워크의 디자인 및 구현, 프레임워크로의 반영, 프레임워크 개선, 프레임워크의 문서화를 담당하며 애플리케이션 개발자는 프레임워크 반영, 프레임워크 이해 및 문서와 레퍼런스를 이용한 이해와 응용 부분을 담당하게 된다.

프레임워크를 이해하기 위한 패턴 언어
PLOP‘08 학회에 발표된 ‘Pattern for UnderstandingFrame works’ 논문에는 프레임워크를 애플리케이션에 적용하기 위해 이해하는 방법으로 다음과 같은 일련의 패턴 언어를 거친다고 기술하고 있다.

- 프레임워크 선택하기 (Selecting a framework)
- 프레임워크를 이용한 프로젝트 레퍼런스 만들기 (Instantiating a framework)
- 프레임워크 발전시키기(Evolving a framework)
- 프레임워크 학습 (Drive your learning)
- 사용 경험의 보전 방법 (Knowledge-keeping)
- 애플리케이션 도메인의 이해 (Understand the application domain)
- 프레임워크 아키텍처의 이해 (Understand the architecture)
- 프레임워크 내부 디자인의 이해 (Understand the design internals)
- 프레임워크 코드의 이해 (Understand the source code)

프레임워크를 구현할 때 무엇보다 중점적으로 집중할 부분은 애플리케이션에 공통적으로 나타나는 부분과 가변적으로 나타나는 부분을 구분하고 분석하는 일이다. 공통적인 부분은 다수의 애플리케이션에서 공통적으로 코드가 반복되게 되므로 프레임워크 안쪽으로 코드가 구현되어 있어 프레임워크 사용만으로 코드 재사용이 일어나도록 구현하는 것이 좋다. 가변적인 부분은 애플리케이션마다 가변적이기 때문에 프레임워크 내의 구현부를 쉽게 선택할 수 있도록 프레임워크 초기화 부분의 파라미터 등을 통해 기능 접근을 할 수 있도록 해야 하며, 만일 가변적인 부분을 프레임워크 내에서 모두 포함하지 못한다면 애플리케이션마다 특정한 상황의 구현을 프레임워크 코드를 대체해 커스터마이징할 수 있도록 위치를 제공해야 한다. 커스터마이징은 가상 함수의 특징인 훅 메소드 형태로 제공해주고 각각의 애플리케이션은 프레임워크에 존재하는 가변적인 코드의 위치를 훅 메소드로 파악해 공통적인 프레임워크의 기능에 도메인에 특화된 기능을 끼워 넣을 수 있도록 한다. 공통적으로 나타나는 변하지 않는 부분의 코드부를 프로즌 스팟(Frozen spots)이라 하며 도메인별로 재구현하는 빈도가 높은 부분의 코드부를 핫 스팟(Hot spots)이라고 한다. 프레임워크를 학습하고 사용할 때 또한 프레임워크의 프로즌 스팟과 핫 스팟을 구분하는 부분을 중점적으로 살펴봐야 한다.

프레임워크 선택하기
프레임워크를 사용하는 데는 다양한 이유가 있다. 예를 들어 MFC를 사용하는 것과 같이 특정 도메인 환경에서의 검증된 코드와 디자인을 활용하기 위해 적용할 때도 있고 애플리케이션을 구현하기에 반복적인 작업이 많이 들어가거나, 애플리케이션의 규모가 커질 경우 애플리케이션의 구현 부담을 프레임워크 적용으로 덜기 위해 프레임워크를 적용하기도 하며, 얼마 전 온 세상을 붉게 물들였던 루비 온 레일즈의 특징처럼 애플리케이션의 구현 기간이 짧아야 할 경우 기능이 미리 충분히 갖춰진 프레임워크를 이용해 릴리즈 일정을 빠르게 하려는 등의 이유로 프레임워크를 사용하게 된다. 이를 위해 먼저 프로젝트에 적용할 프레임워크를 선별하는 작업이 필요한데 선별 작업에 있어 몇 가지 고려할 사항이 있다.

먼저 도메인을 분석하는 작업과 프레임워크의 기능 분석 작업이 필요하다. 애플리케이션이 적용될 도메인을 분석하는 작업과 함께 프레임워크가 가지고 있는 해결 방법이 도메인 문제를 해결해줄 수 있는 애플리케이션을 구현하는 데 기능을 충분히 포함하고 있는지 살펴봐야 한다. 도메인을 분석하는 방법은 ‘애플리케이션 도메인의 이해’ 패턴이 도움이 될 수 있으며 프레임워크의 기능을 파악할 때는 프레임워크의 목적과 성격을 기술해 놓은 문서를 살펴보고 프레임워크의 주요 기능들을 확인하면서 프레임워크에 첨부된 활용 예제들을 살펴보면 도움을 얻을 수 있다.

또한 프레임워크 후보군들 가운데 각 프레임워크를 배우는 데 필요한 시간과 노력을 가늠해보고 적량해보는 작업이 필요하다. 애플리케이션의 개발 기간과 결과물의 품질은 총합인 비용을 두고 한쪽이 높아지면 한쪽이 낮아지는 트레이드 오프 관계에 있으므로 좋은 프레임워크라도 배우는 데 비용이 많이 든다면 프레임워크를 선택할 때 학습 비용을 고려한 선택이 이뤄져야 한다. 그 이유는 학습에 관련된 프레임워크의 문서화가 잘 되어 있는지 확인하는 것도 중요한데다 문서화가 잘 되어 있을수록 학습에 들어가는 비용은 낮아지기 때문이다. 마지막으로 프레임워크의 복잡도가 얼마나 되는지 확인하는 작업이 필요하다. 프레임워크 복잡도에 대한 이해를 위해 ‘프레임워크 아키텍처의 이해’ 패턴과 ‘프레임워크 코드의 이해’ 패턴이 사용되기도 한다.

프레임워크를 선택해서 학습하는 과정은 비용이 많이 들어가는 작업이며, 프로젝트에 적용된 후 중간에 적용한 프레임워크를 교체하는 작업은 경우에 따라 불가능할 정도로 비용이 많이 들어가는 작업이므로 프레임워크를 선택하는 작업은 신중하게 이뤄져야 한다.

프레임워크를 이용한 프로젝트 레퍼런스 만들기
적당한 선택 이후 프레임워크를 사용할 때는 다양한 경력과 경험을 가지고 있는 프로그래머들이 모여 작업하므로 일부 경험이 부족한 프로그래머의 경우 프레임워크를 원활하게 사용하게 될 때까지 기간이 소요되는 경우도 있고, 생소한 프레임워크를 접할 경우 프레임워크에 적응하는 기간과 프레임워크의 복잡도에 따른 학습 시간을 가져야 하는 경우도 있다.

프레임워크를 사용해 애플리케이션을 개발한다는 것은 프레임워크가 제공해주는 아키텍처를 바탕으로 도메인에 특화된 문제를 해결하는 뼈대를 만들고 프레임워크의 구현부에서 재사용하는 코드를 기본으로 도메인에 특화된 문제를 프레임워크 구조에 끼워 넣는 작업으로 진행되기 때문에 프레임워크의 구조 중 끼워 넣는 부분에 대한 정보를 얻고 알아가는 과정의 학습을 통해 프레임워크를 사용한다고 할 수 있다. 이때 프레임워크 코드에서 변하지 않는 프로즌 스팟 부분과 끼워넣을 수 있는 핫 스팟 부분을 구분할 수 있는 것이 중요하다.

프로즌 스팟과 핫 스팟을 구분하는 쉬운 방법은 프레임워크에 포함된 문서를 학습하는 것이다. 애플리케이션 개발자는 프레임워크의 문서에서 확장 포인트를 학습할 수 있다. 대부분의 프레임워크에 포함된 안내문서에는 프레임워크의 프로즌 스팟과 도메인 문제에 구현을 특화시켜 끼워 넣어야할 핫 스팟 구분에 대한 내용이 나와 있으며 특화시킬 코드에 대한 간략한 형태와 함께 이용할 수 있는 유틸리티 등을 소개하고 있다. 문서가 충분치 않다면 애플리케이션에서 프레임워크 코드와 연동되는 진입 부분의 코드부터 분석해서 프레임워크를 알아내면 확장 포인트를 찾을 수 있다.

프레임워크를 이용해 작업할 때, 레퍼런스와 프레임워크 코드만을 가지고 작업하는 것보다는 도메인에 실제로 사용할 수 있는 적당한 예제 단위로 레퍼런스를 구축해 놓으면 팀 단위 작업에서 공통으로 프레임워크를 사용할 때 더욱 효율성을 높일 수 있다.

프레임워크 발전시키기
프레임워크를 개발하는 개발자는 프레임워크가 여러 도메인에 적용됨에 따라 나타나는 문제를 해결해 프레임워크 코드와 디자인에 반영시켜야 하며 하드웨어의 변화, 운영체제 등의 환경 변화를 수용하면서 되도록 하위호환성을 가지게끔 프레임워크를 발전시켜야 한다. 프레임워크를 발전시킬 때, 프레임워크를 설명하는 문서와 첨부된 문서들은 프레임워크를 발전시킬 만한 이슈가 나오기 이전에 만들어진 경우가 많으므로, 대부분의 경우 도움이 되지 못한다.

프레임워크를 발전시키기 위해 프레임워크 유지 보수자는 소프트웨어 전문가일 뿐만 아니라 도메인 전문가 입장에서 문제를 바라볼 수 있어야 한다. 소프트웨어 전문가 입장에서 프레임워크 아키텍처를 살펴보고 프레임워크의 구성이나 어떻게 만들어졌는지, 그리고 목적이 무엇인지 정확하게 이해해야 하고, 도메인 전문가로서 현재 프레임워크가 발전할 수 있는 요수가 무엇인지 분석할 수 있는 능력이 있어야 한다. 소프트웨어 전문가가 아닐 경우 프레임워크의 목적과 구성을 잘못 이해해서 프레임워크의 수정 방향이 잘못 이뤄질 수 있다. 특히 눈앞의 도메인 문제만을 프레임워크에 적용시키려 하면 프레임워크의 목적이 변경되어 질 수 있으며 이때 ‘프레임워크 내부 디자인의 이해’ 패턴과 ‘애플리케이션 도메인의 이해’ 패턴이 정확한 판단을 하는 데 도움을 줄 수 있다.

프레임워크 학습
프레임워크 내부는 커다란 아키텍처 안에 많은 디자인 구조들이 들어가 있고, 디자인마다 다양한 코드들이 존재하게 된다. 일반적으로 애플리케이션은 시작 지점이 존재해서 실행하게 되고 따라서 실행 지점부터 애플리케이션의 수행을 알아본다면 애플리케이션의 분석을 쉽게 할 수 있지만, 프레임워크는 시작점이 없는 특징을 가지고 있기 때문에 일반 애플리케이션처럼 진입 전부터 분석하는 방법은 사용할 수 없다.

프레임워크를 분석하는 방법으로 하향식 방법(Top-down)과 상향식 방법(bottom-up)이 있다. 하향식 방법은 추상화된 레벨에서부터 분석을 시작하는데, 큰 그림을 먼저 잡고 목적을 파악한 다음 서서히 구현부로 내려오면서 프레임워크를 이해하는 방법을 의미하고, 상향식 구현 방법은 거꾸로 세부 구현부터 살펴보면서 점차 추상화된 레벨로 올라가면서 전체적인 구조를 파악하는 분석 방법이다. 두 가지 방법은 모두 장단점을 가지고 있기 때문에 개발자가 자신이 편한 방법으로 분석하면 되는데 대체로 프레임워크에 대한 경험이 많은 사람은 하향식 방법을 사용하면 빠르고 효율적이게 분석할 수 있다. 경험이 많은 개발자는 구현부에 만들어진 코드에 대한 대략적인 지식을 가지고 있으므로 추상화 단계를 보고 전체적인 구조를 쉽게 파악할 수 있기 때문이다. 다양한 상황에 대한 생각을 많이 하는 사람이나 전체적인 기능 파악을 먼저 하는 것을 선호하는 사람 또한 하향식 방법이 좋다. 반면 순차적으로 학습하기를 선호하고, 학습할 때 능동적으로 찾아 학습하는 경향이 있는 사람에게는 상향식 방법이 좋다.

사용 경험의 보전 방법
프레임워크를 애플리케이션에 적용하고, 도메인에 특화된 문제를 프레임워크에 끼워 넣는 작업 프레임워크의 아키텍처와 구조 학습이 선행된 다음에 가능한 작업이다. 이렇게 프레임워크 사용 작업을 반복하면 프레임워크 사용법과 주의사항들이 자연스럽게 학습되고 세부 구조를 쉽게 이해하게 되는데, 이렇게 생긴 노하우나 프레임워크 정보들은 단기간 내에 문서를 보거나 예제를 학습함으로써 얻을 수 없는 것들이 많다. 특히 특정 상황에서 프레임워크의 동작이나 특화된 디자인으로 인해 주의해야 할 점, 프레임워크를 이해하는 과정 중에서 생긴 노하우나 그밖에 프레임워크 관련 정보들에 대해서는 보존하는 것이 좋다.

프레임워크 사용 경험을 보전하는 가장 좋은 방법은 정보들에 대한 문서화하는 것이다. 프레임워크 사용 경험을 문서화시키고 실제 사용했던 코드나 테스트했던 코드들의 레퍼런스나 케이스를 정리하고 포함해 정보들을 문서화해 공유한다면 추후 다시 한 번 볼 수도 있고, 다른 개발자들에게 전파할 수 있다.

애플리케이션 도메인의 이해
프레임워크가 해결해줄 수 없는 애플리케이션 문제는 프레임워크를 적용한 후에 별도로 구현해줘야 하기 때문에 프레임워크를 선택할 때는 애플리케이션에서 구현할 내용들을 해결해줄 수 있는 범위가 어디까지인지 파악하는 것이 중요하다. 이때 도메인에 대한 지식이 부족한 상태라면 프레임워크의 선택을 잘못할 위험이 있으므로, 성공적인 프레임워크 선택에는 도메인의 문제를 잘 파악하고 있는 부분이 중요하게 작용한다. 프레임워크 선택 전 도메인 문제에 대한 지식이 부족한 상태라면 도메인 전문가의 조언을 받아서 도메인에 대한 정보를 확보할 필요가 있다. 전문가의 조언을 받으면서 프레임워크에 포함된 문서의 프레임워크 소개 내용이나 프레임워크가 가지고 있는 해결 방법의 범위와 목적을 알아 가면 해당 프레임워크가 도메인 문제를 푸는 데 적당한지 여부를 판단할 수 있다.

문서화와 예제가 충실하게 잘 갖춰져 있지 않은 프레임워크일 경우 정보를 얻기가 쉽지 않은데, 프레임워크에 대한 정보를 얻기가 여의치 않으면 프레임워크가 가지고 있는 컴포넌트의 이름이나 클래스 이름, 함수 이름들을 살펴보고, 이들을 문서에서 검색하거나 웹을 통해 검색하면 프레임워크의 정보에 대한 힌트를 얻을 수 있다. 이러한 분석을 하다보면 컴포넌트 간의 관계가 파악되는데, 이를 통해 프레임워크의 아키텍처에 대한 구조 정보를 얻을 수 있다. 이러한 구조 정보는 도메인의 적용 범위를 알아볼 때 유용하게 쓰인다.

프레임워크 아키텍처의 이해
프레임워크 기반의 애플리케이션은 프레임워크의 의도에 따라 애플리케이션의 구조가 결정된다. 따라서 프레임워크의 아키텍처는 애플리케이션에 직접적인 영향을 미치게 되므로 프레임워크의 아키텍처 구조를 이해하는 것은 애플리케이션의 흐름과 구조를 파악하는 것과 밀접한 관계가 있다. 구조를 파악하게 되면 프레임워크의 구현체를 재사용하기에 더 용이하며 컴포넌트끼리의 관계를 파악할 수 있으므로 빠르고 정확한 프레임워크 적용이 가능해진다. 화이트박스 프레임워크의 경우 구조를 파악하지 않은 채 상속을 통해 애플리케이션의 기능을 구현하다보면 컴포넌트 간의 관계나 프레임워크 아키텍처 상 맞지 않는 코드를 작성할 수 있으므로 프레임워크의 아키텍처를 파악하는 일은 중요하다.

<그림 4>의 경우 복잡한 네트워크 프레임워크의 아키텍처를 구성하는 패턴들을 나타내고 있으며 각 패턴들이 연결되어 있는 관계도를 도식화해 나타내고 있다. 이처럼 프레임워크의 아키텍처를 이해할 수 있는 문서가 있다면 쉽고 빠르게 구조를 파악하는 데 도움을 받을 수 있다. 아키텍처를 파악할 때는 글과 코드만으로는 한눈에 알아보기 어려운 경우가 많다. 때로는 리버스 엔지니어링 툴을 이용하면 프레임워크의 구조를 알아보는 데 도움을 받을 수도 있다.

프레임워크 내부 디자인의 이해
프레임워크의 아키텍처로 애플리케이션이 문제를 해결하는 방향을 잡는다고 한다면, 애플리케이션에서 도메인에 대한 문제를 유연하게 풀어나가는 것은 내부 디자인에 의해 결정된다. 주로 간단한 패턴들로 이뤄진 내부 디자인은 프레임워크의 확장성과 유연성이 실제적으로 구현되는 부분이기도 하며 프레임워크가 다수의 애플리케이션에 공통적으로 적용시킬 수 있는 특성과 코드를 재사용하는 특징 또한 이 내부 디자인을 통해 제공하게 된다.

실제로 프레임워크를 사용하는 데 있어서 단번에 이해할 수 없도록 복잡한 느낌을 주는 이유도 이 내부 디자인에서 오기 때문인데, 따라서 내부 디자인을 이해하는 것은 실제적으로 프레임워크를 사용하는 데 직접적인 영향을 줄 뿐만 아니라 프레임워크를 좀 더 다양하게 활용할 수 있는 요소를 제공하기도 한다.

애플리케이션에서 프레임워크를 적용하기 위해서 내부 디자인을 살펴볼 때는 그 내부 디자인이 화이트박스 프레임워크를 의도하는지, 블랙박스 프레임워크를 의도하는지 파악하는 것이 중요하다. 이러한 파악에는 특히 디자인 패턴에 대한 선행학습이 큰 도움이 되며, 디자인 패턴에서 말하는 패턴들의 장단점, 그리고 의도를 미리 알고 있다면 프레임워크를 어떤 식으로 사용해야 바람직하고 좋게 사용하는 것인지 판단하는 데 큰 도움이 된다. 프레임워크 내부 디자인을 이해하면 프레임워크에서 의도하는 프로즌 스팟과 핫 스팟의 위치를 파악할 수 있고, 코드의 흐름과 프레임워크를 구성하는 컴포넌트들의 관계를 정확하게 파악할 수 있으며, 프레임워크를 실제 애플리케이션에 적용하는 데 필요한 방법과 정보를 정확하게 알아낼 수 있다.

프레임워크 코드의 이해


프레임워크를 만든 개발자들은 다수 도메인 문제에 대한 많은 경험과 높은 프로그래밍 실력을 가지고 있는 경우가 일반적이다. 이러한 프레임워크 개발자들이 만들어 놓은 프레임워크 코드들은 경험이 부족한 개발자들이 보기에 올바른 코딩 방향과 좋은 코딩 습관을 길러주는데 좋은 본보기가 되는데, 이는 애플리케이션에 적용할 프레임워크를 이해하는 것뿐만 아니라, 프레임워크를 만든 프로그래머들의 프로그래밍 경험을 얻을 수 있는 좋은 기회가 된다.

 

프레임워크가 일반적인 애플리케이션 코드보다 이해하기가 힘든 이유는 일반적인 애플리케이션은 시작점과 종료점이 있는 반면에, 프레임워크는 애플리케이션과 다르게 시작하는 지점이 없기 때문일 것이다. 다시 말해 분석하는 시작점을 찾을 수 없어서 분석하기가 어렵게 느껴지는 경향이 있는 셈이다. 라이브러리와 프레임워크 사용의 가장 큰 차이점은 라이브러리의 경우 애플리케이션에서 구현체를 사용하기 위해 라이브러리의 기능을 호출하는 형태로 사용하지만, 프레임워크의 경우 반대로 프레임워크에 의도하는 구조에 따라 애플리케이션의 흐름이 운용된다는 것이다. 이는 라이브러리를 사용하는 일반 애플리케이션보다 프레임워크를 사용하는 애플리케이션의 코드 분석이 더 어렵게 만드는 이유가 되기도 한다.

프레임워크 코드를 이해하는 가장 좋은 방법은 프레임워크를 이용해 문제를 해결하는 예제를 분석하는 방법인데, 예제의 시작점부터 출발해서 문제를 해결하기 위해 프레임워크가 호출하는 진입점을 살펴보면 쉽게 코드를 분석할 수 있다. 프레임워크는 보통 예제문서와 다양한 도메인 환경에서 프레임워크를 사용하는 방법을 첨부하는데, 이러한 문서들은 프레임워크 코드 분석에 도움을 준다.

참고자료
1. Patterns for Understanding Frameworks (Nuno Flores, Ademar Aguiar) - PLOP’08
2. QoS Middleware Coursework (Douglas Schmidt) - http://www.cs.wustl.edu/~schmidt/cs396/index.html
3. Advanced Software Engineering - CSE870, Spring 2007
4. Testing framework-based software product lines = Raine Kauppinen



반응형
프로그래밍을 하다보면 자연스럽게 접하게 되는것이 디자인 패턴일 것이다.
나도 확실한 개념을 정립하고 있진 못하지만 "Head First Design Patterns" 란 책을 통해 접하고 있다.
조금씩 패턴에 대해 알아가면서 아하! 하고 무릎을 탁치기도 하고 패턴을 적용해 보고 싶은 맘도 든다.
그리고 자바 API를 보면서 무슨 패턴을 적용한거군 하고 알게 되기도 하고 흥미롭다.
마소컬럼중에 아키텍처 패턴이야기가 있어서 퍼오게 되었다.^^

<출처: http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=33149 >

 패턴을 대하기 이전의 마음가짐 - 유연성, 확장성


많은 이들과 패턴을 주제로 얘기하다 보면, 패턴에 대한 잘못된 관점을 가진 경우를 종종 보게 된다. 패턴을 통해 비약적인 성능 향상이나 생산성 증대가 이뤄질 거라 생각하는 사람도 있고 심지어 ‘Silver Bullet(묘책)’으로 생각하는 이도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.

 

초창기 객체 지향(80년대)에서 가장 중요시 여기던 패러다임은 ‘Reuse(재사용)’이었다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 레고(Lego)와 같이 조립만 하면 만들어지는 레고웨어(Legoware)를 꿈꾸어 오면서….

하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명이서는 결코 만들 수 없을 만큼 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향으로 재사용성보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.  그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기는 어려우므로, 예전에 필자가 마소 2007년 8월호에 기고한 ‘미워도 다시 보는 패턴 이야기’를 꼭 읽어보길 권한다. 이 글에서는 패턴의 정의, 원칙, 참고할 만한 설계구조도 설명하고 있다.

패턴은 올바른 아키텍팅을 하기 위한 전술
2007년 10월 『Software Architecture in Practice』의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대해 강연했다. 세미나를 마친 후 어떤 이가 “당신과 같이 훌륭한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?”라고 질문했고 그에 대한 대답으로 아키텍트의 덕목 중 전술로서의 패턴이 지닌 가치를 설명했다.

“전술이란, 전략에 비해 단기적인 의미를 가지는 것으로 소프트웨어의 큰 구성요소들을 나누고, 구성 요소 내에서 어떻게 구현 및 실행해 나갈지 계획을 세워나가는 것을 의미합니다. 이러한 전술을 많이 알고 있어야, 내실이 튼튼한 소프트웨어가 나올 수 있죠. 전술을 많이 알기 위해서는 경험 못지않게 간접 경험, 즉 패턴을 익히는 것도 중요합니다.” 

간략히 패턴에서 전술의 예를 든다면 분산 객체의 마샬링(marshaling) 정책을 들 수 있다. Loosely Coupling하게 마샬링하기 위해 프로토콜 기반의 설계를 사용함으로써 확정성이나 관리의 용이성을 획득하지만, 응답속도나 처리량을 포기해야 한다. 반면에 Tightly Coupling하게 마샬링하기 위해서는 Simple Object를 만들어서 사용하는 방법이 있는데, 시스템에 종속적이고 변화에 유연하지 못한 단점이 있는 반면에 응답속도나 처리량이 더 뛰어나다. 흔히 Web Service(전자인 경우 - SOAP에 의한 프로토콜 전송 방식)과 COM+(후자인 경우 - Simple Object)의 데이터를 주고받는 경우라고 할 수 있다. 만약 여러분이 패턴을 통해 이러한 전략을 습득하고 있다면, 아키텍팅을 수립하는 데 겪는 많은 시행착오를 줄일 수 있다. 

패턴의 시작은 GoF부터?
GoF 책이 명서이며 패턴계에 큰 영향을 끼친 서적임은 분명하다. 하지만 독자 여러분이 처음 패턴을 접한다면 GoF의 『Design Pattern』이라는 서적은 난해할 수도 있다. 필자는 GoF 책이 처음 패턴을 접하기에는 난해하다고 말하는 개발자를 보았다. 필자 역시 GoF 책을 이해하기 위해서 세 번을 읽었고 읽을 때마다 새로운 느낌을 받았다. 마치 성경을 읽는 느낌이라고 할까? 그 만큼 깊이가 있는 책이다.

GoF 책은 1990년대 후반부에 쓰인 터라, 1990년 중반부에 사용되는 애플리케이션을 예로 들어 설명했고, C++의 이해를 수반으로 하고 있으므로 현재 우리가 관심을 가지고 있는 애플리케이션과는 약간 범위가 다르며 자바나 C#에 익숙한 초보 개발자에게는 난해할 수 있다. 그래서 2000년대에 이슈인 데이터베이스 프로그래밍과 같이 누구나 쉽게 이해할 수 있는 수준으로 설명한 책이 『Design Pattern Explained』였고 국내에서는 ‘알기 쉬운 디자인 패턴’이라고 번역되어 있다. 불과 4년 전 만해도 초보자를 위한 디자인 패턴 책은 이것밖에 없었다. 하지만 현재는 뇌공학을 연계로 해서 쉽게 개념을 파악할 수 있는 좋은 서적이 나왔다(『Head First Design Patterns』, 『알기 쉬운 디자인 패턴』 등).

다음 단계 서적으로는, 구체적으로 하나의 언어를 정해 언어별 특성을 파악하며 패턴을 살펴볼 필요가 있다. 여러분이 자바에 관심이 많다면 『Java 언어로 배우는 디자인 패턴 입문』을 추천하며 C++에 관심 있는 개발자라면 『GoF 디자인 패턴! 이렇게 활용한다』를 권하고 싶다. 그 이후에 GoF 서적을 보면 한결 수월하게 읽을 수 있을 것이다. GoF 패턴을 충분히 이해했지만, 프로그래밍에 바로 적용하는 사람은 그다지 많지 않을 것이다. 왜 그럴까? GoF 패턴은 패턴의 가장 기본인 Micro Pattern일 뿐이다. GoF 패턴은 단지 시작에 불과하다.

가족을 이루는 패턴 군을 파악하라
GoF 패턴을 읽은 다음 POSA 시리즈로 불리는 서적들이 있다. GoF와 어깨를 나란히 하는 패턴계의 명서 중에 명서이며, GoF를 읽은 분이라면 패턴에 좀 더 깊은 세계를 맛보도록 도와준다. GoF(1995년)가 나온 1년 뒤(1996년)에 볼륨 1권이 출간되었지만, 국내에는 2008년도에 역서가 나왔기 때문에 패턴 초보자들에게는 그리 알려지지 않은 서적이라고 할 수 있다. GoF가 가벼운 Micro Pattern이었다면, POSA는 좀 더 세부적인 도메인을 다루고 있다.

- Volume 1: Architectural Pattern (소프트웨어 구조를 잘 설계하기 위한 패턴)
- Volume 2: Concurrent and Networked Object Pattern (분산객체를 위한 패턴)
- Volume 3: Resource Management Pattern (자원을 잘 관리하기 위한 패턴)

이 책을 탐독하면 자연스럽게 패턴 군(Compound Pattern)들이 눈에 보이게 된다(물론 GoF 패턴이 밑단에 전체적으로 깔려 있다). 즉 패턴 하나가 혼자 쓰이지 않고 같이 잘 엮여 사용되는 패턴들이 보이기 시작할 것이다. 바로 이러한 패턴 군을 많이 습득하는 것이 패턴을 습득하는 올바른 방법이다. 그럼 소프트웨어 기본 구조에서 볼 수 있는 간략한 사례를 들어 패턴 군을 설명해 본다.

소프트웨어는 <그림 1>처럼 크게 세 가지 요소로 구성되는데 각각 공용부, 가변부, 설정부이다. 공용부는 소프트웨어의 많은 Feature에서 공통적으로 사용하는 부분으로 log, transaction, security와 같은 모듈을 말하며, 요즘 Aspect와 같은 기술들로 구성하는 것이 추세다. 우리가 눈여겨봐야 할 것은 설정부와 가변부이다. 그럼 하나하나씩 살펴보자.

Component Configurator Pattern


아키텍처 패턴(Architectural Pattern)을 다룬 『POSA1』 서적을 통해 알려진 패턴으로, 런타임시 사용하는 컴포넌트들을 제어하고, 시스템 중지 없이 컴포넌트를 추가, 제거, 교체할 수 있는 패턴이다.

 

<리스트 1>과 <리스트 2>는 Component Configurator 패턴의 간단한 샘플이다. 설정 파일(<리스트 1>)의 프로토콜이 HTTP면 그 정보를 읽어 HTTP 프로토콜로 메시지를 전송하고 FTP 프로토콜로 설정되어 있다면 FTP 프로토콜로 메시지를 전송할 수 있다. 이렇게 함으로써 런타임시에 객체의 속성을 정의해 변화에 유연하게 대처할 수 있다.

하지만. 새로운 프로토콜이나 로깅 정책이 추가되어야 한다면 <리스트 2>의 코드도 변경될 수밖에 없다. 이러한 문제를 해결하기 위해 Component Configurator 패턴은 Reflection 패턴과 병행해 사용해야 한다. Reflection은 런타임시에 객체를 생성하는 패턴으로, 이미 닷넷(.NET)과 자바 플랫폼에서 지원하고 있다. 여기서 Component Configuration을 통해 객체 정보를 읽어와 생성하는 Factory를 만들면, 객체를 생성하는 클라이언트 입장에는 별 걱정 없이 객체를 생성할 수 있다. 

Template Method Pattern


Template Method 패턴의 가장 대표적인 예가 xDBC (ODBC, JDBC)이다. 댜양한 제품의 DB에 상관없이 xDBC에 동작하는 쿼리만 알면 언제든지 DB 제품을 쉽게 교체해서 쓸 수 있다. Template Method 패턴은 다른 패턴이 가지고 있지 않은 전체적인 흐름을 제어하는 Template Method(위 예에서는 doQuery)를 가지고 있는데, <리스트 3>의 doQuery를 보면 DB에 연결을 맺고 쿼리를 얻어오는 흐름이 슈퍼클래스(super class)에 있는 것을 볼 수 있다. 서브클래스(subclass)들은 슈퍼클래스의 계약에 따라 움직여야 하는 강력한 제약 상황에 놓여 있게 된다. 이로써 DB 제품을 별 걱정 없이 교체할 수 있는 큰 장점을 얻을 수 있다. 특히 프레임워크들은 일괄적인 제어 흐름과 상황에 맞게 서브클래스를 교체하기 위해, 필수적으로 Template Method를 사용한다.

 

<그림 1>을 다시 한 번 보도록 하자. 이제 전체적인 그림이 이해가 갈 것이다. 설정부에 객체의 속성을 Component Confi gurator를 통해 정의해 놓는다. 그 후 객체가 생성되는 시점에서 Factory가 현재의 상황을 고려해 적합한 객체를 선택한 후, 메모리에 로딩한다. 단 가변부에 있는 객체는 쉽게 교체할 수 있어야 하므로, Template Method나 Strategy와 같이 동일한 계약 상황(인터페이스를 구현하거나 Abstract를 상속하는 형태)을 유지해야 한다.

눈치 있는 독자는 이 구조를 어디서 많이 보았다고 생각할 것이다. 바로 스프링(Spring)과 같은 Dependency Injection Con tainer를 설명한 것이다. 좀 더 자세한 설명을 원한다면 필자의 블로그(종속성을 관리하는 방법 - http://arload.wordpress.co m/2008/12/07/dependency_managment/)를 방문하길 바란다.

아키텍팅의 핵심 SoC, 그리고 문제 중심으로 바라보기
소프트웨어 공학에 관심이 있는 독자라면 누구나 걱정거리의 분리, 관심거리의 분리라고 말하는 SoC(Separation of Concerns)를 들어본 적이 있을 것이다. 필자는 얼마 전 SoC와 복잡성에 대해 논쟁을 주고받은 적이 있다. 필자는 이 논쟁을 통해 SoC와 소프트웨어 아키텍팅의 가치/패턴의 연관성에 대해 다시 생각할 수 있었다. SoC라는 단어를 세상에 처음 발표한 Edsger W. Dijkstra의 정의는 다음과 같다.

“focusing one’s attention upon some aspect”

여러 가지 측면들을 동시에 생각하기는 힘드니, 잘 나누어 각각의 요소에 한 가지 관점만을 적용해 바라보겠다는 의미다. 흔히 분할 후 정복(Divide and Conquer)과 일맥상통하는 말이라 할 수 있다. 다양한 이해 당사자의 요구, 프로젝트의 특수한 상황, 잘못 설계된 아키텍처로 인해, 하나가 바뀌면 연쇄적으로 다른 곳에 변화가 발생하는 파문 효과(Ripple Effect)를 종종 만나게 된다. 이때 우리가 특히 중점을 두어 관리해야 하는 것이 종속성(Dependency)인데, 이러한 종속성이 유발시키는 강결합을 무너뜨리는 좋은 가이드라인을 제시하는 것이 바로 패턴이다. SoC를 얼마나 잘하느냐가 아키텍팅의 성공과 실패를 결정하므로, 패턴 기반의 좋은 참조 아키텍처(Reference Architecture), 특히 패턴 기반으로 구축된 시스템을 평소에 틈틈이 공부할 필요가 있다. 그 이유는 패턴은 군을 이뤄 사용되기 때문이다. 특히 도메인에 한정될수록 사용되는 패턴 군들은 더 제한적이다.

어느 날 갑자기 여러분의 상사가, 모든 환경에서 좋은 성능을 보이는 웹 서버를 설계(SoC)하라고 한다면 어떻게 해야 될까? 먼저 비슷한 선례, 즉 참조할 만한 아키텍처가 있는지 찾아볼 것이다.

유명한 TAO/ACE의 창시자인 Douglas C. Schmidt 박사는 이에 대한 대답으로 주고받는 파일이 사이즈, 클라이언트의 다양한 요청 속성(예를 들면 요청 빈도, 요청시 얼마나 오랫동안 세션을 맺고 있는지 등), 고객의 웹사이트 접근 경로 등을 고려해 환경에 맞게 적절한 전략을 변경할 수 있는 웹서버 JAWS의 소스 코드와 아키텍처를 공유했다(필자의 JAWS 아키텍처 동영상 강의- http://www.devpia.com/net2/EvaCast/Lecture/ ?cu=view&r=11 참조).

이렇게 괜찮은 참조 아키텍처를 발견했다고 하더라도, 왜 이렇게 아키텍처가 구축되었는지에 대한 문제 상황의 깊은 이해가 요구된다. 어떤 부분에는 유연성을 중심으로 설계했고, 또 다른 부분은 유연성보다는 성능을 중심적으로 설계했다. 왜 이렇게 결정했을까? 결국 이렇게 구축한 시스템의 의도를 잘 파악하기 위해서는 패턴을 하나의 해결책으로 바라보는 것이 아니라, 패턴의 의도와 다루는 문제들을 중심적으로 바라볼 필요가 있다. 특히 아키텍처가 거대해질수록 이러한 접근법은 더 효율적이다.
좋은 패턴 서적 소개

현재 발표된 다양한 패턴 서적들을 소개하니 여러분의 프로젝트나 관심 분야 서적들을 골라 읽어보길 바란다.

● PLoPD 시리즈
해마다 다양한 곳에서 여러 종류의 PLoP라는 유명한 패턴 학회가 열린다. 그야말로 패턴의 보고이며, 시중에 나온 새로운 도메인의 패턴 서적들은 거의 다 이 학회를 한번 거쳤다고 해도 과언이 아닐 정도로 영향력을 행사하며 다양한 도메인을 폭 넓게 다루고 있을 뿐만 아니라, 소프트웨어계의 거장들을 만날 수 있는 좋은 학회이다. 이 학회에서 발표된 패턴 중에 괜찮은 패턴들을 묶어 PLoPD(Program Language of Program Design)라는 서적으로 출간되는데 이것 바로 PLoPD이다.   

● POAD(Pattern Oriented Anaysis Design)
그야말로 Pattern Driven Design이라고 불러도 좋을 만큼, 패턴을 활용해 분석이나 적합한 전략/전술을 선택하는 가이드라인을 제공하는 서적이다. 아마존에서 호평을 받았지만, 국내에서는 잘 소개되지 않았다. 학교 도서관이나 주위에 있는 분이 가지고 있다면 꼭 읽어 보길 권한다.

● Holub on Patterns(실전 코드로 배우는 실용주의 디자인 패턴) 
응용프로그램 2개를 기반으로 GoF패턴 23개를 모두 다루고 있는 서적이다. GoF 패턴의 가치를 느낄 수 있는 서적이며, 특히 패턴 군(Compound Pattern)들에 대한 좋은 시선을 제공하는 서적이다. 거기다 패턴을 만드는 5원칙을 역자가 직접 추가해 넣어주었기 때문에 패턴을 학습한 이들에게도 좋은 서적이다.

● Remoting Patterns
POSA2가 오픈소스 CORBA인 TAO, ACE에 사용된 패턴을 소개한다면, 조금 더 최신 기술인 .NET Remoting, EJB, Web Service, CORBA에 사용된 분산 패턴들을 소개하는 책이다. 겉보기에는 POSA2와 다른 패턴을 소개하고 있는 것 같지만 다시 한 번 되짚어보면 POSA2에 소개된 패턴과는 내부 맥락이 같다. 이 서적을 통해 최신 분산 기술에 정리된 내용을 체계적으로 정리할 수 있고 다양한 분산 객체들의 아키텍처를 비교, 평가할 수 있다.

● xUnit Test Patterns
TDD가 이슈가 되면서 테스팅(Testing)에 대한 관심이 매우 높아졌다. VS.NET과 이클립스(Eclipse) 역시 이러한 흐름에 발 맞춰 다양한 테스팅 관련 기능을 제공하고 있다. 그 중 여러분이 가장 자주 사용하는 것은 아마 xUnit(JUnit, NUnit, CUnit…)일 것이다. 이 책은 유닛 테스팅(Unit Testing)을 하기 위해 어떻게 테스팅 코드를 작성하고 리팩토링을 하는지를 자세히 설명한다.

● Patterns For Fault Tolerant Software(耐고장성 소프트웨어를 위한 패턴)
퀄러티(Quality) 검증의 TDD와 방어적인 프로그래밍을 넘어서, 내부적인 고장에도 스스로 복구 및 조치를 취할 수 있는 신뢰성 있는 소프트웨어를 개발하는 데 지침이 되는 서적이다. Error Handling/Mitigation, Fault를 Detection하는 다양한 패턴들을 소개한다.

● PEAA(Patterns for Enterprise Application Architecture)
리팩토링의 창시자인 Martin Fowler가 쓴 책으로, 엔터프라이즈 애플리케이션을 설계하기 위한 다양한 패턴이 소개돼 있다. 물론 POSA나 PLOP에 나온 패턴을 현대적으로 바꾼 것이 대부분이지만, Martin Fowler의 과거 기술, 용어, 개념들을 현대에 맞게 변형, 확장하는 능력을 다시 한 번 느낄 수 있는 서적이다. SI 분야에 속해 있다면 역서라도 꼭 읽어보길 권한다.

● Enterprise Integration Patterns
EAI를 위한 메시징(Messaging) 처리에 중점을 둔 서적이다. 어떻게 메시징 시스템을 만드는지 자세히 설명했고, BPM/ EAI/Enterprise SOA에 관심이 있다면 읽어볼 필요가 있다.

● Real-Time Design Patterns
Real-Time 시스템을 구축할 때 가장 고려해야 할 것이 예측성이다. 우선순위를 고려하고 주어진 데드라인 안에 작업(Job)이 수행될 수 있는지 판단하는 것이 가장 핵심이다. 만약 현재의 요청한 작업이 제한 시간 안에 답변을 줄 수 없을 것 같다면, 차선책을 선택하는 형태로 설계되어야 한다. 이러한 우선순위와 스케줄링에 관심 있는 개발자라면 도움이 될 서적이다.

● Refactoring to Patterns
패턴을 활용하여 리팩토링하는 방법을 소개하는 서적이다. Martin Fowler의 리팩토링을 읽은 독자라면 그 다음 이 서적을 읽어 보길 권한다. ‘패턴을 활용한 리팩토링’이라는 제목으로 역서가 출간되었다.

● Architecting Enterprise Solutions
고성능과 인터넷 기반의 시스템을 구축할 때 유용한 패턴 서적으로, 실제 실무에 인프라를 구축하는 개발자에게 적합하다. 시스템 제어, 성능 측정, 적절한 서버 수 산정과 같은 유용한 가이드라인이 제공된다.

끝나지 않는 패턴 이야기-PLoP
지구상에서는 여전히 많은 패턴들이 계속 발표되고 있다. 그 중 여러분에게 가장 소개하고픈 것은 매년 열리는 PLOP 학회에서 발표된 논문이다.

- PLoP(미국에서 열리는 기반 학회) http://arload.wordpress.com/2008/04/02/plopfestival/
- EuroPLoP(유럽에서 열리는 패턴학회 자료) http://arload.wordpress.com/2008/08/11/euro_plop_paper/

관심 있는 독자는 지난 10년간 발표된 패턴들을 끊임없이 학습하길 권하며 이 글을 마친다. 그 이외에도 다양한 패턴 학회가 존재하지만, 언어적인 제약이나 자료 수집의 어려움 때문에 일부만 소개한다. 

- ChiliPLoP(Hot Topic을 위주로 다루는 패턴 학회)
- KoalaPLoP(오스트렐리아인을 위한 패턴 학회)
- MensorePLoP(일본에서 열리는 패턴 학회)
- SugarLoafPLoP(라틴 아메리카인들을 위한 패턴 학회)
- VikingPLoP(북 유럽 사람들을 위한 패턴 학회)

참고자료
1. Rick Kazman, 소프트웨어 아키텍처 이론과 실제, 에이콘출판
2. Rick Kazman, 아키텍트가 되기 위해 갖추어야 할 덕목 - http://arload.wordpress.com/2008/06/13/rickkazman/
3. The JAWS Adaptive Web Server - http://www.dre.vanderbilt.edu/JAWS/,
http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=11 
4. Edsger W. Dijkstra, “On the role of scientific thought” - http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
5. 손영수, 미워도 다시 보는 패턴 이야기, 마이크로소프트웨어 2007년 8월호



반응형

최근에 본 논문 중에 괜찮은 것이 있어 하나 소개합니다.

소프트웨어 엔지니어링 (Software Engineering, SE) 그 중에서도 품질 보증 (Software Quality Assurance, SQA) 분야에서 아래와 같은 이론은 누구나 알고 있는 자명한 사실일 것입니다.

결함을 늦게 발견할 수록 결함을 수정하는 비용은 증가한다. 즉, 소프트웨어 결함은 조기에 발견할 수록 비용을 절감할 수 있다. 그런 결함 발생 예방 활동 중 대표적인 것이 코드 인스펙션 (Inspection)과 리뷰 (Review)활동이라고 할 수 있을 것이다.

그런데 만약 당신의 상관이나 조직 구성원 중 누군가가 코드 리뷰를 해보지도 않고서 또는 형식적으로 어설프게 해보고

"코드 인스펙션하면 얼마나 효과적인데? 코드 짜고 테스트 케이스 짜서 돌려보는게 더 낫지 않어?"

라는 질문을 던진다면, 주관적인 설득의 무기밖에 소지하고 있지 못한 자신을 발견할 것입니다.

서론이 좀 길었지만, 이런 상황에서 권위 있는 사람의 정량적 실험에 관한 그리고 미국 국방성 (DoD)에 제출한 논문 한편이 큰 도움이 될 것같습니다.

소개할 논문은 논문 저자가 ROI를 측정하기 위해 유사한 소프트웨어 개발 환경에서 Inspection, PSP, TSP, SW-CMM, ISO9001, CMM를 적용한 사례들도 이야기해주는데 국내의 활동과는 너무나 다른 것 같습니다.
가령, 코드 인스펙션으로 한 번의 미팅에서 보는 코드 라인을 240줄로 잡고 있습니다. 240줄! 물론 공백과 주석은 뺐겠지만 국내에서는 상상할 수 없는 라인 수 일 것입니다.

※ 글 중 [ <number> ] 는 참고 문헌입니다.

논문 소개

논문의 제목은 아래와 같고 여기에서 PDF 버전을 다운로드 받을 수 있습니다.

인스펙션, PSP, TSP, SW-CMM, ISO 9000, CMMI의 ROI를 어떻게 예측할 것인가?

How to Estimate ROI for Inspections, PSPsm, TSPsm, SW-CMMâ, ISO 9000, and CMMIsm

저자는 David F. Rico 입니다.
저자 David F. Rico에 대해서 먼저 소개하면 그의 컨설팅 홈페지이에 나와있는 소개 처럼,

소프트웨어 프로세스와 품질 향상에 관한 세계적인 기술 리더로써 15개 이상의 SW-CMM 레벨 2~5 적용 과제를 미국 NASA, 미 공군, 해군, 일본 기업들에서 이끌거나 참여했으며 특히 Software Engineering에 대한 ROI (Return Of Investment) 관련 책과 논문으로도 유명합니다.

이 논문은 미 국방성 (DoD)에 제출된 논문으로 결과부터 말씀 드리면 아래 그래프와 같이 여러 활동 중에서 코드 인스펙션 (inspection)이 ROI 측면에서 가장 효과적이라는 것입니다.

즉, 투자한 비용 대비 가장 효과가 높다는 겁니다.

ROI 측정 방법 [2]

David F. Rico가 ROI를 측정하기 위한 방법을 간단히 소개하면 아래와 같습니다.

  • Benefit/Cost Ratio (B/CR)
    이익을 투자한 비용으로 나눈 것입니다.
    이익/투자 비용
  • Return on Investment (ROI%)
    이익에서 투자 비용을 빼고 이 것을 다시 투자 비용으로 나누어 백분율을 계산
    (이익 - 투자 비용) / 투자 비용 × 100

즉, 위의 두 ROI 측정 방법을 이용해서, 각 활동을 위해 수행 인원들의 교육 비용, 수행 인원들의 활동 시간에 따른 비용을 투자 비용으로 계산하고 전체 소프트웨어 개발 기간 동안 절감된 시간과 그에 따른 비용을 이익으로 계산했습니다.

그 결과가 Benefit/Cost Ratio 상으로도 Inspection이 가장 뛰어납니다.

각 활동들의 수행 내역과 결과를 보면 아래와 같습니다.


전제

  • 한 프로젝트는 4명의 멤버가 수행합니다.
  • 한 사람의 한 시간당 인건비는 $100 입니다.
  • 개발할 소프트웨어는 SLOC가 10,000입니다.

1. Inspection

1. 교육 비용 (Training cost)

Inspection 교육 비용의 평균은 410$이고 한 사람당 24시간 정도 소요되며 한 시간당 인건비는 $100이며 4명을 교육 시켜야 하기 때문에 교육 비용은 다음과 같습니다.


한 사람당 교육 비용 + 24시간 교육을 받는 동안 그 사람의 인건비

= $410 + (24 × $100) = $410 + $2,400 = $2,810

네 사람을 교육 시켜야 하기 때문에 (4 × $2,810) 총 교육 비용은 $11,240 이 듭니다.

2. Inspection 수행 비용

SLOC (Source Line Of Code )가 10,000 일 때 한 시간 동안 Inspection할 SLOC가 240으로 잡을 때 41.67 번의 Inspection을 하고, 한 번 Inspection을 할 때 계획 (planning), overview, 준비 (planning), 회의 (meeting), rework, follow-up 등에 소요되는 시간이 17시간이 들기 때문에 전체 수행 시간은 41.67 × 17로 708.33 시간이 소요됩니다.

시간당 인건비가 $100이기 때문에 총 수행 비용은 $70,833이 듭니다.

※ 미 국방성 (DoD)에 제출한 논문이고 유명한 논문이지만 정말 믿지 못할 만큼 성실하고 자세히 Inspection을 수행하는 것 같습니다.

3. 총 비용 (Total Cost)

교육 비용과 Inspection 수행 비용을 합치면 $11,240 + $70,800 = $82,073이 들었습니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

10,000 SLOC의 소프트웨어를 개발하는 동안 훈련된 Inspector에 의해 Inspection이 수행되고 나서 문제가 발생해서 유지.보수 해야 하는 시간이 총 11,806시간이 들었다고 합니다.

※ 유지.보수는 코드가 잘 못 작성된 것을 추후에 발견해서 고치거나 Integration 또는 Unit/Integration/System Test에서 결함이 발생되어 수정한 시간을 모두 포함했을 것입니다.

이 것은 Inspection을 수행하지 않았을 때 든 유지.보수 시간이 41,800인 것을 29,994 시간만큼 줄인 효과입니다.

즉, Inspection을 수행하고 나니 그렇지 않을 때 보다 29,994 시간이 절약되었고 이 것은 시간 당 인건비 $100을 감안하면 $2,999,400의 절감효과 (benefit)이 생긴 것입니다.

5. B/CR (Benefit/Cost Ratio)

이익을 투자한 비용으로 단순히 나눈 B/CR의 경우는 $2,999,400 / $82,073 = 36.54로 약 37:1의 효과를 가지고 왔습니다.

6. ROI%

이익에서 투자한 비용을 빼고 그 것을 투자한 비용으로 나누어 백분율 (×100)로 표현하는 ROI%의 경우는 (이익 - 투자 비용) / 투자 비용 × 100 이므로

(2,999,400 - 82,073) / 82,073 × 100 = 3,554.55 % 이므로 3,555%가 됩니다.


2. PSP (Personal Software Process)

psp

※ PSP는 위키페이지에서 간략한 설명을 볼 수도 있습니다. 필자도 몇 년 전 PSP 교육을 받아보았는데, PSP는 카네기 멜론 (Carnegie Mellon) 대학에서 만들어진 것으로 원칙이 자신이 맡은 코드를 단 한번에 컴파일을 성공하는 것입니다. 많은 사람들이 코드를 작성하면서 중간 중간에 컴파일을 하면서 에러나 결함을 잡는 것에 비해 PSP는 코드 작성 전이나 코드 작성 중 많은 리뷰 활동을 통해서 이와 같은 것을 가능하게 합니다. 실제 MS에서도 적용 후 놀라운 효과를 보기도 했습니다. 그리고 코딩 시간 및 리뷰를 통해 잡은 에러를 분류/분석해서 정량화 함으로써 문제점을 파악하고 유사 도메인이 과제에 대한 Estimation의 근거 자료로도 쓰일 수 있습니다.



1. 교육 비용

※제가 알기로는 PSP를 교육할 수 있는 자격증은 카네기 멜론 대학에서 이수할 수 있습니다. 그 만큼 교육을 받는 비용도 비싸겠죠?

Software Engineering Institute (SEI)에서 한 사람이 교육을 받는 비용은 $5,000이고 2주간의 항공, 숙박 비 등에 $5,400이 추가로 들며 총 교육 기간은 10일 (80시간)이 소요됩니다. 그리고 각 수업 시간 (1시간) 마다 수업 외의 1시간씩이 더 필요합니다. (제가 교육을 받을 때도 숙제 등의 시간이 많이 필요했었습니다). 즉, 총 160시간 (80+80)이 소요됩니다.

교육비와 부대 비용에 160시간에 대한 인건비 ($100/h)를 계산해보면,

$5,000 + $5,400 + 16,000으로 $26,400이 들고 이 것을 네 명으로 곱하면 총 교육비용은 $105,600입니다.

※ 실제 효과 (benefit)은 PSP가 Inspection에 비해서 높지만 이와 같이 비싼 교육비 때문에 ROI는 낮게 됩니다.

2. PSP 수행 비용

동일한 10,000 SLOC에 대해서 PSP를 적용했을 때 시간당 코딩 할 수 있는 SLOC는 25입니다. ※설명 드린 것처럼 코드를 작성하기 위해 디자인이나 Pseudo 코드, 리뷰, 측정을 할 것이 많습니다. 즉, 10,000 SLOC의 소프트웨어를 개발하기 위해 400시간이 소요되어 총 비용은 $40,000이 됩니다. (※ 4명이 각각 자신의 모듈을 PSP에 따라 작성하기 때문에 Inspection과 달리 4를 곱하지 않습니다)

3. 총 비용 (Total Cost)

총 비용은 교육 비용 $105,600에 수행 비용 $40,000을 더한 $145,600입니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

10,000 SLOC의 소프트웨어에 대한 코드 작성 이후의 유지.보수 비용은 앞에서 이야기 했듯이 41,800 시간이 소요됩니다. PSP의 경우는 이 유지.보수 시간이 0시간으로 됩니다.

※실제 시스템 시험까지 모든 결함이나 설계 문제가 나타나지 않는다는 결론 같은데 쉽게 납득은 되지 않습니다. 하지만 PSP를 정말 제대로 수행했다면 그 많은 설계 검토 과정과 리뷰, Pseudo 코드 작성과 그 것을 코드로 작성하고 작성 중에도 리뷰를 하는 과정을 생각해보면 전혀 틀린 말도 아닌 것 같습니다.

그리고 10,000 SLOC의 일반적인 (without PSP) 코드 작성 시간은 5,088 시간이며 PSP로 코드 작성을 한 시간은 242시간이 됩니다. 즉, 4,846시간을 추가로 절감할 수 있습니다.

※ 이 또한 실제 코딩을 하는 시간은 PSP가 훨씬 적습니다. 그 이 전 단계가 많은 시간을 요하지...

유지.보수 시간을 41,800 시간 줄였고 코드 작성 시간도 4,846시간 줄여서 46,646시간을 줄였습니다.

이 것을 시간당 $100의 인건비를 생각하면 전체 절감 비용 (benefit)은 $4,664,600이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $4,664,600 / $145,600 = 32.03 이어서 32:1이 됩니다.

※ Inspection은 $2,999,400 / $82,073 = 36.54이었습니다. 즉 이익은 적었지만 교육 비용과 수행 비용이 적었습니다.

6. ROI%

이익 - 총 비용 / 총 비용 × 100 은 ($4,664,600 - $145,600) / $145,600 × 100 = 3,103.708%로 3,104% 입니다.


3. TSP (Team Software Process)

tsp

※ TSP에 대한 위키 페이지는 여기입니다. TSP는 PSP의 개인 활동을 팀 활동으로 확대한 것으로 생각하시면 됩니다.

1. 교육 비용

PSP와 같이 SEI에서 교육을 받아야 하고 교육 비용 $4,000에 부대 비용 $2,700이 들며 일주일의 교육 기간이 필요합니다. 즉, 40시간이 소요되어 시간 당 인건비를 곱하면 $4,000의 인건비가 한 사람당 소요됩니다. TSP를 한 사람이 교육 받는데 드는 비용은 $10,700입니다.

그런데 위에서도 설명 했듯이 TSP는 PSP를 팀 활동으로 확대한 것이기 때문에 PSP도 교육받아야 합니다. 그래서 PSP의 한 사람당 교육에 소요되는 $26,400을 더하면 한 사람이 TSP를 수행하기 위해 교육 받는 비용은 $37,100이며 이 것을 네 사람에게 교육해야 하기 때문에 총 비용은 $148,400이라는 천문학적인 비용이 소요됩니다.

※즉, TSP도 효과는 좋으나 교육 비용이 높아서 PSP나 Inspection에 비해 ROI가 낮습니다.

2. TSP 수행 비용

TSP로 10,000 SLOC 소프트웨어를 개발할 경우 한 시간당 작성될 수 있는 코드는 6.12 SLOC (PSP에 비해서 좀 더 해 야할 일이 많습니다) 이어서 1,634시간의 시간이 필요합니다. 그래서 총 수행 비용은 $163,400이 됩니다. [4]

3. 총 비용 (Total Cost)

총 비용은 교육 비용과 수행 비용을 합한 $148,400 + $163,400 = $311,800입니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

PSP와 같이 10,000 SLOC의 소프트웨어 개발에 대한 코드 작성 후 유지.보수 시간인 41,800을 모두 줄일 수 있고, 10,000 SLOC의 소프트웨어 코딩을 위한 5,088 시간도 1,634시간 만 들기 때문에 추가 적으로 3,454시간을 절감 할 수 있습니다.

전체 절감한 시간은 41,800 + 3,454 = 45,245시간이 되어 총 절감 비용은 $4,525,400이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $4,525,400 / $311,800 = 14.51 이어서 14:1이 됩니다.

※ 이 부분은 논문 저자가 잘못 한 것 같습니다. 다른 부분은 모두 올림을 했는데 여기서는 소수점 이하를 버림으로 처리해서 14가 되었습니다. -_-;; 거장에게 메일을 한 번 보내볼까 생각 중입니다.

6. ROI%

이익 - 총 비용 / 총 비용 × 100 은 ($4,525,400- $311,800) / $311,800 × 100 = 1,351.37%로 1,351% 입니다.

 

4. SW-CMM (Capability Maturity Model)

※ CMM으로도 알려져 있는 SW-CMM은 CMMI (Capability Maturity Model Integration)으로 대처되었습니다. 마찬가지로 Carnegie Mellon 대에서 만들어진 것으로 조직의 프로세스를 성숙 단계로 두고 평가하는 모델로 잘 알려져 있습니다.

이후에 나올 SW-CMM, ISO09001, CMMI들은 앞에서 적용한 Integration, PSP, TSP와는 다르게 프로젝트를 수행하는 조직에 해당 모델을 적용하고 심사를 하는 비용을 투자 비용으로 보고 있습니다.

SW-CMM의 경우는 레벨 3까지 조직의 성숙도를 올린 후에 평가를 한 비용은 투자 비용으로 계산하고 있습니다.

1. 레벨 2 적용 비용 (Deployment Cost (Level 2)

SW-CMM을 4개의 프로젝트를 수행하는 소프트웨어 조직에 적용하는 비용은 다음과 같이 측정했습니다.

※즉, 10,000 SLOC의 소프트웨어를 5명이 개발하는 과제가 4개 있는 조직에 대해서 적용하고 있습니다.

6개의 정책에 대해 66시간, 24개의 절차 (procedure)에 대해 512시간, 34개의 문서에 대해 264시간, 76개의 work authorization에 대해 304시간, 116개의 기록 (records)에 대해 464시간, 136개의 보고서에 대해 544시간, 76개의 회의록에 대해 304시간이 소요되어 총 2,458시간이 소요되었고 시간당 인건비 $100을 고려하면 비용은 $245,800입니다 [5].

2. 레벨 3 적용 비용 (Deployment Cost (Level 3)

레벨 2로 조직의 성숙도를 올린 후 그 조직을 레벨 3으로 올리기 위한 비용은 다음과 같습니다.

7개의 정책 (policies)에 대해 77시간, 14개의 절차 (procedures)에 대해 154시간, 80개의 문서에 대해 1,280시간, 44개의 work authorization에 대해 176시간, 148개의 기록에 대해 592시간, 84개의 보고서에 대해 336시간, 48개의 회의록에 대해 192시간이 들어 총 소요 시간은 2,807시간이고 시간당 인건비 $100을 곱하면 비용은 $280,700입니다.

3. 평가 준비 비용 (Assessment Preparation Costs)

우리의 실험 조직에 대해 SW-CMMI를 평가하기 위한 준비 비용은 다음과 같습니다.

13개의 Indoctrination (평가를 위해 사전 교육 과정 정도로 볼 수 있겠습니다) 마다 2시간이 소요되고 이 것을 4개의 과제에 대해서 5명에게 수행해야 하기 때문에 13 × 2 × 4×5가 되어 520시간이 필요하고, response conditioning 코드 (이 것도 마찬가지로 평가를 위한 사전 과정)가 13개가 있고 각 2시간이 소요되어 4개의 과제를 위해 5명에게 필요한 시간은 520시간입니다. 그리고 4개 과제 5명에게 각각 40시간이 드는 예행 심사를 수행해야 하기 때문에 4×5×40의 800시간이 추가로 소요됩니다 [5].

전체 준비 비용은 13개의 Indoctrination 코스와 13개의 response conditioning 과정, 예행 심사의 시간을 더하면 총 1,840시간이 들어서 총 비용은 $184,000이 듭니다.

4. SW-CMM을 적용하기 위한 비용

SW-CMM의 레벨2와 레벨3을 적용한 비용과 평가 준비 비용을 모두 더 하면 $245,800 + $280,700 + $184,000이 되어 $710,500이 소요되었습니다.

5. SW-CMM으로 심사 (assessment)한 비용

이 비용은 Inspection이나 PSP, TSP에서는 각 방법을 적용한 비용과 유사할 것입니다.

SW-CMM으로 조직의 성숙도를 심사하는데 드는 비용은 다음과 같습니다.

3,208시간의 내부 준비 시간이 필요하고

4개 과제의 5명에게 62시간의 계획시간과 234시간의 준비, 646시간의 자체 평가와 57시간의 follow-up 시간을 모두 더하면 1,000시간 (※ 우리의 저자가 또 1을 빼 먹었거나 소수점 자리 계산으로 1,000이 된 것 같습니다. )이 필요하고 이 것의 비용은 시간당 인건비 $100을 고려하면 $100,000이 필요합니다. 여기에 심사 비용 $40,000을 더하면 총 심사 비용은 $140,000입니다.

※ SW-CMM은 자체적으로 심사하는 것이 아니고 외부 심사위원에게 심사를 받는 것입니다.

6. SW-CMM의 총 비용

SW-CMM을 위해 투자한 비용은 SW-CMM 레벨2와 3을 적용한 비용과 평가 준비 비용 심사 비용을 모두 합해서 $710,500 + $140,000이 되어 $850,500이 됩니다.

7. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

SW-CMM 3레벨을 적용한 10,000 SLOC 과제 4개에 대한 이득은 다음과 같습니다.

Inspection으로 27,867의 유지.보수 시간이 줄어들어 4개의 과제에 대해 전체 111,466시간이 절감되었고, SW-CMM 레벨 3를 적용하면 코드 생산성이 2배 증가한다는 Diaz의 보고[6]에 따라 한 과제당 2,544시간의 시간이 절감되어 4과제에 대해서 10,176시간이 줄어들었습니다.

총 절감한 시간은 111,466 + 10,176가 되어 121,642시간이고 비용은 $12,164,200이 됩니다.

8. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $12,164,200 / $850,500 = 14.30 이어서 14:1이 됩니다.

역시 효과는 높지만 그 만큼 투자 비용이 높아서 TSP와 같은 B/CR을 보입니다.

9. ROI%

이익 - 총 비용 / 총 비용 × 100 은 ($12,164,200 - $850,500) / $850,500 × 100 = 1,330%입니다.


5. ISO9001

ISO9001은 품질 관리에 대한 표준으로 다음 사항 등을 포함하고 있습니다.

  • 주요 프로세스에 대한 절차
  • 각 효과를 확인하고 모니터링 하는 것
  • 기록
  • 결함 확인과 수정
  • 리뷰활동

1. 적용 비용

El Emam의 비용 모델[7]에 따라 20명인 조직에 ISO9001모델을 적용하는데 드는 비용은 다음과 같습니다.

※SW-CMM부터는 5명이 한 조가 되어 4개의 프로젝트를 하는 조직에 대한 적용 사례이기 때문에 조직의 구성원이 20명입니다.

ISO9001 등록 준비를 위해 2,184의 준비 시간이 필요해서 시간당 인건비 $100을 곱하면 $218,396의 비용이 필요합니다 (분까지 포함해서)

2. 심사 비용

심사 준비를 하는데 각 구성원이 32시간이 필요해서 20명의 조직원을 곱하면 640시간의 준비 기간이 필요해서 준비 비용은 $64,000입니다. 그리고 여기에 심사 비용인 $48,000을 더하면 총 심사 비용은 $112,000입니다.

3. ISO9001의 전체 투자 비용

ISO9001의 적용 비용과 심사 비용을 합치면 $218,396+$112,000이 되어 $330,396의 비용이 듭니다.

4. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

ISO9001을 적용하면 15%의 유지.보수 비용 절감 효과가 있다고 하기 때문에,

앞에서 거론했듯이 10,000SLOC과제의 유지.보수 비용이 41,800시간이므로 15%는 6,270시간의 절감이 있고 이 것은 4개의 과제마다 효과가 나타나므로 6,270×4가 되어 25,080시간의 유지.보수 시간 절감 효과가 발생합니다.

또한, ISO9001을 적용하면 13%의 생산성이 증가한다고 합니다. 따라서 SLOC가 10,000이 소프트웨어의 코드 작성 시간이 5,088시간의 13%는 661시간이며 이 것이 4개의 과제에 나타나므로 총 코드 작성 시간의 절감은 2,646시간입니다.

전체 절감 시간은 유지.보수 시간 절감과 코드 작성 시간 절감을 더해서 25,080 + 2,646이 되어 27,726시간이며 시간당 인건비 $100을 곱하면 이득은 $2,772,600이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $2,772,600 / $330,396 = 8.39 이어서 8:1이 됩니다.

비용은 SW-CMM보다 낮지만 이익도 낮습니다.

6. ROI%

이익 - 총 비용 / 총 비용 × 100 은 ($2,772,600 - $330,396) / $330,396 × 100 = 739%입니다.


6. CMMI (Capability Maturity Model Integration)

cmmi

SW-CMMI에서도 설명 드렸지만 SW-CMMI등을 통합한 조직 성숙도 모델로 카네기 멜론 (Carnegie Mellon)에서 만들어졌습니다.

※ CMMI는 4개의 프로젝트를 수행중인 조직에 대해서 적용한 것이고 각 프로젝트는 10명의 구성원이 있습니다. 즉 조직은 40명의 조직입니다.

1. CMMI 정책과 절차에 대한 비용 (CMMI Policies and Procedures)

CMMI의 정책과 절차들을 4개의 프로젝트에 적용하기 위한 비용은 다음과 같습니다.

레벨2를 위해 56개의 정책과 절차를 만드는데 필요한 시간은 2,091시간이고 레벨3를 위한 101개의 정책과 절차를 만드는 시간은 3,771시간이 필요해서 CMMI 레벨이 없는 조직을 CMMI 레벨3까지 끌어올리는 총 시간은 5,862시간이고 비용은 $100을 곱해서 $586,200입니다. 이 것은 전체 소프트웨어를 만드는데 필요한 시간으로 코드 작성까지를 전체 프로세스의 반으로 생각할 때 비용은 $293,100입니다.

2. CMMI를 수행했다는 산출물 작성 비용 (CMMI Evidence of Use)

CMMI를 레벨에 맞게 제대로 수행했다는 증거를 위한 산출물 작성 비용은 다음과 같습니다.

(이 것은 참고 문헌의 Rico[8]을 보십시오)

CMMI 레벨2는 138개의 산출물을 작성하기 위해서 10,304시간이 필요하고 레벨3의 275개의 산출물을 작성하기 위해서 20,533시간이 필요합니다. 총 산출물 작성 시간은 30,837시간이 마찬가지로 시간당 인건비 $100을 곱하면 총 비용은 $308,370입니다. 이 것도 코드 작성까지를 전체 프로세스의 반으로 본다면 비용은 $1,541,850이 됩니다.

3. CMMI 적용 비용 (CMMI Implementation Costs)

CMMI 정책과 절차를 적용하기 위한 비용과 산출물 작성 비용을 합하면 $293,100 + $1,541,850이 되어 총 $1,834,950이 됩니다.

4. CMMI 심사 준비 비용 (Assessment Preparation Costs)

심사를 준비하기 위해 20개의 Indoctrination (평가를 위해 사전 교육 과정 정도로 볼 수 있겠습니다)이 각 2시간씩 필요하고 이 것을 조직 구성원 40명에게 수행해야 하기 때문에 20×2×40이어서 1,600시간이 필요합니다.

그리고 각 2시간씩 필요한 20개의 response conditioning 코스도 40명에게 수행해야 하기 때문에 20×2×40이어서 1,600시간이 또 필요합니다.

또한 예비 심사 (mock assessment)를 각 구성원이 40시간씩 수행해야 하기 때문에 추가로 1,600시간이 더 필요합니다.

총 심사 준비 비용은 Indoctrination과 response conditioning 코스 그리고 예비 심사를 더하면 4,800시간이 되어 $480,000이 됩니다.

이 또한 전체 프로세스에 드는 비용이어서 코드 작성까지를 전체 프로세스의 반으로 본다면 $240,000이 됩니다.

5. CMMI의 적용과 심사 준비를 위한 총 비용

CMMI 정책과 절차를 적용하고 필요한 산출물을 만들고 심사를 준비하기 위한 비용은 $293,100 + $1,541,850 + $240,000이 되어서 $2,074,950이 됩니다.

6. 심사 비용 (Assessment Cost)

※David F. Rico가 잘 못 쓴 것 같은데 CMMI 적용 부분에서는 4개의 프로젝트를 각 10명 수행하는 것으로 CMMI 적용과 심사 준비 비용을 산출하다가 여기서 잠시 4개의 프로젝트를 5명이 수행하는 것으로 계산을 하고 있습니다. 이 부분도 메일을 보내볼까 생각 중입니다.

CMMI 심사 비용은 다음과 같이 산출됩니다.

CMMI 심사를 위해 계획을 하고 평가 단계 (appraisal stage)준비를 위해 636시간이 소요되며 평가 단계 (appraisal stage)를 수행하기 위해 1,018시간이 필요합니다. 그리고 보고 단계 (report stage)를 위해 106시간이 들어서 총 1,760시간이 예상되어 시간당 인건비 $100을 곱하면 $176,000이 필요합니다.

여기에 심사 비용 $64,615가 추가되면 총 심사 비용은 $240,615가 됩니다.

7. CMMI를 위한 총 투자 비용

CMMI 적용과 심사 준비 비용에 심사 비용을 더하면 $2,074,950 + $240,615가 되어 $2,315,565가 총 투자 비용이 됩니다.

8. 전체 개발 기간 동안의 이득 (Total Life Cycle Benefits)

CMMI 레벨3인 조직의 Inspection을 통한 코드 작성 이후 유지.보수 시간의 절감은 SLOC 10,000 소프트웨어에 대해 27,867시간입니다. 4개의 프로젝트이므로 4×27,867이 되어 총 111,466 (※ 곱하기가 좀 이상하지만) 시간이 유지.보수 시간에서 절감됩니다.

또한 CMMI 레벨3인 조직은 그렇지 못한 조직에 비해 SLOC 10,000 소프트웨어에 대해 2,544 시간을 코드 작성에서 줄일 수 있습니다. 이 것을 4개의 프로젝트로 확산하면 10,176시간이 코드 작성 시간에서 절감됩니다.

유지.보수 시간의 절감된 시간과 코드 작성의 절감된 시간을 더하면 111,466 + 10,176이 되어 121,642시간이 총 절감되어 비용은 $12,164,200이 됩니다.

5. B/CR (Benefit/Cost Ratio)

이익 / 총 비용은 $12,164,200 / $2,315,565 = 5.25이어서 5:1이 됩니다.

6. ROI%

이익 - 총 비용 / 총 비용 × 100 은 ($12,164,200 - $2,315,565) / $2,315,565 × 100 = 425%입니다.


각 방법론 비교 표

위에서 Inspection, PSP, TSP, SW-CMM, ISO9001, CMMI의 투자 비용과


  교육 수행 총 비용 이득 B/CR ROI%
Inspection 11,240 70,833 82,073 2,999,400 37:1 3,555
PSP 105,600 40,000 145,600 4,664,600 32:1 3,104
TSP 148,400 163,400 311,800 4,525,400 14:1 1,351
  적용 심사        
SW-CMM 710,500 140,000 850,500 12,164,200 14:1 1,330
ISO9001 218,396 112,000 330,396 2,772,600 8:1 739
CMMI 2,074,950 240,615 2,315,565 12,164,200 5:1 425

어느 정도 예상했던 결과가 나옵니다.

  • Inspection이 이득은 가장 낮지만 투자 비용이 훨씬 낮아 ROI가 가장 높습니다.
  • CMMI가 Inspection에 비해 4배 가까이 이득이 높지만 총 비용이 30배 이상 들어서 가장 ROI가 낮습니다.

생각해보기

1. 그들을 먼가 정직하게 하고 있다.

Inspection이 적은 투자 비용으로 큰 효과를 볼 수 있어 ROI가 가장 높다는 자명한 결론 이전에 생각해볼 것은 "그들은 정말 제대로 한다" 입니다.

10,000 SLOC의 소프트웨어를 한 번 인스펙션 할 때 보는 코드 라인수가 240줄입니다. 그래서 41.67번의 미팅이 필요했다고 합니다. 그러면 240줄을 한 시간 동안 준비하고 인스펙션하고 수정할까요? 아닙니다. 한 번의 인스펙션을 위해 소요되는 시간을 17시간으로 잡고 있습니다.

당신의 상사가 그리고 동료 또 부하직원이 240줄을 인스펙션 하기 위해 17시간을 소요하고 있다는 것이 상상이 될까요?

논문이니깐... 이라고 생각될 수 있지만 저자와 제출처 등 논문의 명성을 보면 꼭 그렇게 생각할 수도 없습니다.

2. Measurement의 중요성

측정 (Measurement)을 제대로 해야 평가 (Assessment)도 제대로 하고 예측 (Estimation)도 할 것입니다. "정말 이런 내용들을 다 측정했을까"라는 생각이 될 정도로 많은 항목들을 일관성과 목적을 가지고 제대로 측정한 것 같습니다. 그래서 유명한 논문이 나왔겠죠.

※ 논문의 본 주제로 잠시 돌아가겠습니다.

3. 낮은 비용과 리스크가 적은 것을 선택

인스펙션이나 PSP가 좋은 예가 될 것입니다. 효과 (returns) 극대화를 생각하기 이전에 실패할 수도 있다는 위험 (risk)를 고려한다면 낮은 비용으로 투자를 하는 것이 안전할 것입니다. 모든 방법이 모든 과제와 상황에 성공한다는 보장은 없을 것입니다.

CMMI를 주창해서 도입하고 2백만 달러가 넘는 돈을 투자하고 실패한다면? 상상하고 싶지 않을 것입니다.

4. 비용 집약적인 것을 피하라

이 논문은 인스펙션을 광고하기 위한 논문은 아니지만 낮은 비용으로도 높은 이득 (returns)을 볼 수 있다는 것을 보여줌으로써 비용에 허덕이는 조직에게 단비와 같은 근거를 마련해줍니다.


References

논문에서 사용한 참고 문헌들 입니다.

[1] Rico, D. F. (2002). Software process improvement: Modeling return on investment (ROI). 2002 Software Engineering Process Group Conference (SEPG 2002), Phoenix, Arizona and 2002 International Conference on Software Process Improvement (ICSPI 2002), Washington D.C. http://davidfrico.com/sepg02.pdf http://davidfrico.com/dacs02.pdf

[2] Rachlin, R. (1997). Return on investment manual: Tools and applications for managing financial results. Armonk, NY: M. E. Sharpe.

[3] Rico, D. F. (2000). Using cost benefit analyses to develop software process improvement (SPI) strategies (Contract Number SP0700-98-D-4000). Rome, NY: Air Force Research Laboratory—Information Directorate (AFRL/ IF), Data and Analysis Center for Software (DACS). http://www.dacs.dtic.mil/techs/abstracts/rico.html

[4] Humphrey, W.S. (2000). The team software processsm (TSPsm). (CMU/SEI-2000-TR-023). Pittsburgh, PA: Software Engineering Institute.

[5] Rico, D. F. (n.d./2001). SEI level 2 thru 5: Cost model [WWW document]. URL http://davidfrico.com/sw-cmm-costpdf.htm

[6] Diaz, M., & Sligo, J. (1997). How software process improvement helped motorola. IEEE Software, 14( 5), 75-81.

[7] El Emam, K., & Briand, L. C. (1997). Costs and benefits of software process improvcment (IESE-Report 047.97/E). Kaiserslautern, Germany: University of Kaiserslautern, Fraunhofer-Institute for Experimental Software Engineering.

[8] Rico, D. F. (n.d./2001). Capability maturity model integration: CMMI introductory overview [WWW document]. URL http://davidfrico.com/cmmipdf.htm

[9] Carnegie Mellon University (2001). Standard CMMISM appraisal method for process improvement (SCAMPISM), Version 1.1: Method definition document CMU/SEI-2001-HB-001. Pittsburgh, PA: Software Engineering Institute (SEI).


반응형
원문:  http://www.ibm.com/developerworks/kr/library/tutorial/j-cq11207/index.html

워낙에 흥미로운 주제를 다루고 있다. 많은 개발자들에게 아직은 생소할 Continuous Integration을 다룬 글이다.

여러가지 개발 도구들을 써보는 것을 좋아 하다 보니 여기저기 돌아다니다가 괜찮거나 필요하다 생각되는 것들을

설치해서 사용해 보는 편이다. 그러다가 편하고 괜찮은 유틸이 있으면 다른 분들에게도 제안하여 같이 사용하기도 한다.

특히 자바쪽이 주력이라 이클립스 플러그인쪽을 많이 활용하는데 그와 연관된 것들도 연동하여 사용한다.

버전관리는 CVS를 통해 하고 있고 빌드는 ANT 그리고 프로파일링툴은 TPTP , 최근에 맘에 드는것을 찾았는데

Static Analysis tool 인 Findbugs,PMD 등이 있다.

요즘 관심을 갖는 것은 이슈 트래커나 CI(Continuous Integration) 도구들인데 위의 글을 읽어보니 꽤 맘에 들었다.

CI에 대해 좀더 알아보고 개인적으로 적용해 봐야겠다.

<원문중>
지속적 통합(Continuous Integration, 이하 CI)이란 지속적으로 소스코드를 컴파일, 테스트, 검사, 배치하는 처리과정을 말합니다. 많은 CI 환경에서 이는 소스코드 관리 저장소에 변경 사항이 생기면 빌드가 새로 실행됨을 의미합니다. CI의 장점은 간단합니다. 비교적 관리하기 쉬울 때 소프트웨어를 어셈블해 보면 결함을 조기해 발견할 가능성이 매우 높아집니다. 본 튜토리얼은 Andrew Glover의 In pursuit of code quality 연재와 더불어 CI의 기초를 소개하고 최신 오픈 소스 기술을 사용하여 CI 처리과정을 설정하는 방법을 단계별로 설명합니다.

 CI 서버를 제대로 설정하여 SCM 저장소에 연결하고 소스코드에서 변화가 감지될 때 앤트 빌드 프로세스를 실행하는 방법에 대해서도 다룰 것이다. 또한 자동화된 JUnit 테스트를 실행하는 방법과 PMD와 FindBugs 모두에서 소프트웨어 검사(inspection)를 실시하는 방법을 다룰 것이다. 마지막으로 최신 CI 서버라는 허드슨(Hudson)이 문제를 발견했을 때 어떻게 알려주는지, 안정적인 소프트웨어를 신속하게 만드는 방법은 무엇인지도 다룰 것이다.

목표

이 튜토리얼은 프레임워크에 따라 허드슨, 앤트, 서브버전(Subversion)을 사용한 CI의 기본 개념을 단계별로 안내한다. 한 시간짜리 본 튜토리얼을 마치고 나면 CI의 장점을 알게되고 협업에 필요한 허드슨, 앤트, 서브버전을 설정 및 구성 방법을 이해할 수 있을 것이다. 빌드 프로세스의 결과물은 테스트와 소프트웨어 검사에서 모두 작동하고 문제 발생시 즉각 보고를 할 것이다.


이 연재에 대하여
우리는 개발자로서 사용자들의 일을 자동화하기 위해 노력한다. 하지만 대다수의 개발자가 자신의 개발 공정을 자동화하는 것은 간과해 버린다. 그런 일이 더이상 발생하지 않도록, " 사람을 위한 자동화 " 연재를 통해 소프트웨어 개발 공정을 자동하는 실용적인 방법과 언제 어떻게 자동화를 성공적으로 적용할 수 있는지에 대해 살펴볼 것이다.


반응형

Phoenix/Tools

From OWASP

Jump to: navigation, search

Please send comments or questions to the Phoenix-OWASP mailing-list.

LiveCDs
Monday, January 29, 2007 4:02 PM 828569600 AOC_Labrat-ALPHA-0010.iso - http://www.packetfocus.com/hackos/
DVL (Damn Vulnerable Linux) - http://www.damnvulnerablelinux.org/

Test sites / testing grounds
SPI Dynamics (live) - http://zero.webappsecurity.com/
Cenzic (live) - http://crackme.cenzic.com/
Watchfire (live) - http://demo.testfire.net/
Acunetix (live) - http://testphp.acunetix.com/ http://testasp.acunetix.com http://testaspnet.acunetix.com
WebMaven / Buggy Bank (includes live testsite) - http://www.mavensecurity.com/webmaven
Foundstone SASS tools - http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/s3i_tools.htm
OWASP WebGoat - http://www.owasp.org/index.php/OWASP_WebGoat_Project
OWASP SiteGenerator - http://www.owasp.org/index.php/Owasp_SiteGenerator
Stanford SecuriBench - http://suif.stanford.edu/~livshits/securibench/
SecuriBench Micro - http://suif.stanford.edu/~livshits/work/securibench-micro/

HTTP proxying / editing
WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Burp - http://www.portswigger.net/
Paros - http://www.parosproxy.org/
Fiddler - http://www.fiddlertool.com/
Web Proxy Editor - http://www.microsoft.com/mspress/companion/0-7356-2187-X/
Pantera - http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project
Suru - http://www.sensepost.com/research/suru/
httpedit (curses-based) - http://www.neutralbit.com/en/rd/httpedit/
Charles - http://www.xk72.com/charles/
Odysseus - http://www.bindshell.net/tools/odysseus
Burp, Paros, and WebScarab for Mac OS X - http://www.corsaire.com/downloads/
Web-application scanning tool from `Network Security Tools'/O'Reilly - http://examples.oreilly.com/networkst/

RSnake's XSS cheat sheet based-tools, webapp fuzzing, and encoding tools
Wfuzz - http://www.edge-security.com/wfuzz.php
ProxMon - http://www.isecpartners.com/proxmon.html
Wapiti - http://wapiti.sourceforge.net/
Grabber - http://rgaucher.info/beta/grabber/
XSSScan - http://darkcode.ath.cx/scanners/XSSscan.py
CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
HTMangLe - http://www.fishnetsecurity.com/Tools/HTMangLe/publish.htm
JBroFuzz - http://sourceforge.net/projects/jbrofuzz
XSSFuzz - http://ha.ckers.org/blog/20060921/xssfuzz-released/
WhiteAcid's XSS Assistant - http://www.whiteacid.org/greasemonkey/
Overlong UTF - http://www.microsoft.com/mspress/companion/0-7356-2187-X/
[TGZ] MielieTool (SensePost Research) - http://packetstormsecurity.org/UNIX/utilities/mielietools-v1.0.tgz
RegFuzzer: test your regular expression! filter - http://rgaucher.info/b/index.php/post/2007/05/26/RegFuzzer%3A-Test-your-regular-expression!-filter
screamingCobra - http://www.dachb0den.com/projects/screamingcobra.html
SPIKE and SPIKE Proxy - http://immunitysec.com/resources-freesoftware.shtml
RFuzz - http://rfuzz.rubyforge.org/
WebFuzz - http://www.codebreakers-journal.com/index.php?option=com_content&task=view&id=112&Itemid=99999999
TestMaker - http://www.pushtotest.com/Docs/downloads/features.html
ASP Auditor - http://michaeldaw.org/projects/asp-auditor-v2/
WSTool - http://wstool.sourceforge.net/
Web Hack Control Center (WHCC) - http://ussysadmin.com/whcc/
Web Text Converter - http://www.microsoft.com/mspress/companion/0-7356-2187-X/
HackBar (Firefox Add-on) - https://addons.mozilla.org/firefox/3899/
Net-Force Tools (NF-Tools, Firefox Add-on) - http://www.net-force.nl/library/downloads/
PostIntercepter (Greasemonkey script) - http://userscripts.org/scripts/show/743

HTTP general testing / fingerprinting
Wbox: HTTP testing tool - http://hping.org/wbox/
ht://Check - http://htcheck.sourceforge.net/
Mumsie - http://www.lurhq.com/tools/mumsie.html
WebInject - http://www.webinject.org/
Torture.pl Home Page - http://stein.cshl.org/~lstein/torture/
JoeDog's Seige - http://www.joedog.org/JoeDog/Siege/
OPEN-LABS: metoscan (http method testing) - http://www.open-labs.org/
Load-balancing detector - http://ge.mine.nu/lbd.html
HMAP - http://ujeni.murkyroc.com/hmap/
Net-Square: httprint - http://net-square.com/httprint/
Wpoison: http stress testing - http://wpoison.sourceforge.net/
Net-square: MSNPawn - http://net-square.com/msnpawn/index.shtml
hcraft: HTTP Vuln Request Crafter - http://druid.caughq.org/projects/hcraft/
rfp.labs: LibWhisker - http://www.wiretrip.net/rfp/lw.asp
Nikto - http://www.cirt.net/code/nikto.shtml
twill - http://twill.idyll.org/
DirBuster - http://www.sittinglittleduck.com/DirBuster/
[ZIP] DFF Scanner - http://security-net.biz/files/dff/DFF.zip
[ZIP] The Elza project - http://packetstormsecurity.org/web/elza-1.4.7-beta.zip http://www.stoev.org/elza.html

Browser-based HTTP tampering / editing / replaying
TamperIE - http://www.bayden.com/Other/
isr-form - http://www.infobyte.com.ar/developments.html
Modify Headers (Firefox Add-on) - http://modifyheaders.mozdev.org/
Tamper Data (Firefox Add-on) - http://tamperdata.mozdev.org/
UrlParams (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1290/
TestGen4Web (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1385/
DOM Inspector / Inspect This (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1806/ https://addons.mozilla.org/en-US/firefox/addon/1913/
LiveHTTPHeaders / Header Monitor (Firefox Add-on) - http://livehttpheaders.mozdev.org/ https://addons.mozilla.org/en-US/firefox/addon/575/

Cookie editing / poisoning
[TGZ] stompy: session id tool - http://lcamtuf.coredump.cx/stompy.tgz
Add'N Edit Cookies (AnEC, Firefox Add-on) - http://addneditcookies.mozdev.org/
CookieCuller (Firefox Add-on) - http://cookieculler.mozdev.org/
CookiePie (Firefox Add-on) - http://www.nektra.com/oss/firefox/extensions/cookiepie/
CookieSpy - http://www.codeproject.com/shell/cookiespy.asp
Cookies Explorer - http://www.dutchduck.com/Features/Cookies.aspx

Ajax and XHR scanning
Sahi - http://sahi.co.in/
scRUBYt - http://scrubyt.org/
jQuery - http://jquery.com/
jquery-include - http://www.gnucitizen.org/projects/jquery-include
Sprajax - http://www.denimgroup.com/sprajax.html
Watir - http://wtr.rubyforge.org/
Watij - http://watij.com/
Watin - http://watin.sourceforge.net/
RBNarcissus - http://idontsmoke.co.uk/2005/rbnarcissus/
SpiderTest (Spider Fuzz plugin) - http://blog.caboo.se/articles/2007/2/21/the-fabulous-spider-fuzz-plugin
xxJavascript Inline Debugger (jasildbg) - http://jasildbg.googlepages.com/
Firebug Lite - http://www.getfirebug.com/lite.html
firewaitr - http://code.google.com/p/firewatir/

RSS extensions and caching
LiveLines (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/324/
rss-cache - http://www.dubfire.net/chris/projects/rss-cache/

SQL injection scanning
0x90.org: home of Absinthe, Mezcal, etc - http://0x90.org/releases.php
SQLiX - http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project
sqlninja: a SQL Server injection and takover tool - http://sqlninja.sourceforge.net/
JustinClarke's SQL Brute - http://www.justinclarke.com/archives/2006/03/sqlbrute.html
BobCat - http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html
sqlmap - http://sqlmap.sourceforge.net/
Scully: SQL Server DB Front-End and Brute-Forcer - http://www.sensepost.com/research/scully/
FG-Injector - http://www.flowgate.net/?lang=en&seccion=herramientas
PRIAMOS - http://www.priamos-project.com/

Web application security malware, backdoors, and evil code
W3AF: Web Application Attack and Audit Framework - http://w3af.sourceforge.net/
Jikto - http://busin3ss.name/jikto-in-the-wild/
XSS Shell - http://ferruh.mavituna.com/article/?1338
XSS-Proxy - http://xss-proxy.sourceforge.net
AttackAPI - http://www.gnucitizen.org/projects/attackapi/
FFsniFF - http://azurit.elbiahosting.sk/ffsniff/
HoneyBlog's web-based junkyard - http://honeyblog.org/junkyard/web-based/
BeEF - http://www.bindshell.net/tools/beef/
Firefox Extension Scanner (FEX) - http://www.gnucitizen.org/projects/fex/
What is my IP address? - http://reglos.de/myaddress/
xRumer: blogspam automation tool - http://www.botmaster.net/movies/XFull.htm
SpyJax - http://www.merchantos.com/makebeta/tools/spyjax/
Greasecarnaval - http://www.gnucitizen.org/projects/greasecarnaval
Technika - http://www.gnucitizen.org/projects/technika/
Load-AttackAPI bookmarklet - http://www.gnucitizen.org/projects/load-attackapi-bookmarklet
MD's Projects: JS port scanner, pinger, backdoors, etc - http://michaeldaw.org/my-projects/

Web application services that aid in web application security assessment
Netcraft - http://www.netcraft.net
AboutURL - http://www.abouturl.com/
The Scrutinizer - http://www.scrutinizethis.com/
net.toolkit - http://clez.net/
ServerSniff - http://www.serversniff.net/
Online Microsoft script decoder - http://www.greymagic.com/security/tools/decoder/
Webmaster-Toolkit - http://www.webmaster-toolkit.com/
myIPNeighbbors, et al - http://digg.com/security/MyIPNeighbors_Find_Out_Who_Else_is_Hosted_on_Your_Site_s_IP_Address
PHP charset encoding - http://h4k.in/encoding
data: URL testcases - http://h4k.in/dataurl

Browser-based security fuzzing / checking
Zalewski's MangleMe - http://lcamtuf.coredump.cx/mangleme/mangle.cgi
hdm's tools: Hamachi, CSSDIE, DOM-Hanoi, AxMan - http://metasploit.com/users/hdm/tools/
Peach Fuzzer Framework - http://peachfuzz.sourceforge.net/
TagBruteForcer - http://research.eeye.com/html/tools/RT20060801-3.html
PROTOS Test-Suite: c05-http-reply - http://www.ee.oulu.fi/research/ouspg/protos/testing/c05/http-reply/index.html
COMRaider - http://labs.idefense.com
bcheck - http://bcheck.scanit.be/bcheck/
Stop-Phishing: Projects page - http://www.indiana.edu/~phishing/?projects
LinkScanner - http://linkscanner.explabs.com/linkscanner/default.asp
BrowserCheck - http://www.heise-security.co.uk/services/browsercheck/
Cross-browser Exploit Tests - http://www.jungsonnstudios.com/cool.php
Stealing information using DNS pinning demo - http://www.jumperz.net/index.php?i=2&a=1&b=7
xxJavascript Website Login Checker - http://ha.ckers.org/weird/xxjavascript-website-login-checker.html
Mozilla Activex - http://www.iol.ie/~locka/mozilla/mozilla.htm
Jungsonn's Black Dragon Project - http://blackdragon.jungsonnstudios.com/
Mr. T (Master Recon Tool, includes Read Firefox Settings PoC) - http://ha.ckers.org/mr-t/
Vulnerable Adobe Plugin Detection For UXSS PoC - http://www.0x000000.com/?i=324
About Flash: is your flash up-to-date? - http://www.macromedia.com/software/flash/about/
Test your installation of Java software - http://java.com/en/download/installed.jsp?detect=jre&try=1

PHP static analysis and file inclusion scanning
PHP-SAT.org: Static analysis for PHP - http://www.program-transformation.org/PHP/
Unl0ck Research Team: tool for searching in google for include bugs - http://unl0ck.net/tools.php
FIS: File Inclusion Scanner - http://www.segfault.gr/index.php?cat_id=3&cont_id=25
PHPSecAudit - http://developer.spikesource.com/projects/phpsecaudit

Web Application Firewall (WAF) and Intrusion Detection (APIDS) rules and resources
APIDS on Wikipedia - http://en.wikipedia.org/wiki/APIDS
PHP Intrusion Detection System (PHP-IDS) - http://php-ids.org/ http://code.google.com/p/phpids/
dotnetids - http://code.google.com/p/dotnetids/
Secure Science InterScout - http://www.securescience.com/home/newsandevents/news/interscout1.0.html
Remo: whitelist rule editor for mod_security - http://remo.netnea.com/
GotRoot: ModSecuirty rules - http://www.gotroot.com/tiki-index.php?page=mod_security+rules
The Web Security Gateway (WSGW) - http://wsgw.sourceforge.net/
mod_security rules generator - http://noeljackson.com/tools/modsecurity/
Mod_Anti_Tamper - http://www.wisec.it/projects.php?id=3
[TGZ] Automatic Rules Generation for Mod_Security - http://www.wisec.it/rdr.php?fn=/Projects/Rule-o-matic.tgz
AQTRONIX WebKnight - http://www.aqtronix.com/?PageID=99
Akismet: blog spam defense - http://akismet.com/
Samoa: Formal tools for securing web services - http://research.microsoft.com/projects/samoa/

Web services enumeration / scanning / fuzzing
WebServiceStudio2.0 - http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=65a1d4ea-0f7a-41bd-8494-e916ebc4159c
Net-square: wsChess - http://net-square.com/wschess/index.shtml
WSFuzzer - http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project
SIFT: web method search tool - http://www.sift.com.au/73/171/sift-web-method-search-tool.htm
iSecPartners: WSMap, WSBang, etc - http://www.isecpartners.com/tools.html

Web application non-specific static source-code analysis
Pixy: a static analysis tool for detecting XSS vulnerabilities - http://www.seclab.tuwien.ac.at/projects/pixy/
Brixoft.Net: Source Edit - http://www.brixoft.net/prodinfo.asp?id=1
Security compass web application auditing tools (SWAAT) - http://www.owasp.org/index.php/Category:OWASP_SWAAT_Project
An even more complete list here - http://www.cs.cmu.edu/~aldrich/courses/654/tools/
A nice list that claims some demos available - http://www.cs.cmu.edu/~aldrich/courses/413/tools.html
A smaller, but also good list - http://spinroot.com/static/

Static analysis for C/C++ (CGI, ISAPI, etc) in web applications
RATS - http://www.securesoftware.com/resources/download_rats.html
ITS4 - http://www.cigital.com/its4/
FlawFinder - http://www.dwheeler.com/flawfinder/
Splint - http://www.splint.org/
Uno - http://spinroot.com/uno/
BOON (Buffer Overrun detectiON) - http://www.cs.berkeley.edu/~daw/boon/ http://boon.sourceforge.net
Valgrind - http://www.valgrind.org/

Java static analysis, security frameworks, and web application security tools
HDIV Struts - http://hdiv.org/
Orizon - http://sourceforge.net/projects/orizon/
FindBugs: Find bugs in Java programs - http://findbugs.sourceforge.net/
PMD - http://pmd.sourceforge.net/
CUTE: A Concolic Unit Testing Engine for C and Java - http://osl.cs.uiuc.edu/~ksen/cute/
EMMA - http://emma.sourceforge.net/
JLint - http://jlint.sourceforge.net/
Java PathFinder - http://javapathfinder.sourceforge.net/
Fujaba: Move between UML and Java source code - http://wwwcs.uni-paderborn.de/cs/fujaba/
Checkstyle - http://checkstyle.sourceforge.net/
Cookie Revolver Security Framework - http://sourceforge.net/projects/cookie-revolver
tinapoc - http://sourceforge.net/projects/tinapoc
jarsigner - http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html
Solex - http://solex.sourceforge.net/
Java Explorer - http://metal.hurlant.com/jexplore/
HTTPClient - http://www.innovation.ch/java/HTTPClient/
another HttpClient - http://jakarta.apache.org/commons/httpclient/
a list of code coverage and analysis tools for Java - http://mythinkpond.blogspot.com/2007/06/java-foss-freeopen-source-software.html

Microsoft .NET static analysis and security framework tools, mostly for ASP.NET and ASP.NET AJAX, but also C# and VB.NET
Orcas - http://msdn.microsoft.com/vstudio/express/future/downloads/default.aspx
Web Development Helper - http://www.nikhilk.net/Project.WebDevHelper.aspx
FxCop - http://blogs.msdn.com/fxcop/ http://www.gotdotnet.com/team/fxcop/
Microsoft Application Verifier - http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/appverifier.mspx
Microsoft internal tools you can't have yet - http://www.microsoft.com/windows/cse/pa_projects.mspx http://research.microsoft.com/Pex/ http://www.owasp.org/images/5/5b/OWASP_IL_7_FuzzGuru.pdf

Threat modeling
Microsoft Threat Analysis and Modeling Tool v2.1 (TAM) - http://www.microsoft.com/downloads/details.aspx?FamilyID=59888078-9daf-4e96-b7d1-944703479451&displaylang=en
Amenaza: Attack Tree Modeling (SecurITree) - http://www.amenaza.com/software.php
Octotrike - http://www.octotrike.org/

Add-ons for Firefox that help with general web application security
Web Developer Toolbar - https://addons.mozilla.org/firefox/60/
Plain Old Webserver (POW) - https://addons.mozilla.org/firefox/3002/
XML Developer Toolbar - https://addons.mozilla.org/firefox/2897/
Public Fox - https://addons.mozilla.org/firefox/3911/
XForms Buddy - http://beaufour.dk/index.php?sec=misc&pagename=xforms
MR Tech Local Install - http://www.mrtech.com/extensions/local_install/
Nightly Tester Tools - http://users.blueprintit.co.uk/~dave/web/firefox/buildid/index.html
IE Tab - https://addons.mozilla.org/firefox/1419/
User-Agent Switcher - https://addons.mozilla.org/firefox/59/
ServerSwitcher - https://addons.mozilla.org/firefox/2409/
HeaderMonitor - https://addons.mozilla.org/firefox/575/
RefControl - https://addons.mozilla.org/firefox/953/
refspoof - https://addons.mozilla.org/firefox/667/
No-Referrer - https://addons.mozilla.org/firefox/1999/
LocationBar^2 - https://addons.mozilla.org/firefox/4014/
SpiderZilla - http://spiderzilla.mozdev.org/
Slogger - https://addons.mozilla.org/en-US/firefox/addon/143
Fire Encrypter - https://addons.mozilla.org/firefox/3208/

Add-ons for Firefox that help with xxJavascript and Ajax web application security
Selenium IDE - http://www.openqa.org/selenium-ide/
Firebug - http://www.joehewitt.com/software/firebug/
Venkman - http://www.mozilla.org/projects/venkman/
Chickenfoot - http://groups.csail.mit.edu/uid/chickenfoot/
Greasemonkey - http://www.greasespot.net/
Greasemonkey compiler - http://www.letitblog.com/greasemonkey-compiler/
User script compiler - http://arantius.com/misc/greasemonkey/script-compiler
Extension Developer's Extension (Firefox Add-on) - http://ted.mielczarek.org/code/mozilla/extensiondev/
Smart Middle Click (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/3885/

Bookmarklets that aid in web application security
RSnake's security bookmarklets - http://ha.ckers.org/bookmarklets.html
BMlets - http://optools.awardspace.com/bmlet.html
Huge list of bookmarklets - http://www.squarefree.com/bookmarklets/
Blummy: consists of small widgets, called blummlets, which make use of xxJavascript to provide rich functionality - http://www.blummy.com/
Bookmarklets every blogger should have - http://www.micropersuasion.com/2005/10/bookmarklets_ev.html
Flat Bookmark Editing (Firefox Add-on) - http://n01se.net/chouser/proj/mozhack/
OpenBook and Update Bookmark (Firefox Add-ons) - http://www.chuonthis.com/extensions/

SSL certificate checking / scanning
[ZIP] THCSSLCheck - http://thc.org/root/tools/THCSSLCheck.zip
[ZIP] Foundstone SSLDigger - http://foundstone.com/resources/freetooldownload.htm?file=ssldigger.zip
Cert Viewer Plus (Firefox Add-on) - https://addons.mozilla.org/firefox/1964/

Honeyclients, Web Application, and Web Proxy honeypots
Honeyclient Project: an open-source honeyclient - http://www.honeyclient.org/trac/
HoneyC: the low-interaction honeyclient - http://honeyc.sourceforge.net/
Capture: a high-interaction honeyclient - http://capture-hpc.sourceforge.net/
Google Hack Honeypot - http://ghh.sourceforge.net/
PHP.Hop - PHP Honeynet Project - http://www.rstack.org/phphop/
SpyBye - http://www.monkey.org/~provos/spybye/
Honeytokens - http://www.securityfocus.com/infocus/1713

Blackhat SEO and maybe some whitehat SEO
SearchStatus (Firefox Add-on) - http://www.quirk.biz/searchstatus/
SEO for Firefox (Firefox Add-on) - http://tools.seobook.com/firefox/seo-for-firefox.html
SEOQuake (Firefox Add-on) - http://www.seoquake.com/

Footprinting for web application security
Evolution - http://www.paterva.com/evolution-e.html
GooSweep - http://www.mcgrewsecurity.com/projects/goosweep/
Aura: Google API Utility Tools - http://www.sensepost.com/research/aura/
Edge-Security tools - http://www.edge-security.com/soft.php
Fierce Domain Scanner - http://ha.ckers.org/fierce/
Googlegath - http://www.nothink.org/perl/googlegath/
Advanced Dork (Firefox Add-on) - https://addons.mozilla.org/firefox/2144/
Passive Cache (Firefox Add-on) - https://addons.mozilla.org/firefox/977/
CacheOut! (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1453/
BugMeNot Extension (Firefox Add-on) - http://roachfiend.com/archives/2005/02/07/bugmenot/
TrashMail.net Extension (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1813/
DiggiDig (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2819/
Digger (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1467/

Database security assessment
Scuba by Imperva Database Vulnerability Scanner - http://www.imperva.com/scuba/

Browser Defenses
DieHard - http://www.diehard-software.org/
LocalRodeo (Firefox Add-on) - http://databasement.net/labs/localrodeo/
NoMoXSS - http://www.seclab.tuwien.ac.at/projects/jstaint/
Request Rodeo - http://savannah.nongnu.org/projects/requestrodeo
FlashBlock (Firefox Add-on) - http://flashblock.mozdev.org/
CookieSafe (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2497
NoScript (Firefox Add-on) - http://www.noscript.net/
FormFox (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1579/
Adblock (Firefox Add-on) - http://adblock.mozdev.org/
httpOnly in Firefox (Firefox Add-on) - http://blog.php-security.org/archives/40-httpOnly-Cookies-in-Firefox-2.0.html
SafeCache (Firefox Add-on) - http://www.safecache.com/
SafeHistory (Firefox Add-on) - http://www.safehistory.com/
PrefBar (Firefox Add-on) - http://prefbar.mozdev.org/
All-in-One Sidebar (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/1027/
QArchive.org web file checker (Firefox Add-on) - https://addons.mozilla.org/firefox/4115/
Update Notified (Firefox Add-on) - https://addons.mozilla.org/en-US/firefox/addon/2098/
FireKeeper - http://firekeeper.mozdev.org/

Browser Privacy
TrackMeNot (Firefox Add-on) - https://addons.mozilla.org/firefox/3173/
Privacy Bird - http://www.privacybird.com/

Application and protocol fuzzing (random instead of targeted)
Sulley - http://fuzzing.org/
taof: The Art of Fuzzing - http://sourceforge.net/projects/taof/
zzuf: multipurpose fuzzer - http://sam.zoy.org/zzuf/
autodafe: an act of software torture - http://autodafe.sourceforge.net/
EFS and GPF: Evolutionary Fuzzing System - http://www.appliedsec.com/resources.html


반응형

개발 도구

  1. Eclipse : http://www.eclipse.org/
  2. Netbean : http://www.netbeans.org/community/releases/60/index.html
  3. Firebug : http://www.getfirebug.com/

소스코드 관리

  1. CVS : http://www.cvshome.org
  2. Subversion : http://subversion.tigris.org
  3. MS Visual SourceSafe
  4. BitKeeper : http://www.bitkeeper.com
  5. ClearCase : http://www-306.ibm.com/software/awdtools/clearcase/

빌드 스크립트 도구

  1. make : http://source.redhat.com/cygwin
  2. Automake : http://www.gnu.org/software/automake
  3. Ant : http://ant.apache.org
  4. NAnt : http://nant.sourceforge.net
  5. Groovy : http://groovy.codehaus.org
  6. Rake : http://rake.rubyforge.org/  
  7. SCons : http://www.scons.org/

빌드 시스템

  1. Mavenhttp://maven.apache.org 
  2. Maven2 : http://maven.apache.org/maven2/index.html

CI 도구 (Continuous integration )

  1. CruiseControl : http://cruisecontrol.sourceforge.net
  2. CruiseControl .NET : http://sourceforge.net/projects/ccnet
  3. DamageControl : http://damagecontrol.codehaus.org
  4. AntHill : http://www.urbancode.com/projects/anthill
  5. Continuum : http://maven.apache.org/continuum
  6. LuntBuild : http://luntbuild.javaforge.com/  
  7. Buildix : http://buildix.thoughtworks.com/  
  8. Hudson : https://hudson.dev.java.net/  (직관적이고 사용법이 쉬움)

이슈 추적 도구

  1. Bugzilla : http://www.bugzilla.org
  2. JIRA : http://www.atlassian.com/software/jira/default.jsp
  3. FogBugz : http://www.fogcreek.com/FogBugz
  4. PR-Tracker : http://www.prtracker.com  
  5. Trac : http://trac.edgewall.org/

테스트 프레임워크

  1. JUnit : http://www.junit.org
  2. NUnit : http://www.nunit.org
  3. xUnit.NET : http://www.codeplex.com/xunit
  4. MbUnit : http://www.mbunit.org
  5. HTMLUnit : http://htmlunit.sourceforge.net
  6. HTTPUnit : http://httpunit.sourceforge.net
  7. JWebUnit : http://jwebunit.sourceforge.net
  8. Cobertura : http://cobertura.sourceforge.net
  9. Clover : http://www.cenqua.com/clover  
  10. Cactus : http://jakarta.apache.org/cactus/
  11. Emma : http://emma.sourceforge.net/
  12. Fit : http://fit.c2.com
  13. Fitness : http://fitnesse.org  
  14. Watir : http://wtr.rubyforge.org
  15. Systir : http://atomicobject.com/systir.page
  16. AUT : http://aut.tigris.org/
  17. UnitTest++ : http://unittest-cpp.sourceforge.net/  
  18. TestNG : http://testng.org/doc/  
  19. CppUnit : http://sourceforge.net/projects/cppunit  
  20. CppUnit2 : http://cppunit.sourceforge.net/cppunit-wiki/CppUnit2  
  21. Selenium : http://www.openqa.org/
  22. Agitar : http://www.agitar.com/  
  23. JTest : http://www.parasoft.com/jsp/home.jsp  
  24. PushToSoft : http://www.pushtotest.com/  
  25. Eclemma : http://www.eclemma.org/

프로젝트 관리

  1. OpenProj : http://openproj.org/openproj 
  2. dotproject : http://www.dotproject.net/
  3. Mantis : http://www.mantisbt.org/

커뮤니케이션 도구, 위키

  1. MoinMoin : http://moinmoin.wikiwikiweb.de/
  2. Confluence : http://www.atlassian.com/software/confluence/
  3. TWiki : http://twiki.org/
  4. SocialText : http://www.socialtext.com/  
  5. Springnote : http://www.springnote.com/ko

성능분석

  1. ANTS Load : http://www.red-gate.com/products/ants_load/index.htm  
  2. JunitPerf : http://www.clarkware.com/software/JUnitPerf.html  
  3. Jmeter : http://jakarta.apache.org/jmeter/

기타

  1. Structure101 : http://www.headwaysoftware.com/index.php  
  2. FreeMind : http://freemind.sourceforge.net/wiki/index.php/Main_Page  
  3. Capistrano : http://manuals.rubyonrails.com/read/book/17


 

출처 :   개발이 좋아 개발자가된 많은 사람들에게 말하고 싶은 이야기. by k16wire
           http://moai.tistory.com/notice/270 

반응형

[edit] Open-source products

  • Bandera — analyser for Java
  • Checkstyle — analyse Java and apply coding standard
  • ClassCycle — analyse Java class cycles and class and package dependencies (Layers)
  • CQual — A tool for adding type qualifiers in C
  • FindBugs — an open-source static bytecode analyzer for Java (based on Jakarta BCEL).
  • Flawfinder — open source programming tool that examines C or C++ source code for security weaknesses.
  • Jlint — for Java
  • JsLint - online analyzer for JavaScript
  • Oink — collaboration of C++ static analysis tools
  • Perl::Critic - a static code analysis tool for Perl
  • Pixy — a PHP 4 source code scanner for detection of XSS and SQL injection vulnerabilities.
  • PMD (software) — a static ruleset based Java source code analyzer that identifies potential problems.
  • PyChecker - The original static code analyser for Python.
  • pylint - A static code analyser for Python. Works as a plugin to PyDev for the Eclipse IDE.
  • RATS — Rough Auditing Tool for Security, which can scan C, C++, Perl, PHP and Python source code.
  • Soot — A Java program analysis and compiler optimization framework
  • Sparse — a tool designed to find faults in the Linux kernel.
  • Splint — an open source evolved version of Lint (C language).

[edit] Commercial products

  • Aivosto Oy's - Project Analyzer - Static code analysis tool for VBA, and VB6/VB.net
  • Armorize Technologies CodeSecure - source code scanning (PHP, J2EE, ASP, etc.)
  • Axivion Bauhaus Suite — a tool for C, C++, Java and Ada code that comprises various analyses such as architecture checking, interface analyses, and clone detection.
  • checKing - monitors the quality of software development process, including violations of coding rules for Java, JSP, Javascript, XML and HTML.
  • Checkmarx CxSuite - a suite of software which helps developers and auditors identify software security vulnerabilities. Company homepage (http://www.checkmarx.com)
  • ClockSharp - checks C# code against the Philips C# coding standard.
  • Compuware DevPartner - static code analyzer for .NET (C#, ASP.NET) with Visual Studio 2005 integration
  • Coverity Prevent — analyzes C, C++ and Java code.
  • DMS Software Reengineering Toolkit — supports custom analysis of C, C++, Java, COBOL, and many other languages.
  • Fortify — helps developers identify software security vulnerabilities in C/C++, Java, JSP, Javascript, ASP.NET, C#, VB.NET, PHP, "Classic" ASP, VB, PL/SQL, T-SQL, XML and other languages.
  • FxCop — static analysis for Microsoft .NET programs based on IL. Standalone and integrated in some Microsoft Visual Studio editions. From Microsoft.
  • Green Hills Software DoubleCheck - static analysis for C and C++ code.
  • HP Code Advisor - A static analysis tool for C and C++ programs
  • Intel Compiler Suite — The Intel compilers Intel C++ Compiler and Intel_Fortran_Compiler both offer static analysis.
  • IntelliJ IDEA — IDE for Java that also provides static code analysis.
  • Klocwork K7 — provides security vulnerability and defect detection as well as architectural and build-over-build trend analysis for C, C++ and Java
  • Lattix, Inc. LDM - Architecture and dependency analysis tool for Ada, C/C++, Java, .NET software systems.
  • LDRA Testbed - A software analysis and testing tool suite for C, C++, Ada83, Ada95 and Assembler (Intel, Freescale, Texas Instruments).
  • M Squared Technologies Resource Standard Metrics - source code analysis and metrics (Java, Javascript, etc.)
  • Microsoft Visual Studio - Visual Studio Team System includes a static code analyzer.
  • MZTools - MZTools 3.0 - Free Static Code Analysis, productivity enhancement tool for VBA.
  • NStatic - deep static analysis of C# code.
  • Ounce Labs — automated source code analysis that enables organizations to identify and eliminate software security vulnerabilities in languages including Java, JSP, C/C++, C#, ASP.NET, and VB.Net.
  • Parasoft - static code analysis and security testing tools for Java, C, C++, C#, .Net, HTML, CSS, JavaScript, VSscript.
  • PC-Lint - A multiplatform static code analysis tool by Gimpel Software for C and C++. Also available for the GNU/Linux and Unix operating systems in the form of FlexeLint.
  • PolySpaceTM code verifiers by The MathWorks - Software verification for C, C++ and Ada
  • QA-C - deep static analysis of C for quality assurance and guideline enforcement.
  • ReSharper - Add-on for Visual Studio 2003/2005 from the creators of IntelliJ IDEA, which also provides static code analysis for C#.
  • SemmleCode — object oriented code queries for static program analysis.
  • SofCheck Inspector — provides static detection of logic errors, race conditions, and redundant code for Java and Ada.
  • Sotoarc/Sotograph - Architecture and quality in-depth analysis and monitoring for Java, C#, C and C++
  • STAN — Structure Analysis for Java. Eclipse integrated visual dependency analysis, quality metrics and reporting.
  • Swat4j — a model based, goal oriented source code auditing tool for Java. Comes as an Eclipse plug-in.
  • Telelogic Logiscope RuleChecker (coding standards checking) and Audit (metrics measurement and ISO 9126-based quality modeling) for C, C++, Ada, Java.
  • TorqueWrench - A static Java bytecode analysis tool by StackFrame, LLC.
  • Understand — analyzes C,C++, Java, Ada, Fortran, Jovial, Delphi — reverse engineering of source, code navigation, and metrics tool.
  • Viva64 — analyzes C, C++ code for detect 64-bit portability issues.
  • Veracode SecurityReview — an outsourced application security testing and remediation, C, C++, Java, .Net and other languages.
  • CodePro Analytix - Static code analysis for Java, integrated with Eclipse.
  • Sparrow - C/C++ memory-bug detecting static analyzer.

+ Recent posts