ALM Concept

제 블로그에 자주 오시는 분들이나 혹은 강연이나 기고를 보신분들은 아시겠지만
2008년 한해는 ALM (Application Lifecycle Management)쪽에 많은 시간을 할애한 한 해였습니다.
CI(Contiguous Integration), Unit Test,실용주의 방법론이 유행한 한해이기 때문에, 유난히 관련 서적을 많이 접했던 이유도 있지만 컨설턴트로써 프로젝트 관리와 소프트웨어 품질 관리에 대한 필요성이 많았기에 많은 시간을 부었습니다.

ALM에 대해서 시간이 나는데로 좀더 정리를 해보고자 합니다.

제가 이야기 하는 ALM은 기존의 어떤 방법론이나 사상은 아닙니다. 프로젝트를 하면서 필요하다고 생각되는 부분을 묶어서 정리한 하나의 간단한 방법론 정도로 생각하면 됩니다.
ALM은 크게 3가지 모듈로 구성됩니다.

프로젝트 관리와, 빌드 환경 그리고 테스트 환경입니다.
프로젝트 관리는 JIRA와 같은 이슈 트랙킹 시스템으로 프로젝트에서 발생되는 모든 작업을 기술하고 리소스와 시간(개발자와 스케쥴)을 관리하는 방법을 기술합니다. 특히 각 이슈간의 연관 관계를 기술함으로써 추적성을 부여하는 것인데 예를 들어 고객의 요건이나 시나리오가 실제 코드까지 어떻게 반영되는지에 대한 추적성을 부여합니다. 지금까지 (K*,하*,소*,S*)등 약 4개 사이트에 프로젝트를 하면서 적용을 해봤고 장단점과 문제점에 대해서 보강을 하면서 성숙 시켜온 방법입니다.

빌드 환경은 개발자 IDE와 특히 지속적 통합(CI)를 통하여 빅뱅식 통합에서 오는 문제를 없애고 좀더 Agile한 접근방법으로 개발환경을 셋업할 수 있는 방법에 대해서 가이드 하고 있습니다. 이 내용 안에는 빌드 스크립트에 대한 작성 방법, 개발자의 표준 개발환경 구성 방법 및 Subversion과 같은 SCM도구를 이용한 Configuration management와 branch 관리 전략에 대해서 기술합니다.

마지막으로 Test Automation은 단위 테스트 자동화뿐만 아니라, V-Model에 기초한, 단위테스트,통합테스트,시스템 테스트,사용자 인수 테스트에 대해서 폭넓게 이야기 하고 있으며, 실제 구현 방법 및 전략에 대해서 기술하고 있습니다. 특히 테스트가 시스템의 품질을 검증하는 것이라면, 커버러지 분석 기법과, 코드 복잡도 분석기법, Risk 기반 테스팅 방법 이론을 기반으로 테스트 자체의 품질을 검증하는 방법을 기술합니다.

앞으로는 협업에 대한 부분을 추가해볼 예정입니다. 위의 방법론이 시스템을 통하여 최소한의 품질 수준을 끌어올리는 것이라면, 의사 소통과 협업을 통해서 최대한의 품질 수준을 올리는 방법에 대해서 추가할 예정입니다. Wiki나 Forum을 이용한 시스템 그리고 팀내의 의사 소통 방법과, 페어 프로그래밍, 코드 리뷰 방법에 대해서 기술해볼 예정입니다. 금년에 코드리뷰냐 위키 사용은 몇몇 프로젝트에서 진행해봤지만 시스템이 아니라 사람과 해야 하는 일이기 때문에 더욱 어려운것 같습니다.

Collaboration (협업)