블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Oracle ALM 솔루션

ALM | 2009. 7. 24. 10:39 | Posted by 조대협
그토록 찾았는데 몰랐다. 오라클에도 ALM 솔루션이 있는지는
형상 관리와 TASK 관리는 되는것 같은데, JDeveloper 기반이네.
http://www.oracle.com/technology/obe/obe11jdev/bulldog/gettingstartedtpc/getting_started_tpc.htm

'ALM' 카테고리의 다른 글

Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

ALM 에서 각 기능들은 필수인가?

ALM | 2009. 7. 3. 10:07 | Posted by 조대협

KX사의 프로젝트에서는 Bugzilla
S사의 프로젝트에서는 JIRA + Hudson + xUnit
H사의 프로젝트에서는 JIRA + Confluence + Bamboo + xUnit 
또다른 H사의 프로젝트에서는 JIRA + Hudson + xUnit + Mantis
S사의 프로젝트에서는 Confluence + Hudson + xUnit
K사에서는 DokuWiki
지금 K사의 프로젝트에서는 Trac 

매번 프로젝트마다 ALM 툴셋을 바꿔가면서 사용해보고 있습니다. 제품들을 실제 경험해봄으로써 최적의 조합을 찾기 위함입니다.

그런데, 프로젝트를 하면서 ALM을 적용하면서 깨달은것중의 하나가, ALM의 4개의 Module을 꼭 모두 적용할 필요가 없다는 것입니다. 프로세스나 사상을 기반으로 하되 프로젝트의 특성에 따라서 필요한 모듈만 사용하면 된다는 것입니다.

Issue Tracker를 이용한 Task Management의 경우, 팀의 규모가 적어도 5인 이상이 되고, 이슈가 많을 경우 즉 추적성을 많이 필요로 하고 Task에 대한 공유가 도구 없이 통제할 수 있는 범위를 벗어나는 경우에만 도입하는 것이 유리합니다. 그렇지 않을 경우 Task Logging하는 것 자체가 Burden이 될 수 있습니다. 특히나 Issue Logging에 대해서는 일정기간 개발자들이 시스템에 익숙해지는 Learning Curve에 대한 시간이 필요하기 때문에, 그 전에는 Excel 을 이용한 Scrum 방법론 기반의 팀 운영 방식이 가장 효율적입니다. 

빌드 자동화의 경우 개발이 있는 경우는 대부분 긍정적입니다. 투자되는 시간대비 효과가 좋습니다. 단 이는 개발 중심의 프로젝트인 경우입니다. EAI와 같은 솔루션 기반의 시스템 개발의 경우 코딩 보다 솔루션의 기능을 사용하는 경우가 많기 때문에 이러한 경우에는 CI의 필요성이 반감됩니다.

테스트 자동화의 경우도 마찬가지입니다. In-House 개발의 경우에는 효과가 좋습니다. 그리고 팀원이 많을수록 품질관리에 대한 요구 사항은 올라가기 마련이지만 소규모 팀의 경우 Sprint (주기)를 짧게 나눠서 Short Release를 하면서 매번 테스트를 하는 것이 단위 테스트 구현이나 테스트 자동화 보다 훨씬 효율적입니다. JUnit을 만든 Kent Beck역시 JUnit Max를 만들면서 단위테스트가 모든 프로젝트에서 필요하지 않다는 것을 언급한적이 있습니다.
 제가 제시하는 방안은 시스템에서는 몇가지 대표적인 구현 패턴이 존재합니다. 이런 패턴들을 프로젝트 초기에 Prototyping을 하고 아키텍쳐 검증이라는 이름으로 테스트를 진행해서 해당 패턴의 아키텍쳐 적인 특성을 검증합니다. 이 단계에서는 기능적인면보다는 성능,장애,안정성에 대한 비기능적 테스트를 위주로 함으로써 아키텍쳐의 위험성을 초기에 검출하여 해결안을 찾아내고 RISK를 조기에 없앱니다. 검증된 패턴에 대해서 개발자들이 찍어내기식의 개발을 하게 되는데, 이미 검증된 아키텍쳐이기 때문에, 비기능적 요건에 대해서는 테스트를 할 필요가 없고, 기능적으로 되냐 안되냐만 검증을 하면 됩니다. 필요할 경우에만 기능 위주의 단위 테스트를 적용하도록 합니다.

모든 기술과 이론은 "꼭 이래야 한다" 라는 것은 없는 것 같습니다. 상황과 조건에 따라서 적절하게 사용해야 그 효과가 극대화 되는 것 같습니다.

다음 프로젝트에서는 Polarion을 도입해서 사용해봐야 겠습니다.




'ALM' 카테고리의 다른 글

관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ALM

댓글을 달아 주세요

  1. Green 2009.07.03 11:32  댓글주소  수정/삭제  댓글쓰기

    글 잘 읽었습니다.
    상황에 맞는 최적의 조합을 찾기가 매우 어려운것 같습니다.
    지적허영심이나 과시욕에 의해 방해를 받기도 하구요..
    필요한 경우에만 단위테스트를 적용한다는 내용도 신선한 것 같습니다.
    단위테스트도 실제로 쓰다보면 과도한 부담이 되는 경우가 많거든요..
    그 필요한 경우의 시각차가 클수도 있겠지만요..
    테스트 커버리지의 범위도 생각을 해야 할 것 같습니다.

    • 조대협 2009.07.03 11:49 신고  댓글주소  수정/삭제

      특히 커버러지는 Middleware같이 각각의 모듈이 기능적으로 유일한 경우에는 80% 이상 가는 것이 맞겠지만 일반적인 엔터프라이즈 애플리케이션이나 웹애플리케이션의 경우 아키텍쳐적인 특성이 대부분 동일하기 때문에 주요 업무 30~40%만 커버해도 충분하리라 생각됩니다. (사견입니다.)

IBM에서 ALM E-Book을 무료 배포합니다.

ALM | 2009. 6. 30. 15:28 | Posted by 조대협
http://www.infoq.com/articles/scaling-agile-with-calm

C ALM이라는 개념을 사용합니다. C는 Collaboration을 의미합니다. 애자일 사상에 근간한 ALM을 설명합니다.
Erich Gamma가 필자로 참여했다는 것이 흥미롭고, 그리고 다들 아시겠지만 IBM은 Rational 제품군을 위주로 한 케이스 툴과 Jazz라는 ALM 플랫폼을 가지고 있기 때문에 강력한 ALM 벤더중의 하나입니다.
그러나 Rational 제품들은 툴의 복잡도가 높아서 실제 구현할때 구현 난이도가 고민인 부분중에도 하나입니다.

'ALM' 카테고리의 다른 글

Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

현재 진행하고 있는 프로젝트에서 Trac을 도입해서 사용하고 있습니다.
Trac 뿐만 아니라 사실상 거의 모든 이슈 트랙킹 시스템을 이용하여 팀 일정 관리를 할때 공통적으로 생기는 문제 같은데,
팀관리에서 가장 중요한것은 어떤 TASK를 누가, 언제 하느냐 입니다.
이슈 트랙킹 시스템은, 어떤과 누가를 잘 추적할 수 있게 해줄뿐만 아니라 Comment등을 통한 History 기능으로 어떻게 하느냐까지 잘 관리할 수 있습니다.

그런데 문제는 "언제" 즉 시간에 대한 부분입니다.
이슈 트랙킹 시스템들은 대부분 Time Frame,Mile stone, Due date 식으로 대략 Task 단위의 시간을 제공합니다만, 프로젝트 관리에 있어서 간트 챠트만한것이 없습니다. 문제는 이 이슈 트랙킹 시스템들이 간트 챠트를 제대로 제공하지 않는 경우가 허다하다는 것입니다.

매일 아침 Scrum 미팅을 할때, 간트 챠트를 이용하면 팀원이 무엇을 하고 있는지, 어제와 그제 무었을했고, 이번주에 무엇을 하고 있는지를 비주얼하게 보여줘서 리소스를 할당하는데 편리한데
이슈 트랙킹 시스템은 각 태스크로 관점이 맞춰져 있어서 사실상 팀관리를 하는데 어려움이 많습니다. (사실상 이부분은 엑셀이 더 편할것 같습니다.) 몬가 방법을 더 찾아봐야할것 같습니다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 카이(KAi) 2009.05.19 18:27 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 :)
    TRAC 은 생각보다 거대한 프로젝트로 수백개의 플러그인들이 있습니다.
    그중 간트 플러그인도 있는데 필요하신게 이게 맞는지 모르겠네요. 예제를 제공하고 있지 않아서 확인은 어렵군요. =_=
    http://trac-hacks.org/wiki/FlashGanttPlugin

    이 외에도 http://trac-hacks.org/wiki/ 에 많은 플러그인들이 있는데 한번 찾아보세요. 'ㅁ'

  2. kingori 2009.05.20 10:45  댓글주소  수정/삭제  댓글쓰기

    저희도 trac 을 쓰다가 많이 힘들었던 것이 planning 측면을 고객에게 제시하기 어려웠던 것이었습니다. 이를 위해서 date field 추가 plug-in 설치하고, trac의 sqlite 를 읽어들여 다른 모양으로 보여주기 위해 customization 하는 등의 노력을 했었는데, 결국은 서로 별로여서 계획쪽은 MSProject 로(갑사 보고, 관리), 실행쪽은 trac(개발자 간 communication) 으로 병행했습니다.

    더 잘 쓰는 방안이 있을 텐데, 해답을 찾기 어렵네요. 제가 갑이라고 하더라도 trac의 plan쪽으로 보고받는 것은 좀 아니라는 생각이 들더군요.

  3. 머샤머샤 2009.05.25 14:40  댓글주소  수정/삭제  댓글쓰기

    좀. 다른 관점이 아닐까요? Trac의 Task와 (프로젝트관리)관점의 MS-Project Task는 서로 다른 View라고 생각됩니다. (물론 일치화 시키시는 분들도 있으시겠지만 말입니다.)

    어느 한쪽의 데이터를 기반으로 다른쪽 데이터를 (손쉽게)생성하는 쪽으로 고민해보는 것이 다 타당하다는 의견입니다.

    체크인/아웃 목록 <> 이슈티켓 <> 프로젝트 Task <> 작업시간관리... 모두 연관은 있습니다만, 서로다른 관점의 View라고 생각됩니다.

ALM의 괴리.

ALM | 2009. 5. 14. 22:58 | Posted by 조대협
요즘 매일 대전으로 출퇴근을 하고 있습니다.
계약 관계가 복잡하게 얽혀서 근 3달정도 지연이 되어 버린 프로젝트입니다.
원래는 Project Manager와 Cheif Architect 역할로 계약이 되었지만, 구현일정 관계로 한 모듈의 설계와 구현을 모두 맏고 있습니다.

그러다 보니, 처음에는 ALM을 도입하여 SVN을 이용한 형상관리, WAS Configuration Management, Trac을 이용한 이슈 관리와 Wiki를 이용한 문서화를 진행하려고 계획을 했었습니다.
이번달이 아니라 3월경에 SOW(Scope Of Work )작업으로 일주일정도 진행한 적이 있었는데, 그때는 코딩할당량이 없어서 그나마 프로젝트 관리를 할 수 있었습니다만,
지금은 구현에 치여서 ALM적용을 하지 못하고 있습니다. (부분적으로나마 하고는 있지만... 왠지 체계가...)
프로젝트 관리와 프로세스의 셋업등은 역시나 개발을 하면서(선행 개발이 아니라, 직접 모듈 개발)는 쉽지가 않은 일입니다.
이번에 깨달은 교훈중에 하나는 ALM을 적용하기 위해서는 그만큼의 Man month가 필요하다는 것입니다.누가 그러더군요.. No free lunch...

'ALM' 카테고리의 다른 글

ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 놀새~ 2009.05.15 07:55  댓글주소  수정/삭제  댓글쓰기

    해봐서 알겠지만 프로젝트 프로토타입 단계나 구현 이전의 상세 설계 단계와 병행하여 진행해 주지 않으면 그 이후는 빼도 박도 못한다는 거!
    그나저나 매일같이 대전 출퇴근요? 흐어~~ 기름값 대주죠? 흐어..부럽부럽.

    • 조대협 2009.05.15 08:49 신고  댓글주소  수정/삭제

      그르게요. 그래요 개념은 놓지 말고 적용해야져. 결국 나중에 가서 고생할텐데...

      그리고 기름값은 대주는데... 몸이 힘들어유...
      그나저나 요즘 잘 지내시져?

  2. 놀새~ 2009.05.15 11:20  댓글주소  수정/삭제  댓글쓰기

    삼X 마지막 날이에요. 흐흐..

JUnit Max

ALM/Test Automation | 2009. 5. 6. 09:49 | Posted by 조대협
블로그를 기웃거리다가 찾아낸 툴인데
JUnit을 만들고 실행하지 않고, 바로 코딩 단계에서 테스팅을 해줄 수 있는 도구.
직접 동영상을 보는게 이해하기가 빠를듯한데.
상당히 편리하다.

'ALM > Test Automation' 카테고리의 다른 글

Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18
Selenium (UI 테스트 자동화)  (1) 2009.02.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. Joowonpapa 2009.05.06 11:38  댓글주소  수정/삭제  댓글쓰기

    싸지만 유료라는거...

오늘 OKJSP의 테크 트렌드에서 본 좋은 제품 하나.. http://www.zeroturnaround.com/ Java Agent로 JVM을 Weaving하여, Zero downtime으로 redeployment를 가능하게 해준다. 얼마나 Production에서 제대로 동작할지는 모르겠지만, WLP.WLI는 몰라도, WLS에 전통적인 J2EE Application이나 Spring 기반의 Ap에서는 꽤나 쓸만할듯.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Trac

ALM | 2009. 4. 9. 17:03 | Posted by 조대협
이번 프로젝트에 6번째로 ALM을 사용해보기로 결정하였습니다.
SVN,WIKI,Issue Tracking이 모두 필요하고 설치할 시간도 없어서 Trac (Trac On Windows - 압축만 풀면 사용 가능하게 한 패키징)을 설치하여 사용하고 있습니다.

올인원 패키지이고 플러그인을 지원해서 좋긴하지만 JIRA의 파워풀한 기능을 경험한 저로써는 불편한점이 많더군요. (예를 들어서 조회 조건 같은 것을 Query로 직접 코딩해야 하는 불편함등.)

이번 프로젝트도 상당히 긴 프로젝트가 될것 같습니다. Trac 기반의 ALM을 시험해볼 좋은 기회가 되겠지요.

Trac에 설치한것은 다음과 같습니다.
- TOW (Trac On Windows)
- Timingandestimation plug in
- ScrumBurnDownChart plug in
을 설치하였습니다. Burn down chart 관리함에 있어서 Estimated time을 얼마나 잘 예측하고 시간에 대한 관리를 어떻게 할 수 있느냐가 주요 포인트가 될것 같습니다.
 

'ALM' 카테고리의 다른 글

IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. Richpapa 2009.04.09 19:16  댓글주소  수정/삭제  댓글쓰기

    꼭, 후기 올려주세요. ^^

  2. 안모대리 2009.04.15 11:24  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 조차장님~~~
    Trac0.11인가 그 버전하고 eclipse 최신 버전하고 연동하는 방법아시면 좀 알려주세요. 각각은 잘 설치되는데 Mylyn 받아서 최신 eclipse에서 하려니 잘 안되네요. Trac++쪽은 모듈이 있는것 같은데.. Trac++이 limit이 있는 라이센스라..
    글구 저도 윗분처럼 후기 부탁드립니다. 화이팅~~

Software Testing Proces

ALM/Test Automation | 2009. 4. 9. 10:25 | Posted by 조대협
Testing process
View more presentations from Byungwook.

'ALM > Test Automation' 카테고리의 다른 글

테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18
Selenium (UI 테스트 자동화)  (1) 2009.02.09
EasyMock을 이용한 단위 테스트  (5) 2008.11.07
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

ALM Overview PPT

ALM | 2009. 3. 16. 15:15 | Posted by 조대협

그간 정리해왔던 ALM에 대해서 전체 그림을 다시 한번 정리하였습니다. 컨버팅 과정에서 폰트가 깨져서 좀 보기가 어려울 수 있습니다. 별도로 자료가 필요하신분들은 요청하시면 보내드리도록 하겠습니다.

ALM의 전체 Full Process와 어떤 제품으로 어떻게 구혀하는지, 그리고 구현 전략에 대해서 기술되어 있습니다.

감사합니다.


ALM (Application Lifecycle Management)
View more presentations from Byungwook.

'ALM' 카테고리의 다른 글

ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG Agile, ALM, PPT

댓글을 달아 주세요

  1. 남종환 2009.03.18 09:43  댓글주소  수정/삭제  댓글쓰기

    자료 공개 감사드립니다

    댓글로 요청드리면 될른지요?

    cccnam5158@gmail.com

  2. 2009.03.18 14:27  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  3. 컴프 2009.03.19 17:05  댓글주소  수정/삭제  댓글쓰기

    좋은 글 많이 보고 있습니다.
    조대협님과 케누님께 항상 감사하고 있습니다.
    (Guest Book은 티스토리 가입을 하라고 유도해서..^^)

  4. 2009.03.26 00:59  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  5. 2009.06.02 10:19  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 조대협 2009.06.02 15:17 신고  댓글주소  수정/삭제

      잘 지내시지요?
      http://www.slideshare.net/Byungwook/alm-application-lifecycle-management-1149823?type=powerpoint
      들어가셔서 Get File 하시면 원본 PPT를 받으실 수 있습니다.

  6. sjkoo 2009.10.16 17:17  댓글주소  수정/삭제  댓글쓰기

    오늘 오후내내 글잘읽고 있습니다.
    그동안 너무 안이하게 산거같아요. 알아야 할것이 이리많은데.
    제자신을 공부하고픈 맘이 생기도록 해주셔서 감사해요

  7. 2012.12.26 16:12  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 조대협 2012.12.27 10:05 신고  댓글주소  수정/삭제

      http://www.slideshare.net/Byungwook/alm-application-lifecycle-management-1149823 에서 직접 다운 로드 받으시면 됩니다.
      설명은 http://bcho.tistory.com/680 와 http://bcho.tistory.com/682 를 참고하십시요.

언제 어떤 코드 리뷰 기법을 사용해야 하는가?

 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까?

 코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다.

, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다.

인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다.

 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다.

 1 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍쳐의 큰 틀이 되며, 추후 개발에도 이 아키텍쳐는 크게 변경되지 않는다. (1 Release 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다.)  그래서 1 Release후에 정밀 Inspection을 해서 아키텍쳐의 안정성을 검증할 필요가 있다.

 개발 후반의 시스템 테스트는 주로 비기능적인 요건 (성능,안정성등..)에 대한 성능 테스트가 이루어지는 단계이기 때문에, 테스트 시나리오가 미리 잡혀져 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있기 때문에, 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

 인스펙션을 수행하는 주체는 전문 SI Task Force를 운영하여 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체 (네이X)와 같은 업체는 QA 조직내에 자체적으로 인스펙션팀을 운영하는 것을 권장한다. 그외의 일반 업체 ()나 기업의 경우 인스펙션팀을 운영하기 보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

 인스펙션의 결정 주체는 주로 PMO(Project Management Office) AA (Application Architect) 되는 것이 바람직하다, 대체로 개발 주체 조직 외부에서 인력을 데리고 오고, 여러팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

 팀리뷰

팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다.

일주일에 한번정도, 한시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다.

리뷰는 발표자가 리드를 하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케쥴로 조정을 해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용하여 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management Task로 연결이 되어야 한다.

리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해서 반영 내용을 반드시 검증하도록 한다.

 웍쓰루 (WalkThrough)

일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다.

팀리뷰처럼 PL이나 시니어 개발자가 중재를 하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

 Peer Review

신입 개발자 교육이나, 해당 제품이나 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식공유)와 품질 유지를 위해서 유용하다.. 대신 리뷰어의 Task 부담이 가중되기 때문에 (예상하는 것 보다 많이. 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

 요약

 

시기

효과

변경에 대한 비용

수행 비용

주체

인스펙션

1 Release,
시스템 테스트

매우높음

매우 높음

높음

PMO,QA,AA

팀리뷰 ★

매주

높음

보통

보통

PL

웍쓰루

비정기적

낮음

보통

낮음

원하는 개발자

Peer Review

필요한 경우

경우에 따라 높음

낮음

보통

시니어 개발자

 본인의 경험상 팀리뷰가 가장 효과가 높다. Peer Review는 팀원간의 실력 편차가 클 때 탄력적으로 운영하였고, Enterprise System과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍쳐로 인해서 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸떼 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 내가 만든 코드를 남이 잘못되었다고 이야기 한다.” 입니다.

리뷰의 주요 목적은 결함의 발견과 개선 방안입니다. 흔히 농담 삼아서 창던지기라고 이야기 하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하게 됩니다. 그래서 실제로 인스펙션을 해보게 되면 개발자는 인터뷰를 당하는 것에 대해 취조 당하는 느낌을 가지게 될 수 도 있고 방어적으로 행동할 수 도 있게 됩니다.

 팀리뷰의 경우 감정싸움까지 가는 경우가 허다하지요.

 팀리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신 공격을 받지 않도록 중재하는 기능도 필요합니다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 사람 사이의 관계에서 발생되는 일이기 때문에 문화의 변화가 필수적입니다.

 또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리가 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이루어져야 합니다.

 경험상으로 팀리뷰가 팀에 자리잡기 위해서는 좋은 리더가 있다하더라도 최소한 1달정도의 (통상 2) 기간이 필요합니다. 급하게 할일은 아니라는 겁니다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 헝그리맨 2009.03.18 13:03  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다.
    저희팀은 PeerReview를 실행중이구요, 결함 발견외에도 정보의 공유및 전달이라는 측면에서
    매우 유용한것 같습니다.
    코드 리뷰에 관심이 많은 한사람으로서 앞으로도 좋은 글 많이 부탁드립니다.

들어가기에 앞서서.

소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다

코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다

코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드리뷰 기법일 수 록, Defect의 발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 Defect의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 주니어 개발자에게로의 지식 전달등의 부가적인 목적들도 함께 가지고 있다

코드 리뷰 스펙트럼

코드 리뷰의 기법을 나누는 방법은 크게, 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, Offline에서 직접 커뮤니케이션을 하느냐? 또는 메신져,Email 이나 기타 자동화된 코드리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

 먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다

) 코드리뷰 기법중에는 Pair Programming이 종종 언급되고는 하지만, 본인의 사견상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용한다는 것은 매우 어렵다고 판단하기 때문에, 코드 리뷰 스펙트럼에서는 제외한다. 


코드 인스펙션

코드리뷰 기법중에서 가장 정형화된 패턴의 기법이다.전문화된 코드리뷰팀이 시스템이 어느정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다.인스펙션팀은 크게 4가지 역할을 가지고 구성이 된다.

1.     Moderator

는 인스펙션팀의 실제적인 메니져로 생각하면 된다. 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다.

또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다.

예를 들면, 인스펙션팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청하여 담당 개발자를 섭외하거나 소프트웨어 설계 문서등을 받아다가 인스펙션팀에 전달한다.

또는 인스펙션된 결과에 대해서 테스트가 필요할 때, 테스팅 환경을 확보하고 인원 (DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 갖는다.

가장 중요한 역할중의 하나는 인스펙션이 언제 끝날 것인지 (Exit Criteria)를 정의하는 역할을 갖는다.

2.     Reader

Reader는 각종 산출물들을 읽고, 인터뷰등을 통해서 전체 시스템을 이해하여 인스펙션팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해서 팀내에서 가장 많은 도메인 지식을 갖는 사람이다.

Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라서 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라서 인스펙션을 진행하게 된다.

3.     Designer/Coder

Designer Coder Reader가 지시한 방향에 따라서 코드를 검증하고 잠재적인 Defect의 발견 및 권장 수정 방안을 만들어 낸다.

4.     Tester

Tester는 인스펙션이 진행중인 모듈에 대해서 테스트를 수행하고 Defect를 찾아내는 역할을 수행하며, 이외에 Designer Coder가 권장한 수정 코드안에 대한 검증과, 실제 업무 개발자가 수정해온 코드에 대한 검증 작업을 수행한다

4가지 역할을 가지고 인스펙션은 다음 6단계로 진행된다.

 

1.     Planning

전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건 (금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건, 등등). 그리고 인스펙션 팀이 이때 SET UP이 된다.

2.     Overview

이 단계에서는 인스펙션 팀에 시스템과 구성 제품등에 대한 교육이 이루어지고, 팀원간의 역할이 정의된다.

3.     Preparation

Inspection을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 Tool (테스팅 툴이나, profiler, Application Performance Monitoring 도구..)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축한다.)

4.     Meeting (Inspection)

각자의 역할에 따라서 Inspection을 수행한다. Inspection을 통해서 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실업무 개발자에게 전달되어 FIX되도록 하고, 필요에 따라서는 권장 수정안을 전달하기도 한다.

5.     Rework

보고된 Defect를 수정한다.

6.     Follow-up

보고된 모든 Defect가 수정되었는지 확인한다.

 팀리뷰

팀리뷰는 코드 인스펙션보다 좀 덜 정형화 되었지만 그래도 일정한 계획과 프로세스를 따른다.

코드 인스펙션 프로세스의 단계 (Planning ,Overview ,Preparation등의 사전 준비 단계는 생략된다.) 역할은 중복되거나 생략될 수 있는데, 발표자(Author) Moderator는 필수적으로 구성된다.

리뷰시간에는 발표자(코드를 만든 사람)가 코드에 대한 설명을 하고, 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정하여 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다. (일정에 반영되어야 한다.)

 Moderator는 프로젝트 관리자 (PM이나 PL)이 될 수도 있으나, 팀내에서 기술적인 실력이 가장 좋은 Senior 개발자가 그 역할을 맏는 것을 권장한다

 일주일에 한번정도 팀리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점 (Short Release) 시점에 수행을 하거나, 테스트 결과를 가지고 리뷰를 하는것도 좋은 방법이 된다

 필자의 경우 프로젝트를 수행할 때, 일주일에 한번 정도 팀리뷰를 진행하였으며, Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해서 팀리뷰를 진행하도록 개발자에게 지시 하였다.

 리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 코드 리뷰 결과라는 분류를 따로 만들어서 관리하였고, 각 의견은 TASK로 생성되어 스케쥴에 포함되었다.


<그림. 팀리뷰 리포트>

웍쓰루 (Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법중에서 가장 비정형적인 방법중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나, 아이디어 수집을 위해서 사용될 수 있다.

개발을 위한 프로세스에서 보다는 “Bug 사례에 대한 회의와 같은 정보 공유성격에 유리하다.

유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다.

웍쓰루는 정기적으로 (주일에 한번) 진행할 수 도 있으며, 또는 정보공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다. (정기적으로 진행하는 것이 참여율이나 집중도가 더 높다.) 

Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review2~3 (주로 2)이 진행하는 코드 리뷰의 형태이다.

코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.

 사전 준비등이 거의 필요없고, 필요할때 마다 자주 사용할 수 있는 리뷰 방법이다.

주로 Senior 개발자(사수) Junior 개발자를 멘토링할 때 사용할 수 있으며, Junior 개발자에 대한 교육과 함께, Junior 개발자가 양산한 코드에 대한 품질을 관리할 수 있다.

 그러나 이 기법은 Senior 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, Senior 개발자의 시간 투여량이 많은 만큼. Senior 개발자의 참여도가 떨어질 수 있다. (형식적으로 될 수 있다. )그래서 프로젝트 관리 관점에서 Peer Review 에 대해서도 프로젝트 스케쥴상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 시켜야할 상황이 있었고, 그때 이 Peer Review를 진행하도록 하였다. 결과적으로 만족할만한 품질을 얻었지만, Senior 개발자에게 Review에 대해서 Task를 지정하고 스케쥴링을 하였음에도 불구하고, Senior 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있기 때문에, 팀원간의 실력 편차와 난이도에 따른 시간 배분과 함께, 경험적 (3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다. )인 작업량 측정이 필요하다

Passaround

코드리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다.

Passaround는 번역하자면 돌려보기이다. 온라인 보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애를 받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 Ownership이 애매하여 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해서 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

 이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다

필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품의 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맏는 개발자가 개발팀에 속해 있었기 때문에 원할한 Passaround 리뷰가 가능했고, 이슈(버그) 트랙킹 시스템 (AtlassianJIRA와 같은)과 소스 코드 Viewing system (AtlassianFisheye)이 많은 도움이 되었다

지금까지 간단하게나마 코드 리뷰의 기법에 대해서 살펴보았다. Formal한 리뷰 (코드 인스펙션..)등에 대한 설명이 많은 것은, Formal한 리뷰가 좋아서라기 보다는 정형화 되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다

회사의 성격 (SI,게임,임베디드,인하우스개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 구름너머 2013.01.25 10:08 신고  댓글주소  수정/삭제  댓글쓰기

    정리가 잘 되어있네요.퍼갑니다.
    감사합니다.
    양식이 있으면 하나 올려주세요.

  2. 잠실사옥 2018.01.26 10:19  댓글주소  수정/삭제  댓글쓰기

    머리속으로 정리 잘하고 갑니다. 감사합니다.

Code Review Article Bookmark

2009. 3. 10. 23:48

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다.
주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다.

그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다.
결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요.

그런데, 만약에 Short Release를 통해서 매번 회귀 테스트를 진행했더라면 어땠을까 하는 생각이 문득 집에 도착한후에 들더군요. 그러한 문제는 아주 조기에 발견이 되었을 것이고, 초반에 아키텍쳐 수정이 가해졌을 것이며, 이렇게 비용을 들여서 Code Inspection을 하거나 추가 비용을 들여서 하드웨어를 증설할 일도 없겠지요...

그리고 여러개의 시스템이 연결된 시스템이기 때문에, 이제서야 통합 작업을 수행합니다. 마찬가지로 Interative and ieration 전략을 사용했더라면 초반부터 통합을 해왔기 때문에 통합때문에 드는 작업이 거의 없었겠지요.

특히 통합이 일정대로 원할하지 못한 경우, 이번에 튜닝을 위해서 거의 5명의 벤더 엔지니어를 불러다 놓고 하루종일 거래 개통도 되지 않아 엔지니어들이 대기하다가 돌아갔습니다. 보통 벤더 엔지니어의 하루 몸값은 Charging을 하는 경우에는 100~120만원선이 됩니다. 5명이니 대략 아무것도 안하고 600만원을 날린셈이 되는 것입니다.

회귀 테스트나 Iteration 방법론, Short Release 를 실제 프로젝트에서는 시간이 없다. 예산이 없다는 이유로 잘 사용하지 않습니다. 기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요.

결국은 위의 사례와 같이 오픈 연기, 하드웨어 추가 구매, 튜닝 컨설팅등의 추가 비용이 발생하고, 끊임없는 야근과 누더기 코드로 이어집니다.

반대로 지난번 프로젝트를 진행했던 S사의 경우 제가 진행했던 파트는 2주 주기의 Short Release를 사용했고, Short Release 마다 어떤 형태로든 비기능 테스트를 통해서 끊임없이 아키텍쳐를 검증했기 때문에, 지금 프로젝트에서는 통합에 대한 이슈나 아키텍쳐를 통째로 흔드는 일이 없습니다.

항상 자연계 열역학 제 1의 법칙을 이야기 하지만, "에너지 불변의 법칙"은 사람이 일할때도 통하나 봅니다. 개발과정에 생략한 테스트와 검증은 프로젝트 말에 그만한 부담으로 다시 돌아옵니다. 아니 에너지 불변의 법칙이 아니라, Defect 증폭의 법칙이라고 해야할까요?
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. zeous 2009.03.05 13:57  댓글주소  수정/삭제  댓글쓰기

    어디서 본 이야기인데
    요즘처럼 하드웨어의 가격이 엄청나게 싸지고 있는 상황에서는
    사람을 통한 소스, 아키텍처의 변경을 통한 튜닝보다는 CPU나 메모리 업그레이드를 통한
    튜닝이 훨씬 싸게 먹힌다고 하더라구요

    물론 이것이 절대적인 대안이 될수는 없지만
    점차 하드웨어의 성능향상이 소프트웨어의 질을 커버해주는 상황이 되어버리면
    소프트웨어의 질의 중요성이 점차 낮아지지 않을까 하는 걱정이 되네요..

    • 조대협 2009.03.05 16:11 신고  댓글주소  수정/삭제

      그것도 ROI 관점에서는 한번 생각해볼만 하겠군요.
      그러나 하드웨어 증설은 유지보수 관점에서, IDC 확보, BOX당 유지보수 비용 지불. BOX당 소프트웨어 LICENSE 추가등의 비용이 들지 않을까요? 오픈 소스 기반이 아니라면 하드웨어 증설은 증설만으로는 끝나는 문제가 아닌것 같습니다. :)

  2. 김민재 2009.03.10 01:17 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다.
    옥에 티라면,
    Itertive and iteration 방법론
    Interative and ieration 전략
    이 두가지 표현인데요.. 일단 오타가 있구요, 동일한 이야기의 핵심 표현인거 같은데 틀린 이유가 잘 짐작이 안되네요. 그리고 추가 내용을 찾고자 구글링을 했는데 이렇다할 내용이 안 나오네요. 관련 자료가 있다면 url 공유 부탁 드립니다. ^^

    • 조대협 2009.03.10 09:53 신고  댓글주소  수정/삭제

      오타 맞습니다. 맞구요.. ^^;
      Iterative and incremental 개발 방법론입니다.
      RUP도 그렇고, 실용주의나 Agile 방법론도 반복 및 점진적 개발방번론(Iterative and incremental) 을 기반으로 하고 있기 때문에 구글링해보시면 자료를 찾으실 수 있을것 같네요.
      감사합니다.

    • 김민재 2009.03.10 17:24 신고  댓글주소  수정/삭제

      http://alistair.cockburn.us/Incremental+versus+iterative+development
      Iterative and incremental 개발방법론은 이 둘을 다 취하는거네요..
      구별해서 생각하는 것도 또 다른 인사이트를 준다고 설명하고 있습니다.

  3. kenu 2009.03.10 08:36  댓글주소  수정/삭제  댓글쓰기

    "기능 구현에 쫓겨서 일단 구현만 해놓고 보자는 건데, 그 안에 있는 Defect 에 대한 검증이 이루어지지 않은 폭탄 코드를 양산해 내는 거지요."
    <-- 이게 너무 당연해서 나중에 힘든 거지요. 일반적인 개발자에게는 너무 익숙한 태도입니다. 등산을 하면서 나무에 리본을 달아주는 여유, 그 정도만 있어도 좋을텐데 말입니다.

  4. 안모대리 2009.03.10 15:47  댓글주소  수정/삭제  댓글쓰기

    사실 개발자들은 예전부터 그런 방법론을 써오고 있는 거 같습니다. 자기 중심의 Test-Driven 개발요. 전체적인 관점에서 작고 주기적인 Release식의 방법은 유용할 것 같습니다. 대형 프로젝트에서 어떻게 관리되냐가 관건이겠지만요. 조만간 몇가지 조언을 들을 일이 생길수도 있겠다는 생각이 드네요. 오랜만에 뵙고 싶기도 하고요.~~ 그럼 계속 좋은 글 기대하겠슴다.

    • 조대협 2009.03.11 11:55 신고  댓글주소  수정/삭제

      불러만 주신다면 저야 감사하지요...
      어떤 프로젝트 준비하고 계신지도 궁금하구요.
      한번 초대해주세요..
      이야기 같이 나누면 좋겠습니다.

ALM / Polarion Review

ALM/Task Management | 2009. 2. 20. 19:05 | Posted by 조대협
ALM에 대해서 정리하다가 오늘은 Polarion (http://www.polarion.com) 을 직접 인스톨해서 Evaluate해보았습니다.
Polarion이 개념상으로도 만족 스럽고 무엇보다 AJAX기반의 깔끔한 UI가 마음에 들어서 비싼 가격에도 불구하고 미련이 남아서 다시 테스트를 해보았습니다.

Polarion ALM은 Enterprise Version으로 많은 기능을 제공하고 자체적으로 CMMI Level까지 충족시키는 프로세스를 포함한다고 해서 복잡도가 높고 속도가 느린 것으로 알려져있습니다. 그리고 가격도 만만하지 않구요.
오늘 테스트 한 버전은 Polarion Track + Wiki 라는 버전으로 일종의 Light 버전으로 생각하면 됩니다.

테스트해보고 딱 드는 생각은 Trac의 Commercial Version이다. 입니다.

1. 가격
25 User를 기준으로 1250$ 입니다. 가격은 만만합니다.

2. 구성
Issue Tracking + Wiki + Subversion + 간단한 CI 입니다.

3. 장점
일단 UI가 미려하고, 쉬운 인스톨에 인스톨만 끝나면 Trac과 마찬가지로 All in on package이기 때문에, 처음에 진입하기가 수월합니다.
그리고 하나의 UI내에서 모든 인터페이스를 제공하기 때문에, Seamless integration이 이미 구현되어 있습니다.
Eclipse Plugin 을 제공하고 또한 Java platform만 아니라 make나 다른 빌드 스크립트를 제공하기 때문에, 플랫폼에 종속성이 낮습니다.
또한 JIRA와 마찬가지로 Workflow에 대한 정의가 가능합니다. 이건 꼭 필요하고 강력한 기능입니다.
멀티 프로젝트를 지원하는 것도 장점중의 하나라고 할 수 있겠습니다.
무엇보다 Task간의 Hierachy 정의가 가능하고 이를 리스트에서 트리형태로 보여주는 것은 아주 장점중의 하나입니다.

4. 단점
Issue Tracking의 경우, Iteration이나 Release Plan에 대한 개념이 없어서, Short release (개발 프로세스를 작은 단위로 쪼개서 프로젝트를 진행하는 개념, Scrum의 Sprint를 생각하면 됩니다.) 이게 약간 걸리기는 하지만 Time point라는 개념으로 충분히 커버라 가능합니다..
또한 Wiki의 경우는 어느정도 기능을 가지고는 있지만, Confluence Wiki에 비하면 많이 떨어지는 것은 사실입니다. Confluence Wiki의 경우 Export나 MS-WORD 기능이 강력하기 때문에, 문서를 밖으로 Export하여 산출물로 활용할 수 도 있는데,  Polarion도 Wiki에 PDF Export기능이 있기는 하지만, Confluence 대비해서 얼마나 경쟁이될지는 미지수 입니다.
CI 부분을 살펴보면, 역시 Hudson에 익숙해져 있는 저로써는 눈에 거슬리는 부분이 많습니다. Hudson의 강력한 플러그인으로 여러 리포트를 만들어낼 수 있는데 반해서, Triggering으로 Build를 돌려주고 결과를 로깅하는 정도입니다.
 그러나 빌드 #와 Task를 연결 시켜주는 기능은 마음에 드는 군요.

5. 총평
말 그대로 Trac의 Commercial Version이라고 보시면 될것 같습니다.
쉬운 인스톨과 통합된 환경, 미려한 UI, 낮은 가격으로 ALM의 성숙도를 아주 높게 끌고 가지 않을 것이라면 손쉽게 선택할 수 있는 대중적인 솔루션이 아닌가 싶습니다. 조금 더 유연한 환경을 원하는 사람들을 위해서라면 글쎄요.. 그 부분에 대해서는 의문이 듭니다만, 충분히 추천해볼만 한 솔루션이라고 봅니다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


Adapting JIRA For Scrum
Scrum을 JIRA로 구현하는 방법인데, 간단하지만 실용적인 가이드 입니다. 확장 여지는 있지만 기본 방향은 권장할만 합니다. 참고하세요.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ALM, JIRA, Scrum

댓글을 달아 주세요

  1. 2009.08.06 10:56  댓글주소  수정/삭제  댓글쓰기

    그린하퍼도 괜찮아요~^^

재미있는 ALM 도구 발견

ALM | 2009. 2. 20. 14:53 | Posted by 조대협
http://www.inflectra.com/HomePage.aspx 에서 제공하는 SpiraTeam이라는 시스템이다.
가격도 매우 저렴하고
무엇보다 마음에 드는것이, Requirement 부터 Test case까지 End2End 추적이 가능하도록 되어 있고
Release 관리와, Iteration 관리.. 그리고 Requirement와 Task에 대한 추적성까지 깔끔하게 제공한다는 것이다.
UI는 다른 툴에 비해서 다소 떨어지는 것 같지만 개념적으로 매우 마음에 드는 도구이다.
Report도 Velocity나 기타 왠만한 Reporting도 다 제공하고, Defect(Bug) Tracking 시스템도 내장되어 있고 또는 JIRA나 Bugzilla와 같은 외부 Bug tracking 시스템과 연계 가능한 플러그인도 가지고 있다.

단 빌드나 고수준의 테스팅에 대한 연계성은 다소 떨어지기 때문에, (Code Inspection이나 Coverage등) 이 부분은 별도의 커버가 필요할듯하다.

아래는 Dashboard에 대한 스크린샷

'ALM' 카테고리의 다른 글

Trac  (2) 2009.04.09
ALM Overview PPT  (10) 2009.03.16
재미있는 ALM 도구 발견  (0) 2009.02.20
실용주의 ALM (Application Lifecycle Management) Overview - PDF  (0) 2009.02.18
실용주의 ALM (Application Lifecycle Management) Overview  (3) 2009.02.18
오랜만에 ALM 업데이트  (0) 2009.02.17
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

실용주의 ALM (Application Lifecycle Management) Overview - PDF

ALM | 2009. 2. 18. 17:48 | Posted by 조대협
PDF 버전입니다.
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

실용주의 ALM (Application Lifecycle Management) Overview

ALM | 2009. 2. 18. 17:35 | Posted by 조대협

 

Practical Application Life cycle Management (ALM)

 Overview

ALM의 정의를 wikipedia에서 찾아보면 다음과 같다.

Application lifecycle management (ALM) is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.[1]

 

해석해 보자면, 기존의 애플리케이션 개발은 기술적인 관점에서 많이 접근이 되어 왔으나, 비즈니스 요건 관리 부분과 실제 소프트웨어 개발 프로세스를 융합하고 이에 대한 관리를 자동화된 툴을 이용하도록 하는 것이 ALM의 개념이며, 이 부분에는 요구 사항 관리, 아키텍쳐, 코딩, 테스팅, 그리고 이슈 추적과 릴리즈 관리등을 포함한다. 

한마디로 이야기 하면 비즈니스와 실제 소프트웨어 개발간의 괴리를 없애고, 소프트웨어 개발의 요구사항 분석에서부터 릴리즈까지의 모든 과정을 툴을 도입함으로써 관리하겠다는 개념이다. 

기존에 소프트웨어 개발 프로세스는 요구 사항 관리에 대한 문서나 시스템, 아키텍쳐나 디자인에 대한 Case tool과 산출물, 코드 관리, 일정 관리 등등이 각기 다른 제품과 다른 프로세스 다른 템플릿으로 구현이 되어 왔고 이로 인해서 소프트웨어 개발 과정에 대한 개념이 실제로 구현되었을때는 단계별로 추적성과 실용성이 떨어졌다.

ALM의 의미는 이런 현실과 괴리된 부분을 좀더 통합되고 현실적으로 전문화된 도구를 이용하여 현실화 시키고 궁극적으로 소프트웨어 개발 프로세스를 개선하는데 목적을 두고 있다고 말할 수 있다. 

ALM이 실제 커버하는 범위를 보면 아래 그림과 같이 요구사항 관리에서부터 프로젝트 관리, 릴리즈 관리까지 소프트웨어 개발의 거의 전 영역을 커버하는 것을 볼 수 있다.


(위키피디아 ALM Concepnt 그림 인용 : http://en.wikipedia.org/wiki/Application_lifecycle_management)

 

요즘 들어서 많은 업체들이 이 ALM이라는 개념을 사용하고 있다. H*의 경우 버그 추적 시스템을 기반으로 이슈 관리, 테스트 자동화 도구를 가지고 ALM이라고 이야기 하고 있으며 Mc* 라는 업체의 경우 테스팅 툴 하나만을 가지고 ALM 업체라고 이야기 하고 있다. 

ALM이 가져야 할 최소한의 요건은

요구 사항 관리, 프로젝트 스케쥴 관리를 위한 Task 관리, 빌드 환경 자동화 및 형상 관리, 테스트 자동화 부분이 핵심이다.

그외에 Deployment의 경우 주로 운영 (SM : System Management) 조직이 담당하며, Design이나 아키텍쳐링의 경우 ALM 사상내에 포함되는 것이 이론적으로는 맞지만, 사실 Design의 경우 프로세스를 정형화 시키기 어려울뿐더러, 실제 프로젝트에서는 Design이 프로젝트가 진행되어감에 따라 변화하고 완성되어 가기 때문에,  Design을 포함시키는 것은 쉽지 않다.

사람들은 프로젝트를 하면서 똑똑해지고 시스템은 프로젝트 진행됨에 따라 명확해 진다. Agile 사상에서도 Design은 선행 작업이 아니라, 주로 프로젝트 진행과 같이 가는 On going 작업으로 정의하고 있다. Design을 ALM의 구현체 내에 포함시키기 위해서는 말단 개발자까지 상당 수준의 성숙도가 필요하다. 

문제점

ALM의 사상적인 출발은 툴을 이용한 소프트웨어 개발 사이클의 현실화인데, 시장에 있는 툴의 경우 그 성숙도가 매우 높아서 프로젝트에 적용하는데 상당한 경험과 지식을 필요로 한다. 실용적인면에서 생각했을 때 ALM의 적용 범위는 일반 말단 개발자 수준에 까지 적용이 되어야 하기 때문에 난이도가 높을때는 실제 프로젝트에 적용하기가 어려운 점이 많다.

또한 ALM Company를 자칭 하는 많은 회사들이 ALM에 대한 Full set을 가지고 있지 않은 상태에서 마케팅적인 메시지로 Drive 하는 경우가 많아서 사용자의 혼란을 초래하고 있다. 

그리고 무엇보다 중요한 것은 ALM을 시스템으로 구축하기 위한 제품이 아니라 ALM을 조직에 적용하기 위한 프로세스와 방법론 즉, 컨설팅과 같은 인적 지원면인데, 적어도 국내의 벤더들에서는 실용적으로 ALM을 프로젝트에 적용할 수 있는 업체가 있는지는 의문이다. 

실용주의 ALM

실용주의 ALM은 이런 문제점을 바탕으로 좀더 실용적이고 실무적인 ALM을 개발하여 실무에 사용하고자 하는데 목적을 두고 있으며 아래와 같은 특징을 갖는다.

l        주로 오픈소스나 저비용의 제품을 조합하여 ALM의 핵심 범위를 커버한다.
l        Agile과 Kent Beck, Erich Gamma, Joel Spolsky 등에 의해서 주장되고 있는 실용주의 방법론 (Practical methodology)를 바탕으로 하여, 튼튼한 이론적인 바탕을 가지고 현실에 맞는 실용적인 프로세스를 구축한다.
l        구현팀을 위주로 프로세스를 정의한다.
l        품질 향상 

End to end use case (시나리오)

이해를 돕고자 이제부터 소개하고자 하는 실용주의 ALM 프레임웍의 가상 시나리오를 살펴보도록 하자


개발자 시나리오
1)       개발자 D씨는 아침에 출근해서 이클립스 IDE를 오픈한다.
2)       이클립스 IDE는 이슈추적툴로 부터 D씨에게 할당된 작업들이 리스트업되고, 그중에서 오늘해야 할 작업을 선택하여 PROGRESS로 상태를 변경한다.
3)       SCM으로 부터 최신 코드를 UPDATE받고 코딩을 시작한다.
4)       코드를 만들고 테스트 케이스를 작성하여 코드가 제대로 작동함을 확인하고, 커버러지 분석을 통해서 금일 코딩한 내용이 테스트에서 모두 확인 되었는지 체크한다.
5)       오늘 코딩한 내용을 INSPECTION툴을 통해서 잠재적인 문제가 있는지 없는지 검증 받고 NAMING RULE등이 문제 없는지 확인한다.
6)       완료된 내용을 SCM에 작업 번호와 함께 COMMIT한다.
7)       자동 빌드 머신에서 COMMIT된 소스코드를 감지하고 모든 소스를 내려받아서 빌드를 완료한후에 개발 서버에 자동으로 배포하고 테스트를 수행한다.
8)       테스트가 실패한 경우 이전 버전으로 개발 서버를 원복 시키고 모든 개발원과 PM에게 이메일로 테스트 실패 사실을 통보한다.
9)       PM은 테스트 실패사실을 이메일로 통지 받고, 이번 빌드에서 변경된 부분을 빌드 자동화 시스템을 통해서 확인하고 빌드 자동화 시스템에 의해서 리포트된 내용에 따라 누가 어느 모듈을 수정했는지를 찾아서 해당 개발자에게 수정을 지시한다.
10)   개발자는 수정을 마친후에 다시 SCM에 소스를 반영하고 빌드 자동화 시스템은 빌드,테스트,커버러지 분석,코드 복잡도 분석,INSPECTION작업을 수행한다.
11)   PM은 빌드가 완료된 결과를 통보 받고, 복잡도가 높은 클래스 모듈 10개에 대해서 제대로 테스트가 커버하는지 확인하후에 미비한 부분에 대해서 담당 개발자에게 테스트 보강을 지시한다. 

PM의 작업지시 시나리오
1)       PM P씨는 아침에 출근하여 고객으로 부터 새로운 요건을 받았다.
2)       P씨는 요건을 정리하여 내용을 이슈 트랙킹 시스템에 등록하고 심각도와 우선 순위를 지정해서 개발 PL에게 ASSIGN하였다.
3)       개발 PL은 요건의 우선 순위와 긴급도를 보고 누구에게 작업을 지정할것인지 고민한다. 이슈 트랙킹 시스템에서 개발원별로 진행중인 이슈 사항을 보고 개발 난이도에 맞는 사람중에서 가장 할당된 이슈가 적은 사람에게 이슈를 ASSIGN하였다.
4)       개발자는 해당 ISSUE를 받아서 처리한 후 PL에게 다시 ASSIGN한다.
5)       이때 작업에 관련된 메일,전화 통화내용 기타 관련 내용들을 시스템에 모두 LOGGING한다.
6)       PL은 작업이 완료된 내용을 검토한후 해당 ISSUE를 CLOSE한다.
7)       PM은 자신이 지시한 내용에 대해서 누가 진행하고 있으며 진행현황이 어떻게 되었는지를 이슈를 통해서 추적할 수 있다.

PM의 현황 관리 시나리오

1)       PM P씨는 1차 오픈 때까지 해결되어야 할 이슈를 이슈 관리 시스템에서 검색한다.
2)       심각도가 높은 이슈와 오픈된지 오래된 이슈를 확인하여 진행이 안되고 있는 이유는 무엇인지 RISK는 무엇인지를 조사하고, RISK에 대한 대비책을 세운다.

만약에 날짜에 비해서 해결되어야 할 이슈가 많을 경우 심각도와 우선순위를 고려하여 2차 오픈으로 이슈를 연기한다.

실용주의 ALM 구성

실용주의 ALM은 크게 4가지 모듈로 구성된다.


Task Management (Task 기반의 프로젝트 관리)

프로젝트에서 진행되는 작업에 대한 진행 상황과 스케쥴링 그리고 리소스에 대한 관리 방법론을 제공한다. 기본적인 사상은 Agile 방법론의 프로젝트 관리 방안을 기반으로 하고 있다.Task Management 모듈은 다음과 같은 서브 모듈을 포함하고 있다  

Process
1)       Task Management Process : Agile Scrum 기반의 Task 관리 프로세스
2)       SOA or Open API Service Lifecycle Management Process (Optional) : SOA나 WEB 2.0에서 Service Lifecycle (서비스 신청에서부터 배포 까지) 관리 프로세스와 시스템
3)       Requirement Analysis Process (TBD) : 요구 사항 추출 프로세스

Reference Architecture
1)       Task Management System Reference Architecture  : 프로세스를 구현한 Task 관리 시스템
2)       Task Management Dash board Reference Architecture : 프로젝트의 진행 상태를 한눈에 알 수 있는 Dash board
3)       Requirement Analysis Management Reference Architecture (TBD) 요구 사항 관리 시스템

Build Environment (빌드 환경)

Implementation 단계에서 사용되는 개발환경을 제공한다. 기본적인 사상은 Pragmatic(실용주의) 방법론으로 Kent beck이나 Joel Spolsky에 의해서 소개된 방법론을 기초로 하며, 일일 빌드와 점진적/반복적 통합론을 중심으로 개발환경 구성에 대한 가이드를 제공한다.

다음과 같은 서브 모듈을 포함하고 있다

Process
1)       SCM branch guide : 소스 형상 관리에 대한 브렌치 관리 전략
소스 코드 관리에 있어서 브렌치에 대한 관리 방법을 기술한다. 브렌치는 잘못쓰면 전체 소스코드 관리를 하는데 있어서 엄청난 혼란을 초래할 수 있는 만큼 적절한 브렌치 관리 정책이 정해져야 한다.

2)       Contiguous Integration Process : 점진적 통합 방법에 대한 프로세스
자동 빌드 시스템을 구축하여, 개발자의 소스 코드 변화를 자동으로 인지하고 매일 자동 빌드를 통해서 코드의 통합을 빅뱅 방식이 아니라 매일 점진적인 방식으로 진행함으로써 통합으로 인해 발생할 수 있는 문제를 조기에 발견하고 해결할 수 있도록 하며, 빌드 과정내에 테스팅을 포함시켜서 결함을 조기에 발견하여 전체 소프트웨어 품질 향상을 유도 한다.

Reference Architecture
1)       Standard IDE : 개발자를 위한 표준 개발 환경 가이드
프로젝트에서 개발자별로 선호하는 개발 도구들이 다르다. (이클립스, NetBeans, VI 등) 다른 개발 도구는 구현된 코드에도 영향을 주며, 특히 새로운 팀원이 합류했을 때 보통 1~2일을 개발환경을 셋업 하는데 시간을 소요 하게 된다. 표준 개발 환경은 ZIP으로 개발에 필요한 모든 환경을 만들어서 개발자가 ZIP 파일만 풀면, IDE에서 테스트 프레임웍, 테스트용 서버 환경까지 일괄로 셋업이 되서 모든 개발자가 빠른 시간내에 동일한 개발환경에서 소프트웨어를 구현할 수 있도록 한다.

2)      Contiguous Integration Reference Architecture
실제 CI 환경을 구축하는데 필요한 아키텍쳐에 대해서 설명한다.

3)       Standard Build Script : 표준 빌드 스크립트 구축 가이드

표준 개발환경과 마찬가지로 빌드 스크립트 역시 표준화 되어야 한다. LIB 위치나 버전, 빌드 스크립트내의 TARGET 정의, 빌드 순서등을 통합하고 표준화된 형태로 제공하여 개발자가 빌드 스크립트 작성에 소요되는 시간을 절약하고, 비표준화된 빌드스크립트 사용에서 오는 오류를 예방한다. 

Test Automation (테스트 자동화)

일반적으로 테스팅은 QA팀의 역할로 인식이 되어 왔고, 시스템 개발이 완료된 후에 QA팀에 의해서 테스팅이 되는 것이 일반적이었다.

 여기서는 소프트웨어 개발중에 개발팀에 의해서 수행되는 단위 테스트와 통합테스트에도 비중을 두고, 테스트 자동화와 회귀 테스트(테스트 마다 지난번 테스트했던 내용을 포함하여 테스트 하여, 변경 사항이 기존 기능에 영향을 줬는지 여부를 검증함)를 중점적으로 다룬다.

테스팅 모델은 전통적은 Waterfall 방식을 확장한 V-Model을 기반으로 한다.

Process
1)       Testing Process (테스트 프로세스)
소프트웨어 개발 단계에서 부터의 단계별 테스팅 프로세스에 대해서 정의한다.
V-Model에 기초하여 Unit Test,Integration Test, System Test, User Acceptance Test 4단계로 나누어서 정의한다.

2)       Defect Management Process (결함 관리 프로세스)
테스트 결과 발견되는 결함에 대한 관리 프로세스를 정의한다.

Reference Architecture
1)      Unit Test Framework Reference Architecture
특히 단위 테스트의 경우 소프트웨어의 안쪽을 테스트 하기 때문에, 일반적인 테스팅 도구보다는 소프트웨어 컴포넌트에 따라 더 정밀한 테스팅 도구가 필요하다.
단위 테스트를 수행하는데 필요한 테스팅 프레임웍에 대해 정리한다

2)      Static Testing Reference Architecture
소프트웨어 테스팅 기법중에서, 소프트웨어의 동작 상태가 아니라 코드 검증을 통해서 결함을 찾아내는 방법을 Static Test라고 한다. 이 테스트에서는 코드의 Naming Convention이나 특정 패턴에 따른 잠재적인 결함 (메모리 누수, Null Pointer Exception)을 찾아낼 수 있다. 이 Static Test를 수행할 수 있는 도구에 대해서 설명한다.

3)      System Test Reference Architecture
테스팅 중에서 주로 성능과 비기능 (확장성, 가용성등)에 대한 테스팅 수행 도구에 대해서 설명한다.

Collaboration (협업)

협업 모듈은 팀이 프로젝트를 진행하는데 있어서 의사 소통과 공동 작업을 돕기 위한 몇가지 기법과 시스템에 대해서 소개한다.

Process
1)      Code Review
코드 리뷰는 실제로 코드를 검토하여 예측 되는 결함을 찾아내고 서로 개선 방향을 찾아내는 행위이다. 코드 리뷰의 방식은 여러가지가 있으나 비형식적인 코드리뷰라도 투자대비 소프트웨어 품질에 많은 효과를 줄 수 있기 때문에, 협업의 기법중의 하나로 소개한다. 

Reference Architecture

1)      Wiki Based Document Management Reference Architecture
ALM을 이용해 구축된 표준이나 프레임웍, 프로세스등 많은 내용들이 Architect 레벨에서 일반 개발자들에게 전달되어야 한다. 이런 지식을 전달하는 방법이 문서등 여러가지 방법이 있겠지만, 문서등은 여러 버전 관리나 변경 관리가 어렵고, 표현의 한계가 있다.
 Wiki의 경우 내용을 하나의 장소에서 계속 업데이트가 가능하고, 검색이 가능하며, TEXT와 이미지뿐만 아니라 멀티미디어 데이터를 넣을 수 있기 때문에 직관적인 정보 전달이 가능하다.
 또한 링크를 이용하여 정보간의 연관 관계를 정의할 수 있다.

MS-WORD등으로 만들어진 문서는 공유 폴더에서 사장되거나 또는 이쁘게 바인딩되어서 책장이라는 무덤속으로 사라질 수 있는데, Wiki를 이용하는 이유중의 하나는 꼭 필요한 문서만, 필요할때 사용할 수 있도록 하여, 프로젝트에서의 정보 공유를 가속화 하는데 그 목적이 있다.

2)      Communication with Forum Reference Architecture
Wiki의 경우 대부분 위의 조직에서 아래 조직으로의 하향성을 가진 단방향 커뮤니케이션이다. 이를 보안하기 위해서 Forum은 좋은 양방향 커뮤니케이션 도구로 사용될 수 있는데, Wiki를 통한 단방향 정보 전달의 Feedback으로 사용할 수 있다. 

이러한 협업 도구들은 전체 협업의 생산성을 높혀줄 수 있는 일부만을 권장하는 것이며 조직의 수준과 구조에 맞춰서 별도의 협업 프레임웍을 구축 하기를 권장한다

실용주의 ALM 의 구현

ALM을 프로젝트에 적용 하기 위해서는 아래와 같이 3가지 관점에서의 접근이 필요하다.


프로세스

ALM은 전체 소프트웨어 개발 프로세스를 커버하기 때문에, 각 모듈을 프로젝트에 적용되는 프로세스에 대한 정의가 필요하다.

Reference Architecture

프로세스를 실제로 시스템으로 구현하기 위해서, 어떤 형태의 시스템 아키텍쳐를 이용하여 프로세스를 현실화할 수 있는지에 대한 가이드를 제공한다.

조직

시스템과 프로세스를 가지고 프로젝트에 적용할때, 적용하는 주체의 역할과 책임에 대해서 정의한다. 

성공적인 ALM 구현 전략

간략하게 실용주의 ALM에 대해서 살펴보았다. 이 실용주의 ALM을 성공적으로 적용하기 위해서 몇 가지 전략이 필요한데, 다음과 같다.

1)      Liquid

전체 프로세스가 모난 부분이 없이 물 흐르듯이 하나의 프로세스로 연결되어야 한다.

프로세스가 넘어가는 단계가 매끄럽지 못하면 전체 개발 프로세스에 병목이 생기게 되고, 프로세스 흐름에 문제가 생긴다.

2)      Seamless

앞에서 소개한 실용주의 ALM의 모듈 구성을 보면 알겠지만, 상당히 많은 부분을 많은 기술로 커버하고 있다. 이러한 기술들이 유기적으로 결합되어 마치 하나의 통일된 프레임웍과 같은 형태를 취하여 사용자 입장에서 하나의 프레임웍을 쓰는 듯한 느낌을 줘서, 사용자 관점에서 올 수 있는 혼돈을 미연에 방지해야 한다.

3)      Process Oriented

ALM의 가장 중요한 요소는 프로세스이다. ALM은 소프트웨어 개발 프로세스를 시스템화 하는 것이기 때문에, 프로세스 자체가 중요하며 자칫 잘못하면 시스템 구현에 이끌려서 프로세스가 망가지는 경우가 있다.

4)      Step by Step

실용주의 ALM이 다른 ALM에 비해서 경량이고 현실적이라고는 하지만, 커버하는 영역이 상당히 넓다. 한번에 전체 개발 프로세스를 변경하는 것은 구성원들에게 큰 혼란을 초래할 수 있기 때문에, 난이도별로 단계적으로 적용하는 것을 권장한다.

5)      팀의 수준에 맞춰서

팀의 성숙도에 맞춰서 실용주의 ALM을 Customization해서 적용해야 한다. 성숙도가 낮은 팀에 실용주의 ALM을 적용할 경우, 마치 기존의 중량의 방법론을 적용할때와 마찬가지로 형식 지키기에만 급급해지고 실제 생산성은 오히려 더 떨어질 수 도 있다.

6)      Be Simple

모든 기능을 커버하려 하지 말고, 목표가 100일때 80만 커버하더라도 단순성을 우선시해야 한다. 복잡도가 높아질 수 록 실용주의 ALM 사용으로의 진입장벽과 Learning Curve가 급격하게 올라가고 이는 또 다른 형식적인 방법론으로 전락할 수 있다.

 

 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 서영아빠 2009.03.05 09:00  댓글주소  수정/삭제  댓글쓰기

    매번 유용한 글 잘 보고 갑니다. ^^
    그리고 글 내용중에서 SCM branch guide에 대해서 좀 더 상세한 설명이나 포스팅을 부탁드려도 될까요? branch는 아무리 머릴 굴려봐도 항상 어렵네요. 사례같은 것도 찾기가 쉽지 않네요.

    # 빌드환경에서 Contiguous => continuous 오타났어요^^;;

    • 조대협 2009.03.05 09:58 신고  댓글주소  수정/삭제

      ^^: 안그래도 ALM Full Framework 을 PPT로 다시 정리하고 있는데, 이제 반 정도 했네요.. (다 만들면 대략 200장 정도의 자료가 될것 같은데요.) 요즘 Branch Guide 작성하고 있습니다.

      프로젝트를 들어와서 ALM을 업데이트할 시간이 많지 않은데요. Branch Guide 작성되는데로 빨리 올리도록 하겠습니다.

      의견 고맙습니다.

  2. 씨니 2010.05.05 02:42 신고  댓글주소  수정/삭제  댓글쓰기

    ALM에 대해 잘 정리된 글이네요. 퍼감다.
    (새로 이직하신 회사에서 잘 되셔서 고공비행 하시길 빕니다.)


Selenium이 UI Base 테스팅 툴로 널리 쓰이는 것은 기정 사실로 알고 있는 것이고,
대용량 부하 테스트를 할 경우, 환경 마련이 만만하지 않은데,
Amazon의 E2C 클라우드를 이용해서 Selenium으로 대규모 부하 테스트를 할 수 있는 사이트가 있어서 소개 합니다.
인데, Selenium 스크립트를 만든후에, 로드하면 Amazon 클라우드를 이용하여 부하테스트를 하고, 그 결과를 리포팅 합니다.

Load R*와 같은 툴을 사용할 수 없는 곳이나, 이미 Selenium으로 테스트 코드를 구현해 놓은 곳에서는 저비용으로 매우 유용하게 사용할 수 있겠네요.

'ALM > Test Automation' 카테고리의 다른 글

JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09
Cloud 컴퓨팅을 이용한 대용량 Selenium 테스트  (0) 2009.02.18
Selenium (UI 테스트 자동화)  (1) 2009.02.09
EasyMock을 이용한 단위 테스트  (5) 2008.11.07
테스트 자동화 도구들  (0) 2008.08.07
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요