참 이것저것 많이도 건드리고 있습니다. 머 하나 제대로 한 것도 없는데...
이번엔 TDD ( Test Driven Development) 입니다. 책은 사 놓고 1년 넘게 몇페이지 안보고 있다가
xUnit에 대해 관심을 갖다 보니 또 이렇게 끄적끄적 하게 됐네요. 
우선 책은 Kent beck의 Test-Driven Development By Example이란 책의 번역본 -_- 을 보고 공부하려 합니다. 
Money 객체를 통한 적용이 나오는 전반부는 다 봤고, 
이제 xUnit을 만드는 부분을 볼 차례입니다. 

이 책에는 예제코드가 Phython으로 있지만
저는 Cocoa framework에서 xUnit구현을 하고자 합니다. 
Phython의 언어적 특성을 얼마나 따라갈 수 있을지 모르지만, (아직 objective-c도 잘 몰라서...)
잘되면 xUnit도 공부하고, Objective-C 언어도 공부할 수 있어 일석이조가 될 수도 있을 듯 합니다. 
Posted by yunseong
이 포스트는 "왜 프로그램은 실패하는가"의 2장을 읽고 썼습니다.

발생한 defect 정보와 그 해결책을 연관짓기 위해서는 defect report를 적기 보다는, test case를 작성할 것을 추천하고 있습니다. 물론 저도 그것에 동의합니다. . 

물론 자세하게 적힌 defect report는 초기에 그 정보를 팀원과 공유하기엔 매우 유용합니다. 

그러나 예를 들면 2주 정도 지난 다음에 그 길게 작성된 따분한 report를 읽는 것은 어떨까요?

만약에 복잡한 state machine의 미묘한 문제같은 같은 것이라면 그 내용을 한참 지난 후에 기억하는 것은 쉽지 않습니다. 

더 나아가 만약에 1달 정도 지난 뒤에 regression testing을 해야 한다면, 그 test case를 작성하는 것 조차 거의 불가능 합니다. 

그래서!!

이 책의 저자는 defect이 해결되면, 바로 test case를 작성할 것을 추천하고 있습니다. 
(사실 이 부분은 제 개인적인 해석이 들어갔습니다. 책에서는 test case를 작성하고 report를 퇴물로 만들어라 라고 되어 있는데, 제 생각에는 최대한 빨리 test case를 작성하라는 것도 포함되어 있지 않을까 싶습니다.)

간혹 어떤 보고서보다도 test case가 더 명확하기도 합니다. test case는 단어보다는 논리로 구성되기 때문입니다.  


This post is written after reading chapter 2 in "Why programs are failed??"


Be linked with happened defect information and its solution, writer recommends make test case, instead of writing defect report, and i agree. 

Of course, at beginning step, defect report which is written in detail is helpful for sharing with team member what happened. 

But after 2 weeks passed from it resolved, how about that i have to read that boring report to verify it??

If that defect is happened in complex condition (For example, a kind of state machine problem) , I cannot remember all of its situation. 

Furthermore, how about i have to do regression test after a month?? Even writing test case  is almost impossible. 

So!!

in this book writer recommends to write its test case immediately when defect is resolved. (Don't be LAZY!!!)

Sometimes, test case code can be more clear than any other report, because test case is the code, and the code is logic not words, i think.

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
본 내용은 "왜 프로그램은 실패하는가? (Why programs are failed?)"란 책을 읽으며 작성한 글입니다. 

일반적으로 정말 단순한 프로그램을 개발하는 것이 아니라면, Issue tracker 혹은 bug tracker라 불리는 시스템을 사용하게 됩니다. 

대표적인 툴로서, 먼저  bugzilla 와 Mantis가 있습니다. 둘 다 Open source기반이고, Web 기반입니다. 
그러나 제가 리눅스에 매우 약한 이유로 이 둘은 써본적이 없습니다 -_-;;

그리고 상용프로그램은 대표적으로 Perforce와 IBM의 Clear Quest가 있습니다. 
Perforce는 써본지 워낙 오래 되었고, 당시에는 이런 툴의 목적도 몰랐고 잘 쓸줄도 몰랐고 -_-;; 사실 지금은 Clear Quest밖에 쓸 줄 모릅니다. 

그렇지만 이런 Issue tracker류의 프로그램은 사용방법이 대동소이 한 것 같습니다. 

Defect정보를 등록하면 (Defect Submit), Project manager에 의해 개발자 혹은 누군가에게 할당되고 (Assign), 개발자는 그 문제를 분석 및 수정한 후에 수정되었음을 표시하고 (Resolved), 해당 defect의 수정이 확인되면 (Closed)시키는 process를 갖게 됩니다. 물론 reject, reopened등의 state가 있지만, one-shot 에 수정가능하다는 전제하에^^ (이와 다르게 하는 경우도 있나요? 있으시면 리플좀 ^^;)

물론 이 책에서 처럼 Unconfirmed, verified 등의 state가 있을 수는 있으나 이는 생략이 가능해 보이고, 

이 책에서 표시된 "WONTFIX" (Will Not Fix)는 사실 아직 겪어보진 못했습니다.
요구사항에 명시되어 있는 대로 동작하지 않는 다는 것을 알면서도 고치지 않겠다라는 건... 글쎄요. 아마 현재의 상황에 어쩔 수 없는 선택이겠지요? 그렇다면, 이는 시간 (혹은 현재의 어떤 특별한 상황)의 문제일 뿐, 나중엔 고쳐져야 하지 않을까 싶습니다. (그렇다면 POSTPONE 처리) 아니면, "고칠 이유가 없다"라는 이유로 고치지 않겠다고 하면, 이 defect을 올린 test engineer가 가지고 있는 requirement spec이 현재 개발이 가는 방향과 일치하지 않는다는 것입니다. 그렇다면 요구사항 변경  process를 수행해야 겠죠. (요구사항의 문제 혹은 SQA Error로 Close 할 수 있음). 

그리고 이 책엔 SCCB (Software Change Control Board)가 나옵니다. defect을 누구에서 assign할 것인지, severity, priority를 정하기 위한 모임이라는데... 개발자, 테스터, 형상관리자가 참가한다고 나옵니다.
근데 이 정도면 개발팀 전체 다 나오라는 것 같군요... -_-;;

사실 defect의 severity는 개발팀과의 관계에도 매우 민감한 문제입니다. 일반적으로 critical 혹은 Major수준의 defect이 발견되면, 해당 S/W는 출시를 하지 않아야 합니다. 그런에 이 구분 명확하지 않아 애매모호 하면, 개발팀과 의견 충돌이 발생할 수 있습니다. 

실제 이런 경우가 있었습니다. 

모 개발 조직에서 defect의 severity를 책정할 때, Requirement Spec violation은 Major defect처리 한다. 라고 정하고 시작하였습니다. 그러다 테스트 도중 거의 일반적인 user scenario에서는 쓰이지 않는 기능중에서 spec과 약간 다르게 동작하는 현상 (Spec과 다른 error code반환) 을 발견했습니다. 이를 issue tracker에 major defect으로 등록하자 

개발팀 : 이 defect은 major급이 아니다. 어짜피 error는 발생시켰지 않느냐,, 그 error code가 아니더라도, 일반적으로는 error가 발생하면 retry하기 때문에, 동작은 같다.
SQA팀 : 해당 error code는 Industry spec에 명시되어 있으며, 우리의 requirement spec에 우리의 product는 Industry spec을 따른다고 명시되어 있다. 그리고 모든 사용자가 그 "일반적"이라는 시나리오 대로 사용할 것을 보장할 수 있는가?  
개발팀 : 그러나 이 문제로 다시 시스템 테스트 process를 밟으면 납기 일정을 맞추지 못할 수 있다. 그 risk가 더 크다. 동작이 크게 틀리지 않은데 굳이 major로 처리해야 하는가? 
SQA팀 : 물론 일정의 문제는 이해하지만, 그렇다고 spec violation을 아니라고 할 수는 없다. Major처리 하겠다.

머 대략 이런 경우입니다. 많이 공감하시는지 모르겠습니다. 전 하도 많이 겪어봐서 -_-;; 대부분 납기 일정에 쫓길 때 이런 상황이 많이 발생하더군요. 이럴땐 기획이나 마케팅의 자문을 구해 일정의 critical한 수준을 보고서 판단하여 해결하는 경우가 많았습니다만... 참 어렵더군요. 하지만 이런 일을 겪으면서 defect의 severity를 정하는 지표가 도출되어 점점 나이지긴 했습니다.

추가 : Issue tracker가 필요한데 서버도 없고, 서버 운영할 사람도 없으면 google의 Project hosting을 참고하세요~ 무료입니다!!

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong

Objective-C 2.0에서는 Retain count 기반으로 메모리 할당 해제가 관리 됩니다. 
그 규칙은 다음의 3가지 입니다. (Apple의 Memory Management Programming Guide for Cocoa 참조)

 
1. You own any object you create. (니가 만든건 니가 갖는다)
    You "create" an object using a method whose name begin with "alloc" or "new" or contains "copy" (for example, alloc, newObject, or mutableCopy).

2. If you own an object, you are responsible for relinquishing ownership when you have finished with it. (만약 객체를 소유했으면, 다 쓸때 반환하는 것에 대한 책임도 가지게 된다)
    One way to relinquish ownership of an object is to send it a release message, In cocoa terminology, relinquishing ownership of an object is typically referred to as "releasing" an object.

3. If you do now own an object, you must not release it. (직접 만든 객체가 아니면 절대 해제하지 마라)


규칙은 간단합니다. 만든건 책임지고, 안만든건 건드리지 말라. Memory leak을 유발하지 않기 위한 가장 기본적인 원리입니다. 

위의 규칙을 몸소 겪어보고자, 요 한동안 삽질의 연속이었습니다. Retain / Release를 통한 메모리 관리 mechanism을 몸에 베게 하기 위해 일부러 NSAutoreleasePool 객체를 만들지 않고 코딩연습을 했습니다. 그렇게 하면 정확한 프로그래밍을 하지 않으면 leak이 우수수 쏟아질 것으로 생각했기 때문입니다. (그러나 convenience method를 호출할 수 없어 난관이 있었습니다 -_-;)

머 결과는 그닥 보잘것이 없습니다. Web에서 쉽게 찾아볼 수 있는 수준의 결과가 나왔네요. 몇일 동안의 삽질 끝에 알아낸 것을 정리합니다. 

1. NSString에서 initWithXXXX계열의 함수들은 parameter로 받은 객체의 retain count를 1 증가시킨다.
즉 복사가 아닌 reference한다. 사실은 initWithXXXX계열의 함수는 alloc된 객체에 의해서만 가능합니다. 즉, alloc을 호출하기 때문에  retain count가 증가하는 것은 당연한거지요. 이 말은 즉, 직접 release까지 해 주어야 한다는 것입니다.  

2. NSString에서  stringWithXXXX계열의 함수들은 parameter로 받은 객체를 "복사"하고 NSAutoreleasePool에 등록한다.
 즉 객체를 만든 입장에서는 release를 해주지 않아도 된다는 것입니다. 이 함수는 alloc을 호출하지 않고 [NSString stringWithFormat: ~~~] 이런 형식이기 때문에 alloc을 사용자가 명시적으로 호출하지 않습니다. 즉 release하지 않아도 된다는 것입니다. AutoreleasePool을 이용한 release는 delayed release가 됩니다.  이런 stringWithXXXX같이, 사용자가 release를 신경쓰지 않고 autoreleasePool을 이용하도록 하는 함수를 Convenience Method라고 합니다. 

3. Code상에 @"ABCDEF"같이 문자열을 직접 쓰는 것은 객체가 아니기 때문에 해제할 필요도 없다. 문자열을 이용해 initWithString함수를 이용해 만든 NSString객체는 해재할 필요 없다. 

그런데!!! 참 알다가도 모르겠습니다. main함수에서 열심히 retain counter를 올려봤건만... 하나도 release하지 않았는데 프로그램이 종료될 때 까지 leak error가 발생하지 않더군요... 이건 참 모르겠습니다. 물어볼 사람도 없는데 -_-;;
 

#import <Foundation/Foundation.h>

#import "Test.h"


#import <Foundation/Foundation.h>

#import "Test.h"


int main (int argc, const char * argv[]) {

    NSAutoreleasePool * pool = [[NSAutoreleasePool allocinit];

    Test* test = [[Test allocinit];

    [test printMemberRetainCount];


    NSString* testName = [NSString stringWithFormat@"ABCDEFG"];

    [test setName: testName];

    [test printMemberRetainCount];

    
    [testName
retain];

    NSLog(@"Test Name's retain Count : %d", [testName retainCount]);

    [pool drain];

    

    return 0;

}



저 녹색 글씨부분... 분명히 retain Counter가 1 증가하여 autoreleasePool에서 release시켜도 dealloc안되고 leak이 되어야 하는데... 



어디에도  leak에 대한 error는 없습니다. -_-;; 모르겠네요 -_-


Posted by yunseong
이제 실제 XCode에서 버젼관리가 되는 개발을 시작해보겠습니다. 

원본소스를 이용해 소스코드를 import시켰지만, 정작 원본소스 코드를 XCode로 여시면, version관리가 되지 않습니다. Repository에서 새로 코드를 받아서 열어야만, 버젼 관리가 됩니다. 

Repository explore에서 trunk폴더를 선택하시고, 프로젝트 폴더를 선택하시고, Check Out버튼을 누릅니다. (물론 원본소스코드와 다른 폴더이여야 겠죠? 아니면 원본폴더를 지워버리셔도 됩니다. 어짜피 서버에 있으니까...)


Check Out이 끝나면, 

이런 창이 뜨고, project를 Open합니다. 

열린 프로젝트 창에서 File Name이라고 써 있는 부분에서 마우스 오른쪽 click을 하시면, 다음과 같이 SCM항목이 나옵니다. 여기서 SCM을 체크해줍니다. 

바로 소스의 변경 상태를 나타내주는 column입니다. 간단히 소스코드를 수정해보면, 

contact.m 파일 옆에 M(Modified) 이라고 나타납니다.  다른 사람에 의해 Upload된 파일이 있으면 U라고 뜹니다. (근데 google은 좀 반응이 느리군요 -_-)

수정내용을 repository에 반영하려면, 아래와 같이 Commit Changes, 혹은 rollback하려면 Discard Changes를 선택하시면 됩니다. 

Commit을 하시면, 이 코드에 대해서는 Revision이 1 증가하게 됩니다. 

아래의 2개의 캡쳐를 비교해 보시면, 
위의 그림이 Commit하기 전, 

이게 방금 Commit한 캡쳐입니다. revision이 r2에서 r3로 증가했습니다. 

우선 저도 해본게 여기까지라 당장은 더이상의 posting이 어렵군요 -_-;;
여기까지는 SVN의 가장 기본적인 기능입니다. 물론 실제 project를 진행하려면, rollback도 할 줄 알아야 하고, Diff툴도 쓸 줄 알아야 하고, 다른 revision끼리의 merge도 할 줄 알아야 하는데, 저는 아직 SVN은 익숙치가 않네요 ^^;

사실 이런 SCM 시스템이 있어도, 적절한 branch전략, labeling (tag생성), 그리고 merge가 뒷받침되지 않으면 안됩니다. 회사에서 Clear Case를 쓰는데, 그런 비싼 고가의 tool이 있어도 그냥 대충 쓰는 사람이 있는가하면 끝내주게 체계적으로 사용하는 사람도 있습니다. 

각설하고, 나중에 merge, rollback등이 익숙해지면, 또 posting 해야 겠습니다. 



Posted by yunseong
먼저 XCode에서 개발하고자 하는 project를 생성합니다.

그리고 project가 생성된 폴더를 보면 아래와 같이 xcodeproj파일 및 pch, h, m파일 등이 있을 것입니다. (저는 console기반의 project를 만들었고, 이미 몇 개의 파일을 만들어 놓았습니다.)

이 파일들을 repository에 올릴텐데, 이 때 이 폴더에 있는 모든 파일을 올릴 필요는 없습니다. 
이 중에 개발산출물 폴더인 build폴더, 그리고 프로젝트 파일을 가장한 폴더인 xcodeproj안의 mode 파일, pbxuser파일은 굳이 공유할 필요도 없고, 버젼관리가 될 필요가 없습니다. 오히려 이 것들이 version tree안에 있으면, merge나 check in시에 귀찮기만 하지요. 그래서 이 것들을 알아서 빼도록 설정합니다. 

터미널을 띄우시고, 
cd ~/.subversion 폴더 안의 config파일을 수정합니다. 

수정 내용은 global-ignore라는 항목을 찾아서 (아래 검정색 박스로 만들어 놓은 부분입니다)
 
다음과 같이 수정합니다. 

맨 앞에 '#' 을 지워 주석처리를 없애주시고, 뒤에 "build *.pbxuser *.mode*" 라고 추가하고 저장합니다. 의미는 집작하셨겠지만, 여기에 해당하는 파일들은 repository에  upload할 때 자동으로 빠지게 됩니다. 

그리고 실제 upload를 해 봅시다

XCode에서 SCM --> Repositories... 를 선택하시면, 

이 창이 뜨는데, 만든 Repository를 선택하시고, trunk 폴더를 선택합니다. 아시다시피 trunk폴더는 main소스코드가 저장되는 곳이기 때문에... (저는 이번에 알았습니다 -_-)
trunk 폴더를 선택하시고, 왼쪽 상단의 Import 버튼을 누르면, 

창이 뜹니다. 여기서 프로젝트 폴더를 선택하시고, 아래의 comment box에 간단한 Comment를 달고 Import 시킵니다. 

그럼 잠시후에 Import Completed라는 메시지 박스가 뜹니다. 

그리고 trunk 폴더를 확인해보면, 

소스코드가 repository에 upload되었습니다. 그리고 불필요한 파일인 mode, pbxuser 파일, Build폴더 등은 없습니다. 이렇게 하면 기본적인 Upload는 다 되었습니다. 

다음 Post는 이제 repository에서 소스코드를 다운받고, 버젼관리하는 것을 보겠습니다. 

참고로, 이 내용은 박진형님의 blog내용을 참조했습니다 (http://jinhyung.org/2008/06/04/inside-xcode-1/
Posted by yunseong
Google Project Hosting site에서 Project생성을 완료했으면, XCode에서 연결을 해야겠죠. 

XCode를 실행시키면 menu-bar에서 SCM --> Configure SCM Repositories... 를 선택합니다. 


처음 SCM을 셋팅하신다면, Repository가 아무것도 없을거고, 이미 있으시다면 있겠죠 -_-;; 

제 캡쳐화면엔 있지만, 새로 셋팅하는 것으로 하겠습니다.

먼저 왼쪽 하단에 + 표시를 누르시면, 

요렇게 뜹니다. 이름을 입력해주시고, SCM System은 Subversion을 선택합니다. 

그러면 Subversion Setting창이 뜹니다. 정보를 입력해줘야 하는데, 

먼저 URL은 google Project hosting에서 앞장에서 만든 Project 메인페이지에서 "Source" tab을 클릭합니다. 


선택하면, 

자, 화면 중반부에, https 프로토콜의 URL을 볼 수 있습니다. 여기서, trunk 앞, 즉 ~~~~~/svn/ 까지를 복사해서 XCode의 URL창에 붙여 넣습니다. 

그리고 URL에서 focus를 out시키면, Scheme, Host, Path창이 자동으로 입력되고, SSL Certificate 창이 뜹니다.  Accept하시고, 

username은 본인의 google ID (@gmail.com은 뺍니다) 를 입력하고 (만약 제 Id처럼 .이 있으면 .은 빼고 입력합니다) Password는 화면 중반부의

When prompted, enter your generated googlecode.com password.

에서 링크된 부분을 클릭하면 Password가 나옵니다. 

역시 입력을 마치시고 apply를 누르시면

아래와 같이 "Authenticated"가 떠야 합니다. 떴으면 인증 완료입니다.



그럼 생성된 폴더를 확인해봅시다.

XCode메뉴의 SCM --> Repositories... 를 선택하면 Repositories창이 뜹니다. 


거기서 왼쪽에 방금 만든 Repository를 선택하면

보시는 것과 같이 SVN의 기본 폴더인 trunk, branches, tags 폴더를 보실 수 있습니다. 

우선 연결은 이렇게 하면 끝나겠네요. 다음은 실제 XCode Project를 설정하고, source code를 올리는 것을 posting하겠습니다. 




Posted by yunseong
SVN서버는 SCM (Software Configuration Management, 소프트웨어 형상 관리) tool 중 하나로, CVS의 개량판이라고 하더군요. 사실 저희 회사는 IBM社의 Clear Case를 쓰기 때문에, SVN은 이번에 처음 써봤습니다. CC와는 다른 부분이 많아서 아직도 햇갈리는 부분이 많지만, 머 차차 적응해가야 겠지요 ^^

요새 집에서 iPhone S/W를 개발해보려고 하고 있는데, source code version을 관리할 마땅한 시스템을 찾지 못하고 있었습니다 (회사의 CC는 외부에서 접속 불가 -_-, 게다가 XCode는 CC지원 안함 -_-) . 리눅스도 잘 쓸줄 모르고, 집에 있는 데탑에 WinCVS서버 깔면, 항상 집에 있는 PC를 켜놔야 하고...(요새 경제가 어려워 전기료가... -_-). 무엇보다 저는 PC를 자주 포맷하는 편이라 안정적으로 서비스를 제공하는 사이트를 찾아야 했습니다. 이를 찾기 위해 웹검색을 한 결과 역시 google은 에지간한 서비스는 다 하고 있더군요. 물론 assembla나 다른 몇개의 사이트도 찾았지만 아무래도 google이 안정적일 것 같아 google로 결정했습니다. 단!! google은 open source를 전제로 한다는 것!! 누구나 source code를  browsing할 수 있습니다.  저는 제 소스를 많이 부끄러워하는 편이라 공개하는건 좀 그렇지만, 아직 본격적인 개발을 할 단계는 아니고, SVN에 익숙해질 겸, Objective-C에 익숙해질 겸 해서 우선 여기에 둥지를 틀기로 했습니다. 그럼 시작합니다!!

먼저 http://code.google.com에  로긴해서 Project Hosting --> create new project를 클릭하여 기본적인 프로젝트 정보를 입력하여 프로젝트를 생성합니다. License종류를 선택하라는데, 이 부분은 저는 머가 먼지 몰라서 아무거나 선택했습니다. 차이점을 아시는 분은 답글 달아주시면 감사하겠습니다. (제가 linux를 모르니 이런 부분은 상당히 약하군요)



project를 다 만들었으면, 화면 오른쪽 상단에 Profile을 클릭하면 본인이 만든 프로젝트가 나옵니다. 그럼 우선 project는 생성 끝입니다 -_-;;

참고로 이 Google Project Hosting은 SVN뿐만 아니라, wiki, DTS (Defect Tracking System) 까지 지원을 해줍니다. google doc까지 쓰면 Project관리의 상당부분을 One-Stop으로 관리할 수 있습니다.
Posted by yunseong
소프트웨어 지표는 3가지로 분류할 수 있다.

1. Product Metrics
  --> 제품의 특징을 나타낸다. 크기, 복잡도, 디자인, 성능, 품질 수준 등 제품 자체에 대한 특징을 담고 있다.

2. Process Metrics
  -->소프트웨어 개발의 관리 정도에 대해 나타낸다 즉, 개발기간동안 발견된 결함의 해결 효율성, 결함 해결 소요 시간 등을 담고 있다.

3. Project Metrics
  --> 소프트웨어 개발 프로젝트의 지표이다. 즉, 투입된 개발 인력, Staff, 비용, 일정, 생산성 등을 나타낸다.


참고 : Chapter 4. Software Quality Metrics Overview in Metric and Models in Software Queality Engineering

'Software Testing > Metric and Models in SQE' 카테고리의 다른 글

Category of Software Metric  (0) 2008.11.04
Some Software development process model  (2) 2008.11.03
Posted by yunseong
1960~1970년대에 소프트웨어 개발 프로젝트는 비용 초과 방지와 일정 준수에 촛점을 두었다.
Water-fall모델은 개발팀에 무엇을 개발하여야 하고, 개발물은 무엇을 지원해야 하는지에 대해 명확히 하는 것을 주 목적으로 한다.
Water-Fall Model에서는 ETVX Paradigm (Entry, Task, Verify, Exit)이 가장 중요한 특징이다.
Water-Fall Model의 가장 큰 특징이자 제약점은 요구사항이 fix되어 있다는 것을 가정한다는 것이다.
따라서 요구사항이 변경될 경우 유연하게 대처할 수 없다. 그러나 현재의 소프트웨어 개발은 요구사항이 명확하지 않는 상태에서 진행될 수 있으며, 심지어 정의하지 못하는 경우도 있다 .

이를 보완하기 위해 나온 모델이 prototyping이다. 이는 메인 개발을 시작하기 전에, prototype을 먼저 개발하고, 이 prototype에 고객이 만족할 경우에 메인 개발을 시작하는 모델이다 .

Spiral model (나선형 모델)은 prototyping을 확장한 것으로 개발을 단계별로 나누어, 각각에 대해 prototype을 개발, 및 통합을 거치는 model이다.

'Software Testing > Metric and Models in SQE' 카테고리의 다른 글

Category of Software Metric  (0) 2008.11.04
Some Software development process model  (2) 2008.11.03
Posted by yunseong
이전버튼 1 2 3 4 이전버튼