조대협의 블로그

요즘 매일 대전으로 출퇴근을 하고 있습니다. 계약 관계가 복잡하게 얽혀서 근 3달정도 지연이 되어 버린 프로젝트입니다. 원래는 Project Manager와 Cheif Architect 역할로 계약이 되었지만, 구현일정 관계로 한 모듈의 설계와 구현을 모두 맏고 있습니다. 그러다 보니, 처음에는 ALM을 도입하여 SVN을 이용한 형상관리, WAS Configuration Management, Trac을 이용한 이슈 관리와 Wiki를 이용한 문서화를 진행하려고 계획을 했었습니다. 이번달이 아니라 3월경에 SOW(Scope Of Work )작업으로 일주일정도 진행한 적이 있었는데, 그때는 코딩할당량이 없어서 그나마 프로젝트 관리를 할 수 있었습니다만, 지금은 구현에 치여서 ALM적용을 하지 못하고 있습니다...

이번 프로젝트에 6번째로 ALM을 사용해보기로 결정하였습니다. SVN,WIKI,Issue Tracking이 모두 필요하고 설치할 시간도 없어서 Trac (Trac On Windows - 압축만 풀면 사용 가능하게 한 패키징)을 설치하여 사용하고 있습니다. 올인원 패키지이고 플러그인을 지원해서 좋긴하지만 JIRA의 파워풀한 기능을 경험한 저로써는 불편한점이 많더군요. (예를 들어서 조회 조건 같은 것을 Query로 직접 코딩해야 하는 불편함등.) 이번 프로젝트도 상당히 긴 프로젝트가 될것 같습니다. Trac 기반의 ALM을 시험해볼 좋은 기회가 되겠지요. Trac에 설치한것은 다음과 같습니다. - TOW (Trac On Windows) - Timingandestimation plug in - ScrumBu..

그간 정리해왔던 ALM에 대해서 전체 그림을 다시 한번 정리하였습니다. 컨버팅 과정에서 폰트가 깨져서 좀 보기가 어려울 수 있습니다. 별도로 자료가 필요하신분들은 요청하시면 보내드리도록 하겠습니다. ALM의 전체 Full Process와 어떤 제품으로 어떻게 구혀하는지, 그리고 구현 전략에 대해서 기술되어 있습니다. 감사합니다. ALM (Application Lifecycle Management) View more presentations from Byungwook.

언제 어떤 코드 리뷰 기법을 사용해야 하는가? 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까? 코드 인스펙션 코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다. 즉, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다. 필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다. 1차 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계..

들어가기에 앞서서. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데, 코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다. 코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다. 코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고..

요즘 모회사의 차세대 시스템의 오픈을 막바지에 두고, 성능 향상 컨설팅에 나와 있습니다. 주로 하는 작업이 Code Inspection을 통하여 구조 개선 및 성능 개선을 하는 작업입니다. 그런데, 코드를 보면서 이해가 안되는 아키텍쳐가 종종 있습니다. 이런 의도가 아닐텐데 라던지.. 아키텍쳐 구성이 잘못되었다던지. 그런데 이미 구현이 끝나가는 단계에서 이런 아키텍쳐를 변경하기는 거의 불가능합니다. 알면서도 당하는 케이스라고나 할까요? 이미 여러 코드들이 동일 패턴으로 구현이 되어 있기 때문에, 공통부라면 어떻게 변경을 시도해보겠지만, 아키텍쳐적인 문제나, 통신 전문 같은 경우는 변경이 불가능합니다. 결국 울며 겨자 먹기로 CPU를 늘리거나, 다른 부분의 코드를 튜닝해서 목표 성능치를 내야 겠지요. 그런..

ALM에 대해서 정리하다가 오늘은 Polarion (http://www.polarion.com) 을 직접 인스톨해서 Evaluate해보았습니다. Polarion이 개념상으로도 만족 스럽고 무엇보다 AJAX기반의 깔끔한 UI가 마음에 들어서 비싼 가격에도 불구하고 미련이 남아서 다시 테스트를 해보았습니다. Polarion ALM은 Enterprise Version으로 많은 기능을 제공하고 자체적으로 CMMI Level까지 충족시키는 프로세스를 포함한다고 해서 복잡도가 높고 속도가 느린 것으로 알려져있습니다. 그리고 가격도 만만하지 않구요. 오늘 테스트 한 버전은 Polarion Track + Wiki 라는 버전으로 일종의 Light 버전으로 생각하면 됩니다. 테스트해보고 딱 드는 생각은 Trac의 Comm..

Adapting JIRA For Scrum View more presentations from Paul rené Jørgensen. (tags: agile scrum) Scrum을 JIRA로 구현하는 방법인데, 간단하지만 실용적인 가이드 입니다. 확장 여지는 있지만 기본 방향은 권장할만 합니다. 참고하세요.

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 시스템과 연계 가능한..

PDF 버전입니다.