'마이크로소프트; Microsoft; 개발자; PLC;'에 해당되는 글 2건

  1. 2009.02.25 1.2 품질 프로세스
  2. 2009.02.23 1.1 소프트웨어 프로세스 모델 (2)

QG(Quality Gate) 우리말로 의역을 하면, “품질통과기준으로 이해 할 수 있을 것 같다. 위키백과에서는 다음과 같이 정의하고 있다.

QG(Quality Gate)

간단히 이야기 하면, 검수관이 출구에 서서 제품을 살펴보고 이 제품 또는 기능이 출구를 통과해도 될지 안될지를 결정하는 과정이다.

 

모든 개발자는 당연히 좋은 품질의 소프트웨어를 만들기 위해 노력한다. 말은 참 쉬운데, 왜 쉽지 않을까?

여기에 고려해야 할 네 가지 주요 요소가 있다.

 

Feature – Quality – Time – Resource(사람과 비용)

 

피처를 잘 구현하기 위해서는 많은 시간과 자원을 투입하면 된다. (많은 시간과 자원을 투입한다고 항상 좋은 결과가 나오는 건 아닌 것 같지만J)

그렇지만, 기업은 항상 시간과 자원이 부족하다. 결국 전체 제품에서도 가치(Value)에 따라 우선순위를 정하고 자원을 배분 할 것이다.

 

예전 제 매니저분과 이야기 중 자신에게 자원(비용과 사람)이 풍부하다면, 난 이 일을 당신에게 맡길 이유가 있을까? 라고 질문을 하셨다. 사람과 자원이 풍부하면, 당연히 모든 주도권을 기업이 가지게 될 것이다. 결국 자원이 너무 풍부한 상황은 개발자 자신에게도 그렇게 유리한 상황은 아니다. (부족해도 문제, 많아도 문제 J)

품질과 자원은 항상 트레이드 오프가 생기게 되어 있다. 결국 조절을 해야만 한다.

(이러한 조정은 보통 와이드밴드 델파이(Wideband Delphi) 기법을 많이 사용한다. 와이드밴드 델파이 기법은 향 후 꼭 다루게 될 것이다. 그때 자세히 이야기 하도록 하겠다.

품질 프로세스와 보안 프로세스는 절 때 개발 프로세스와 떨어져서 진행하면 안 된다. 항상 함께 고려해서 함께 진행을 해야 한다.

 

자 이제 QG를 통과하기 위한 항목으로 소프트웨어 개발에서는 어떤 것을 보는지 살펴보자.

 

1.      높은 수준의 경고를 사용해 컴파일

2.      정적 분석 도구를 이용한 코드 분석

3.      모든 코드에 대한 유닛 테스트

4.      코드 커버리지 비율

5.      모든 코드에 대한 리뷰

 

여기서 소스와 개발은 닷넷위주로 이야기 하도록 하겠다.

경고는 항상 버그라고 생각해서, 되도록 방어적 프로그램을 할 필요가 있다. 사실 매뉴얼 하게 하면, 일이 참 많은 부분인데 Visual Studio를 사용하면, 쉽게 적용이 가능한 부분이다.

 

정적 분석 도구를 이용하는 부분이 QG에서 상당히 비중이 높다.

 

소스 코드를 가이드에 맞게 작성을 했는지 그 규칙을 지정한다. 소스 코드의 스타일 지침은 소스 코드의 형식을 지정하는 방법에 대한 규칙이며, 들여쓰기나 순환문의 형식 등 아주 자세한 코딩 룰을 지정 할 수 있다. 이런 소스 코드에 대한 규칙은 StyleCop 이라는 툴을 많이 이용한다.

자세한 방법은 아래 사이트나 검색을 통해 관련 자료들을 찾을 수 있다. 저는 향 후 이 내용에 대해서도 아주 심도 있게 다룰 것이다.

StyleCop 사이트


그 다음이 소스 코드 보다는 좀 더 나아가 어셈블리 중간코드를 분석해줄 필요가 있다.

FxCop 이라는 툴을 사용해 컴파일된 .NET 어셈블리의 중간 코드를 분석하고 디자인, 보안 및 성능 개선을 위한 기능을 제공한다.

이 기능은 제가 아주 좋아하는 기능이라 뒤에서 아주 자세히 다루도록 하겠다.

FxCop 사이트

C/C++Prefast를 사용할 수 있다.

Visual Studio Team System을 사용한다면, 통합되어 있는 Code Analysis를 사용하는 것이 가장 편할 것이다.

 

다음은 분석된 결과를 기반으로 각 코드에 대한 Unit 테스트를 모두 실행해야 한다. 유닛 테스트가 TDD에서도 가장 비중 있게 논의되는 부분이다.

닷넷에서 가장 많이 사용하는 툴은 NUnit 이다. NUnit은 닷넷 기반의 단위 테스트 프레임워크(Unit-testing framework)이다. Visual Studio Team System Unit 테스트 프레임워크를 사용할 수도 있다.

이것 또한 제가 아주 좋아하는 툴로 단지 사용법뿐만 아니라 단위 테스트에 대해서는 아예 다른 코너를 만들어서 다룰까 한다.

NUnit 사이트

 

이외에도 좋은 단위 테스트 툴이 많이 있다.

csUnit, mbUnit, xUnit.net 등이 있는데, 그 중 최근 개발된 xUnit이 눈에 뛴다. xUnit의 개발자 중 한명인 James Newkirk NUnit 개발에도 참여한 사람으로 다년간의 노하우로 xUnit을 개발했다고 한다. 기대가 되는 툴이 될 것 같다.

xUnit 사이트

 

마지막으로 닷넷에서의 단위 테스팅 프레임웍크와 TDD를 하기 위해 꼭 참고할 사이트가 바로 테스트 드리븐 닷넷이 있다.

테스트 드리븐 닷넷

 

다음 과정은 코드 커버리지를 통해 테스트가 코드를 얼마나 잘 테스트하는지를 측정하는 방법이다. 테스트의 목적은 무조건 많은 코드를 테스트 하는 것이 목적이 아니라 소프트웨어의 품질을 향상시키는데 있다면, 코드 커버리지의 목적은 테스트의 품질을 향상시키는데 있다. 그 비율을 통해 신뢰의 정도를 결정 할 수 있을 것이다. 보통 70~80%로 결정 하는 것 같다. 이건 상황에 맞게 결정 하면 될 것 같다.

 

자 마지막으로 모든 코드에 대한 리뷰과정이 있다. 보통 코드 인스펙션(Code Inspection) 이라고 하는데, CODE COMPLETE 2 에서는 코드 읽기로 소개가 된 것 같다.

인스펙터 툴도 있는데, 이건 제가 보기에는 정적 분석 도구로 분류하는 것이 더 나을 것 같다.

이게 사람들이 모여서 하게 되면, 잘못하면 누가 멀 잘못했는지 감정이 많이 상할 수 있는 부분이 있다. 이론상 좋지만 쉽지 않은 부분인 것 같다.

마이크로소프트에서는 개발자는 자신의 코드를 빌드 서버에 올릴 수가 없고, 리뷰어만 등록을 할 수 있는데, 보통 테스터가 많이 한다고 한다. 등록된 코드의 문제점에 대한 책임은 개발자가 지는게 아니고 리뷰어가 지게 된다고 한다. 당연히 내가 잘못한 것도 아닌데, 책임을 져야 하니 눈에 불을 키고 문제를 찾게 될 것이다. 저 또한 이 부분에서는 경험이 부족해 아주 자세한 노하우는 전달이 힘들 것 같다.

 

이러한 과정을 다 거쳐야 QG를 통과하게 되는 것이다. 사실 간략히 넘어갔지만 중간 중간 나오는 과정 하나가 상당한 분량이고 거기에 있는 툴 하나에도 상당한 책들이 나와 있을 만큼 중요한 부분이기도 하다.

제가 좋아 하는 부분이기도 해서 많이 다루고 싶었지만, 지금은 그 과정을 이야기 하는 부분이라 대부분 소개만 하고, 뒤에 자세히 다루기로 하겠다.

특히 몇몇 툴은 분량이 너무 많아 아예 카테고리 하나 만들어서 이야기 하는 것이 나을 것 같다.

 

자 다음은 Scrum(스크럼)에 대해 이야기 해 보도록 하겠다.

스크럼 자체를 아주 자세히 설명하는 건 아니니 스크럼이 무엇인지는 검색을 통해 미리 알고 있으면 좋을 것 같다.

 

Posted by SF공장장

 


 

마이크로소프트 PLC(Product Life Cycle)에서는 Product – Project – Feature 로 나누어서 접근하고 있다.

 

아무래도 마이크로소프트는 서비스 보다는 패키지 소프트웨어를 개발해서 판매하는 것을 주 업으로 하고 있어서 패키지 소프트웨어 개발 라이프 사이클을 잘 표현해 주고 있다.

그렇다고 꼭 패키지 소프트웨어에서만 적용이 가능한 것은 아니다.

어느 정도 차이는 있지만 인터넷 서비스에 적용하기에도 무난할 것 같다. 그리고 SI개발에도 도움이 될 것이다.

 

앞의 글에서 언급한 것처럼 항상 시작은 무엇(What)을 만드냐에서 시작한다.

하나의 제품(인터넷 기업에게는 서비스가 제품이 될 것이다.)을 만들기 위해 무엇을 만드냐는 것은 회사 전체의 전략이나 비전에 따라 결정이 될 것이다.

자동차회사에서 세탁기를 만든다면, 아무래도 좀 이상할 것 같다.

 

그럼 제품이 회사의 방향과 전략에 다르지 않다면, 왜 만들어야 하는지 당위성이 있어야 할 것이다. 우리가 살아가면서 필요하다고 무조건 물건을 구입하지 않는 것처럼, 기업 또한 필요하다고 무조건 만들지는 않을 것이다. “필요는 하지만 우리가 지금 정말 만들어야 하나?”

분명 여기서 생각해야 하는 것이 ROI(Return Of Invest) 일 것이다. 지금 수익성은 떨어지더라도 향후 회사의 전략상 필요한 것이라면, 당연히 모험을 해서 투자를 해야 할 것이다. 이 외에도 고려 해야 할 것이 훨씬 만을 것이다.

 

자 이제 만들기로 결정을 했다면, 개발의 입장에서는 전체 개발 공정을 어떻게 할 것인지, 업그레이드를 위한 장기 계획도 있어야 할 것이지만, 만들 무엇(What)에 대해 몇 가지 원칙이 필요할 것 같다.

 

고객, 비전, 방향, 책임

 

고객에게 전달할 제품의 가치는 무엇인지, 다양한 각각의 고객에게 줄 수 있는 비전은 무엇인지, 제품의 발전 방향에 대한 일관되고 신뢰할 수 있는 로드맵제품으로 인한 책임은 무엇인지를 개발에 앞서 결정해야 할 것이다.

 

SI 개발자들은 이런 이야기에 대해 이건 영업이나 PM이 할 일이고, 내 일은 아닌 것 같다고 대부분 생각하는 것 같다. 지금 맡겨진 일만 해도 태산이고, 스트레스 많은데 머 이런 것까지 라고 이야기 할 것이다. 다른 건 다 필요 없고, 내가 만들어야 하는 모듈이나 프로그램에 대해서만 정확히 이야기 해 주고 뒤에 다른 말만 안 해줘도 정말 고마울 다름이다.

그런데, 이렇게 일을 하면, 재미가 없다. 옆에서 보기만 해도 참 재미 없을 것 같다.

 

제가 만난 분 중에 SI 개발만 15년 이상 하신 분도 더러 있다. 비슷한 경력을 일 했으면, 실력도 비슷할까? 그건 아닌 것 같다. 정말 천차만별이다. 정말 하기 싫은 일을 밥벌이로 15년을 해도 생각해도 실력이 5년 정도 개발한 개발자와 별 차이를 못 느낀다. 거기에 비해 10년 정도 했는데도 진짜 대단하다는 생각이 드는 분들 또한 많다.

왜 이런 차이가 생기는지 한번 생각해 보시고, 그게 무엇일지도 한번 생각해 보시면, 내가 어떤 개발자가 될지 모습이 보일 것이다.

 

이외에도 제품에서 고려 하고 계획 해야 할 것들은 더 많을 것이지만, 이제 Project를 보자.

Value Proposition에 대해서 프로젝트 계획을 시작하면, 먼저 프로젝트의 최종 목표가 있을 것이다. 이 목표를 달성하기 위해 마일스톤과 기능에 대한 일정 그리고 기능의 우선 순위 리스트를 정한 후 엔지니어링 표준을 정해야 한다. 이제 우리가 앞 글에서 이야기 했던 구현에 대한 방법론 적용부터 디자인 등 이제 개발자들이 본격적으로 해야 할 일들이 슬슬 늘어나기 시작한다.

 

Feature 에서는 각 피처 팀들이 혼자 개발을 하는 것이 아니라 다른 팀과 지속적으로 상호작용하면서 애자일 방법을 사용해 개발을 진행하게 된다. 물론 지속적인 반복을 통해 각 빌드마다 QG(Quality Gate)를 통과 해야만 외부에 자신들이 자신 있게 만든 기능들을 공개하고 평가 받을 수 있다.

 

이런 과정을 거치면서 개발자들은 자신이 만들고 있거나 만들고 있는 제품에 대해 그리고 그 프로젝트에 작게는 자신이 참여한 피처에 자부심을 가지게 되는 것 같다.

아무래도 패치지 소프트웨어나 큰(사용자가 많은) 웹사이트의 개발자들이 이런 부분에 있어서는 자부심을 가질 수 있는 여건이 되는 것 같다. 게임의 경우에는 게임 마지막이나 중간 인트로 부분에서 개발에 참여한 사람을 영화처럼 보여주는데 이것 또한 개발자들에게 동기 부여가 되는 것 같다.

마이크로소프트에서는 제품 개발에 참여한 개발자에게 제품 출시와 관련해 특별한 기념품이나 제품의 버전 별로 참여한 사람의 이름을 돌에(?) 새겨 주는 것도 한다.

 

개발자에 대한 대우는 단지 높은 급여뿐만 아니라, 자부심을 가지고 일을 할 수 있는 환경 또한 절 때 무시 할 수 없을 것이다.

 

이렇게 하고 PLC를 넘어가기에는 아쉬움이 남는 것 같다.

실제 개발 중 개발자에게 가장 많은 스트레스를 줄 QG(Quality Gate)에 대해 알아보고, 품질 프로세스에 대해 살펴보자.

 

 

Posted by SF공장장

티스토리 툴바