소프트웨어 생명주기에서 프로세스 모델의 목적은 “Feature – Quality – Time – Resource(사람과 비용)” 이 네 가지의 요소를 최대의 효과를 내기 위해서 이다. 이걸 잘하기 위해 소프트웨어 공학이 존재하고, 많은 개발 방법론과 기법들이 총 동원되고 있다.

 

제가 이 모든걸 다룰 능력은 되지 않고, 개발자에 좀 더 집중하기 위해 QA(Quality Assurance)에 좀 더 비중을 두고 이야기를 풀어 나갈 것이다.

 

소프트웨어 QA 우리말로 하면 품질 보증이 될 것 같다. 그럼 그 특성을 살펴보면, 소프트웨어 품질의 특성은 스티브 맥코넬의 “CODE COMPLATE 2”에서는 소프트웨어는 외적 품질 특성과 내적 품질 특성으로 나누어서 이야기 하고 있다.

 

외적 특성

정확성(Correctness), 유용성(Usability), 효율성(Efficiency), 신뢰성(Reliability), 무결성(Integrity), 적응성(Adaptability), 정밀성(Accuracy), 견고성(Robustness)

 

내적 특성

유지 보수성(Maintainability), 유연성(Flexibility), 이식성(Portability), 재사용성(Reusability), 가독성(Readability), 테스트 용이성(Testability), 이해성(Understandability)

 

중요하지 않은 게 하나도 없다.

 

여기서 집중하고 싶은 내용은 바로 실제 프로그래밍 과정에서 코드 테스트 디버깅과정을 효율적으로 일하는데 많은 시간을 할애 할 것이다.

 

작년 2008 3Heroes Happen Here 이라고 Visual Studio 2008 제품 발표회가 있었다.

이때 제가 발표한 내용이 실전 Visual Studio 2008 Agile Programming이라는 주제로 발표를 했었다.

그리고 2008 5월 동일한 주제로 월간 마이크로소프트웨어 잡지에도 기고한 내용이 있다.

이것 또한 참고하면 도움이 될 것 같다.

 

1장은 이쯤에서 마치고 2장으로 넘어가도록 하겠다.

 

신고
Posted by SF공장장

스크럼을 이야기 하면 당연히 따라 나오는 것이 애자일 소프트웨어 개발(Agile software development)이다. 그 중 가장 대표적인 것이 "Extreme Programming" 이다.

이것을 또 작게 나누면, 프로그래밍 테크닉, 개발 프로세스, 프로젝트 관리 이렇게 세 부분으로 구분 할 수 있다.

스크럼은 애자일 개발 프로세스로 분류할 수 있으며, 여기에는 익스트림 프로그래밍과 FDD(Feature-Driven Development), ASD(Adaptive Software Development) 등이 포함된다.

 

스크럼이 최근 인기를 누리는 건 무엇 때문일까?

마이크로소프트 내에서는 왜 스크럼을 많이 사용하는 걸까?

 

제가 들은 바로는 마이크로소프트 내에서 스크럼을 많이 사용하는 건 처음부터 스크럼이나 다른 모델을 적용했다기 보다는 마이크로소프트 내에서 진행되고 있는 개발 형태를 분석하고 외부 전문가에게 보이니 이 프로세스가 스크럼과 아주 유사했다고 한다. 그래서 자연스럽게 스크럼의 장점을 마이크로소프트 내부 개발 프로세스로 정착 하는 과정에서 마이크로소프트는 스크럼만 한다더라 이런 이야기가 나오게 된 것 같다.

 

 

위의 리서치 자료는 2005년말 기준으로 마이크로소프트 내부에서 애자일 방법 적용과 다른 기업의 적용 결과를 보여 주고 있다. 국내에는 XP가 가장 인기가 있을 시기였던 것 같다. 마이크로소프트 내부를 보니 스크럼이 대다수를 차지하고 2위가 모른다라는 것이 재미있다. J

 

스크럼은 30일 이내의 개발 주기를 설정하고, 구현하거나 개선할 기능에 우선 순위를 부여하고, 개발 주기에 적용하거나 개선할 목록을 설정한다. 그리고 항상 팀 단위로 의사 소통을 하고, 매일 짧은 미팅을 통해 확인해 가는 과정이다.

 

스크럼을 통해 얻을 수 있거나 배울 수 있는 것은 무엇일까?

스크럼은 기술이 아니라 역할이 중심이다.

팀 단위 주기는 최대 30일을 넘지 않는 것이 좋지만, 개발자 개인은 한 주를 단위로 하는 것이 효율적이다.

개발 주기 별 단기 목표를 위해 노력해야 하고, 팀에 의한 팀의 성공과 실패만 있다.

워크 아이템은 4~16시간 정도가 적당하다.

완료라는 것은 개발, 테스트, 필요한 경우 문서, 테스트 샘플 작성 등을 포함한다.

매일 짧은 시간 미팅(15분 정도)은 아주 중요하다. 이 시간은 지켜져야 한다.

 

초보 개발자들은 거절을 잘 못한다. 자기가 다 할 수 있을 거라고 생각하고, 할 수 있다고 이야기 한다. 혹 매니저가 안될 것 같다고 이야기 하면 자기 실력을 의심한다고 아주 불쾌하게 생각하거나 낙심한다.

 

못한다는 것은 실력이 부족해서 못할 수도 있고, 방법이나 리소스를 몰라서 못할 수도 있고, 시간이 없어서 못할 수도 있다. 제가 볼 때 대부분의 경우는 두 번째나 세 번째 경우가 훨씬 많다.

 

대부분의 좋은 매니저들은 이 상황을 잘 알고 있다. 간혹 개발자들에게 이거 할 수 있어, 실력이 없어서 못하는 거 아니야. 이거 못할 거 같은데.” 이렇게 개발자들의 감정을 건드려 할 수 있다는 확답을 들으려는 사람이 있다. 그러고 뒤에 가서는 당신이 할 수 있다고 하지 않았냐?” 등으로 사람을 궁지로 몰아 넣는 경우가 있다.

매니저로서 정말 쉽게 살아가는 경우가 이런 경우다. 당신이 기능 정하고 일정 잡아서, 언제까지 보고해 라는 식으로……

한가지는 확실하다. 이런 매니저는 오래 못 간다.

근데, 회사에서 이 사람의 정치력이 아주 뛰어나거나 높은 곳에 인맥이 있다면이런 경우는

 

젠장, 회사 옮겨야 하나. T.T

 

다음 글은 이제 슬슬 이번 장을 마무리 하는 글로 넘어가도록 하겠다.

 

신고
Posted by SF공장장

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공장장

티스토리 툴바