2008. 11. 7. 08:50

▣ ASP.NET Unit Test (in Visual Studio Team System 2008 Development Edition)


[ ASP.NET Unit Test ]

 

* 웹 환경에서의 Unit Test는 극히 제한적으로 이루어질 수 밖에 없음

    + MSDN에서 ASP.NET 단위테스트는

         “.aspx 파일이나 App_Code 폴더 외의 다른 폴더의 코드에서는 테스트를 생성할 수 없습니다.“

       라고 설명하고 있다.

       따라서 이외의 테스트는 실행할 수 없다.

    + VSTS2008 Development Edition에서는 [단위테스트]외에 [웹 테스트],[부하 테스트], [수동 테스트], [제네릭 테스트], [순서가 있는 테스트]는 실행할 수 없다

        - VSTS 2008 Test Edition에서만 가능

 

* 단위 테스트의 작성 방법은 테스트의 초기 소스코드를 만드는 코드 생성 기능을 이용하는 방법과 직접 테스트 코드를 생성하는 방법이 있다.

    + 자동으로 코드를 생성하는 방법

        - 메뉴의 [테스트]-[새 테스트]를 이용하여 생성

        - 테스트를 수행할 메서드에서 Context Menu를 이용해 단위 테스트를 생성

    + 직접 테스트 코드 생성하는 방법

        - 테스트 프로젝트를 생성하거나 미리 생성된 테스트 프로젝트에서 Attribute를 포함한 테스트 코드를 작성하여 생성

 

* 단위 테스트의 개요

    + http://msdn.microsoft.com/ko-kr/library/ms182516.aspx

 

 

 

[ 간단한 예를 통한 ASP.NET에서의 Unit Test 방법 ]

 

1. 단위테스트를 수행하기 위해서는 먼저 Web Application이나 Web Site 프로젝트가 생성되어야 함

    + Web Application으로 생성하는 것을 권장(배포 및 관리적인 측면에서 Web Site보다 좋다고 함)

 

▶[그림 1] 테스트를 수행할 웹 페이지 UI

 

 

▶[그림 2] 테스트 대상 프로젝트

 

 

 

2. 단위 테스트를 위해서 Test 프로젝트 생성

 

▶[그림 3] 단위테스트의 생성

    + 자동으로 Test 프로젝트를 생성해줌

 

 

▶[그림 4] 단위 테스트를 만들 Method 및 환경 설정

    + 원하는 Method를 선택하면 해당 코드의 테스트코드가 생성됨

 

 

 

3. 환경을 설정함

 

▶[그림 5] LocalTestRun.testrunconfig를 실행한 테스트 실행 환경설정 :: IIS 에서 테스트 수행시

    + 메뉴의 [테스트]-[테스트 실행 구성 편집]으로 실행

    + 호스트 형식을 [기본값]으로 사용하면, VS2008에서 지원하는 Virtual IIS에서 테스트가 수행됨

    + IIS에서 테스트를 수행할때는 다음과 같이 설정

 

 

▶[그림 6] 테스트 코드에서의 설정

    + 테스트 코드 생성시 자동으로 생성되는 Attribute를 설정

        - IIS에서 테스트 수행시에는 [AspNetDevelopmentServerHost] 속성을 사용하지 않기 때문에 주석처리함

        - [UrlToTest]에는 실제 웹브라우저에서 확인가능한 페이지를 설정함(페이지명까지 설정하도록 함)

            :: 해당 페이지가 다른 페이지로 Redirect하는 경우 꼭 Redirect된 페이지가 웹브라우저에서 표시가 되는지 확인

            :: 가능하면 Redirect되는 페이지를 사용하지 않을 것을 권장

    + 테스트를 수행하기위한 값으로 초기화

        - 그림에서는 입력값에 각각 1과 출력값으로 3을 설정

 

 

 

4. 테스트를 실행

 

▶[그림 7] 실패하는 테스트 실행 결과(빨간색으로 표시)

 

 

▶[그림 8] 성공하는 테스트 실행 결과(녹색으로 표시)


[참고사항]

 

1. 테스트를 수행할 타겟이 protected나 private와 같은 멤버는 외부에서 접근할 수 없는 것이 옳다.

    하지만, 이로 인해 테스트를 수행하지 못한다면 의미가 없기때문에 VSTS에서는 Accessor를 이용하여 해당 멤버를 사용할 수 있도록 한다.

 

2. Attribute를 가진다.

    + 이 Attribute는 해당 테스트 메서드만을 위한 것이다. 

    + IIS 환경에서 테스트를 수행할때는 [AspNetDevelopmentServerHost]를 사용하지 않는다

    + [UrlToTest]는 웹브라우저에서 실제로 접근이 가능한 웹페이지까지의 Full URL을 설정한다.

        - 여기서 예에서 보이는 Default.aspx가 다른 페이지로 Redirect될 경우 해당 페이지가 웹 브라우저에서 잘 보이는지 꼭 확인해야 함.

테스트

코드의

Attribute

[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("E:\\inetpub\\Temp\\AddTemp\\AddTemp", "/")]
[UrlToTest("http://localhost/Default.aspx")]
[DeploymentItem("AddTemp.dll")]

 

3. 테스트 코드를 검증하기 위해서 [Break Point(F9)]를 사용할 수 없다.

    + 동일한 목적을 위해서는 System.Diagnostics.Debugger.Break(); 를 테스트 코드의 중단 위치에 입력하여 사용한다.

 

[참고자료]

 

1. 단위 테스트 작업 

    + http://msdn.microsoft.com/ko-kr/library/ms182515.aspx

 

2. How to: Debug while Running a Test in an ASP.NET Solution

    + http://msdn.microsoft.com/en-us/library/ms243172.aspx

 

3. Microsoft 고객지원

    + http://support.microsoft.com/

 

4. 개발 OS가 XP를 사용하면 웹 브라우저의 Session개수가 10개로 제한되어 테스트 수행시 오류를 발생할 수 있다.

    + [제어판]-[관리도구]-[성능]에서 [Current Connections] 정보로 확인 가능

 

 


Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon 열라착한앙마 2008.11.11 16:58 신고  댓글주소  수정/삭제  댓글쓰기

    회사 지식게시판에 작성하고
    귀찮아서 그냥 복사해왔더니만..
    짤리네;;;

2007. 9. 18. 16:13
Cem Kaner(http://www.kaner.com)SWEBOK(Software Engineering Body of Knowledge)의 문제점을 지적한 글을 다음의 링크를 따라가서 보도록 하자..
당연 영어니까 마음의 준비는 단단히 해두시고...
(영어가 능숙한 당신이라면 간단하게 클릭클릭~ 난 우황청심원 먹고 크...클리익.. ㄷㄷ)

http://www.satisfice.com/kaner/?p=7


안되겠다.. 나중에 천천히 보자..
양도 방대하고.. 울렁증이 도저히..ㅎㄷㄷ

IEEE에서 발간한 SWEBOK이 문제가 많다는 소리는 많이 들었지만
이렇게 문제가 많았나?
전문가들 싸그리 모아서 만들었다던데 왜이리 말이 많은지..

소프트웨어공학을 공부하는 사람으로써 SWEBOK도 읽어보고(또 영어 ㅡ.ㅜ)
왜 말도 많고 탈도 많은지 문제점도 읽어봐야겠고.. (이건 아직...으으 ㅜ.ㅜ)

나름대로 자신만의 소견을 갖도록 해야겠다..
아직 경험도 지식도 부족한 나에게는 모두가 공부거리다..

Cem Kaner가 Software Testing 분야의 전문가라고 한다.. 그래서인지 주로 Testing 관련 부분에 대해 문제점을 지적하고 있다고 한다..
흠.. 지금 준비하는 학위 논문도 테스트쪽이고 하니..
나에게는 필수적으로 함 읽어볼만한 가치가 있는 글이겠다...
그나저나 영어 울렁증 치료약은 없나?

Posted by 열라착한앙마

댓글을 달아 주세요

2007. 6. 17. 13:59
사용자 삽입 이미지

SOA 성숙도 모델을 표시 하며 CMM 의 5레벨과 비교 가능하다.
자세한 자료는 아래의 PDF를 참조 가능하며



관련된 IBM의 자료의 Link는 아래와 같다.
http://www-128.ibm.com/developerworks/kr/library/ws-soa-method2/


sonic의 ESB에 대한 마케팅 자료이지만 ESB가 무엇을 주로 하는지 잘 나와있다.
IBM의 자료와 비교하여 보면 좋을듯...
나름대로 간단하게 잘 표현했지만 mediation에 대한 글이 약하다는 느낌이 든다.
http://www.sonicsoftware.com/products/docs/sonic_esb.pdf


[ 출처 : http://itgs.tistory.com/tag/CMM ]
Posted by 열라착한앙마

댓글을 달아 주세요

2006. 10. 9. 00:59
저자: 박지훈
출처: 누가 소프트웨어의 심장을 만들었는가 (박지훈 저 / 2005년 3월 출간)


프레드릭 브룩스 ( 1931 ~ 현재 )


개발 기간이 지연되는 소프트웨어 프로젝트의 관리자가 있다. 그는 원래 의도한 날짜에 프로젝트를 마치기 위해 더 많은 인력을 추가했다. 그 결과는 어떻게 되었을까? 지금도 수 많은 프로젝트 관리자가 고민하고 있는 이 질문에 대해 프레드릭 브룩스는 이미 1975년에 답을 했다. 그 답은 소프트웨어 공학이 필요하고 유용하다는 사실을 널리 인식시켰다.


소프트웨어 프로젝트 관리자의 고전 필독서로 오랫동안 사랑 받는 책이 있다. 1975년 프레드릭 브룩스가 지은 “ The Mythical Man Month”는 소프트웨어 개발의 공학적 원리들을 소개하였는데 이들 중 어떤 것은 그 당시 개발자의 기본 상식에서 벗어난 새로운 발상이었다. IBM에서 거대한 운영 체제를 직접 개발하면서 겪게 된 경험을 근간으로 소프트웨어 개발에서 자주 발생하는 문제들을 논리적으로 풀어낸 이 책의 내용은 소프트웨어 공학의 중요한 기준점이 되었다.

IBM에서 운영체제를 개발하다.

1931년에 미국에서 태어난 프레드릭 브룩스는 듀크대를 졸업하였다. 1956년에 하바드 대학에서 컴퓨터 응용 수학(Applied Mathematics)을 전공하여 박사 학위를 받는다. 하워드 아이켄(Howard Aiken)이 그의 스승이었다. 아이켄은 IBM의 하버드 마크 1(Harvard Mark 1) 컴퓨터의 핵심 개발자였다. 그의 영향으로 브룩스는 1956년에 IBM으로 입사하게 된다. 거기서 스트레치(Stretch)와 하비스트(Harvest)라는 컴퓨터들의 아키텍처를 설계하는 일을 하게 된다. 그는 곧 System/360 시리즈에서 동작하는 운영 체제인 OS/360 을 개발하는 프로젝트의 관리자가 된다. 이 시스템을 개발하는 과정에서 얻은 통찰력으로 소프트웨어 공학 분야에 길이 남는 명저를 저술하게 된다.

System/360(S/360) 시리즈는 아키텍처와 구현이 깔끔하게 분리된 최초의 메인 프레임 컴퓨터 시리즈였다. 시리즈의 아키텍트는 진 암달(Gene Amdahl)이었다. 이 시리즈에 속하는 컴퓨터들은 낮은 사양에서 높은 사양으로 업그레이드가 가능하였기 때문에 기업으로부터 많은 인기를 얻게 된다. IBM은 이 시스템에 50억 달러라는 엄청난 비용을 투자했다. 당시 미국에서 가장 높은 비용을 투입한 프로젝트는 아폴로 달 탐사 프로젝트였고 2위가 IBM의 System/360 프로젝트였다고 하니 IBM이 이 프로젝트에 얼마나 관심이 있었는지 알 수 있다.

System/360의 하드웨어가 완성되자 이제는 운영 체제가 필요했다. 따라서 OS/360이라는 운영체제가 배치 처리(Batch Processing)의 용도로 개발되었다. 그런데 이 운영체제는 예상 기간보다 늦게 개발 되었다. 기술적인 어려움 외에 IBM이 소프트웨어 분야에 대규모로 프로젝트를 진행한 경험이 부족했고 개발 조직들간에 불협화음이 있었기 때문이었다. 원래 1966년에 간단한 버전이 출시되어야 했으나 1967년까지 릴리즈 1.0은 생산되지 못했다. 1년 이상 프로젝트가 지연된 것이다. 따라서 IBM은 임시로 BOS(Basic Operating System), TOS(Tape Operating System), DOS(Disk Operating System)을 개발하고 System/360 시리즈에 탑재 시킨다.

OS/360 프로젝트가 지연되면서 프로젝트 관리자인 프레드릭 브룩스는 큰 교훈을 얻게 된다. 그리고 자신이 기존에 경험한 프로젝트의 지식들과 OS/360에서 얻는 통찰력을 기반으로 1975년 “The Mythical Man Month”라는 명저를 저술한다.

전설이 된 소프트웨어 공학의 클래식, “The Mythical Man Month”

그는 이 책에서 당시 시대 상황에는 매우 파격적인 소프트웨어 공학의 원리들을 소개하였다. 그 중 특히 인상적인 것은 책의 제목과 관련이 있다. “Man Month의 신화”가 바로 그것이다. “Man Month(M/M)”란 특정 기간에 프로젝트에 투입되는 인력의 수량을 월 기준으로 나타낸 것이다. 만약 어떤 프로젝트에 한 사람이 12개월 동안 참여했다면 그 프로젝트의 Man Month는 12이다. 만약 두 사람이 참여했다면 24이다. 브룩스는 OS/360 프로젝트가 인력을 더 투입했는데 오히려 더 지연되자 그 이유를 깊이 고민하다가 인력 투입과 개발 기간 간의 상관 관계를 알아냈다.

만약 어떤 개발자가 마이크로소프트사의 파워포인트와 같이 복잡한 프로그램을 만든다고 가정해보자. 아마도 매우 능력있는 프로그래머 1명이 일년동안 프로그램을 분석하고 설계하고 코딩하고 테스트할지 모른다. 이럴 경우 이 프로젝트는 12 Man Month의 노력이 투입된 것이다. 그런데 프로젝트 관리자는 타사의 경쟁 제품이 두 달 후에 출시될 예정이라는 불행한 소식을 듣게 된다. 해법은 무엇일까? 1975년 당시 브룩스를 제외한 대부분의 프로젝트 관리자들은 이렇게 말했을 것이다. “12명의 뛰어난 프로그래머를 스카우트하고 일을 12등분해서 그 사람들에게 나눠 주십시오. 그리고 한 달 안에 일을 마치라고 주문하면 아마 해결될 것입니다. 왜냐하면 12명이 한달 동안 일을 하니까 한 명이 12개월 일하는 것과 동일한 12 Man Month가 투입되었기 때문입니다.”

하지만 브룩스는 다른 결론을 얻었다. “지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.” 일명 브룩스의 법칙(Brook’s Law)이다. OS/360을 개발하면서 브룩스는 “1 개발자 * 12 개월 == 12 개발자 * 1 개월”이 아니라는 것을 몸소 깨달았다. 개발자를 추가하면 할수록 그들 사이에 미팅, 인터페이스 합의, 이메일 송수신 등과 같은 커뮤니케이션 비용이 월등히 증가하기 시작했다. 또한 커뮤니케이션 오류로 일이 잘못 진행되는 경우도 빈번히 생겼고 그럴 때마다 원상태로 수정하는 추가 작업들이 발생하였다. 이런 요인으로 추가 인력이 투입될수록 프로젝트가 지연되는 현상을 겪게 된 것이었다. 전문적으로 말하면, 개발자가 N명이라면 N만큼 개발자가 일하는 양이 늘어나지만 N의 제곱만큼 프로젝트가 복잡해지기 때문에 결국 시간 내에 일을 끝낼 수 없다는 것이다.

따라서 지연되는 프로젝트를 원래 스케쥴대로 진행하려면 인력을 더 추가하는 것이 아니라 “개발하기로 약속했지만 아직 완성되지 못한 기능”을 없애는 것이 합리적인 방법이며 프로젝트의 범위(scope)를 조절함으로서 스케쥴을 제어해야 한다고 주장했다.

브룩스의 법칙 외에 “두번째 시스템 효과(Second System Effect)”, “프로토타입(prototype)”, “커뮤니케이션(Communication) 중시” 등의 원리들은 30년이 넘는 지금 들어도 충분히 공감되는 소프트웨어 공학의 원리를 제시했다.

“두번째 시스템 효과”란 엔지니어가 두번째로 만드는 시스템은 가장 위험한 시스템이 될 수 있다는 가설이다. 왜냐하면 첫번째 시스템을 작고 성공적으로 개발했던 경험이 있는 엔지니어는 두번째 시스템에서는 그 성공을 뛰어넘을 욕심으로 추가 기능을 많이 포함한 공룡 같은 시스템을 만들려는 경향이 있기 때문이다. 브룩스는 성공적인 IBM 70XX 시리즈의 운영 체제 이후에 OS/360을 개발하면서 그 사실을 깨닫게 되었다. OS/360 은 공룡과 같은 두번째 시스템이었다. 이것은 시스템을 유지보수하면서 확장시켜 나갈 때도 발생될 수 있는 문제이다.

“프로토타입”은 새로운 종류의 시스템을 개발할 때는 프로토타입(prototype)을 먼저 만들어서 기능과 성능을 시험을 해 본 후 버리고, 두번째로 더 좋은 시스템을 새롭게 만들어 고객에게 주자는 것이다. 이렇게 하면 좀 더 품질이 좋은 시스템을 고객에 전달할 수 있다고 주장하였다.
“커뮤니케이션 중시”란 팀은 가능한 다양한 방식으로 의사소통을 원활히 하고 명확히 해야 프로젝트에서 발생 가능한 재앙을 미리 막을 수 있다는 원리이다. 애매한 일은 반드시 매니저에게 확인 받고 진행해야 틀리게 생각했던 작업들의 진행을 방지하여 재작업의 요소를 제거해야 한다는 것이다.



은총알은 없다.(No Silver Bullet) 진정?

브룩스는 1987년에 “은총알은 없다(No Silver Bullet)”라는 소프트웨어 엔지니어링 에세이를 발표했는데 많은 논쟁을 불러 일으켰다. 이 글은 1995년에 출간된 “The Mythical Man Month”의 20주년 기념 서적에 포함되기도 하였다. 그는 소프트웨어 개발 생산성을 한번에 해결해 줄 만한 은총알과 같은 기술이나 개발 방식은 더 이상 없을 것이라고 선언했다. 하드웨어의 발전속도를 소프트웨어 개발 속도가 따라 잡지 못하는 현실을 소프트웨어의 복잡성과 관련해서 설명하였다. 소프트웨어 개발의 복잡도는 두 가지 종류가 있는데, 첫번째로는 제거가 가능한 비본질적(accident)인 복잡성이 있다. 이것은 소프트웨어 개발 방식이나 기술 자체가 덜 성숙하거나 잘못된 경우에 생긴다. 이런 복잡도는 IT 과학자들이 노력하면 복잡성을 제거할 수 있다. 예를 들어 불편한 어셈블리 언어 때문에 개발 생산성이 떨어진다면 C나 자바와 같은 고급 언어를 개발하면 해결된다.. 두번째로는 본질적(essential)인 복잡도가 있다. 브룩스는 풀어야 할 문제 자체가 복잡하다면 그 문제가 사라지지 않는 이상은 복잡도는 줄 지 않는다고 주장했다. 시간이 가면 갈수록 고객들은 복잡한 기능들을 요구할텐데 이런 요구 자체는 단순화될 수 없다는 것이다.. 본질적인 복잡도는 대폭 완화될 수 없기 때문에 소프트웨어 개발 생산성을 높이는 정도에는 한계가 있다는 것이다. 객체 지향이나 재사용 등은 이런 본질적인 복잡성을 줄이지 못하는 실패한 은총알이라 주장했다. 그의 글은 많은 소프트웨어 공학자들이 소프트웨어 생산성을 향상시키기 위해 근본적으로 해결되어야 할 선행 이론들에 대해 관심을 갖게 만들었다.

이 주장은 많은 논쟁을 불러 일으켰고 브래드 콕스(Brad Cox)는 “No Silver Bullet Revisited”라는 에세이에서 브룩스가 말한 본질적인 복잡성도 비본질적인 복잡성들로 분리하여 해결하면 충분히 생산성을 높일 수 있다는 반론을 제기하였다.

누가 소프트웨어의 심장을 만들었는가



인간의 편에 선 소프트웨어 개발의 원리

위의 내용에서 보다시피, 그는 개발자들의 심리와 개발 문화, 커뮤니케이션을 기반으로 소프트웨어 프로젝트의 성과를 분석한 선구자였다. 브룩스의 법칙은 개발자들이 증가할수록 커뮤니케이션의 복잡도가 증가하여 프로젝트의 복잡도가 증가한다는 사실을, “두번째 시스템 효과”는 성공적인 시스템의 후속작을 만들때의 엔지니어의 과대 욕망이 일으키는 프로젝트 실패의 요소를, “커뮤니케이션의 중요성”은 커뮤니케이션 오류로 인해 발생하는 프로젝트의 지연 요소를 지적하고 있다. 브룩스는 단지 뛰어난 능력을 가진 사람들의 노력만으로는 프로젝트를 성공시킬 수 없다는 사실을 객관적인 자신의 경험으로 입증하였다. 기술이 아니라 인간의 편에서 소프트웨어 프로젝트를 투시했다.

그의 성과는 이어지는 소프트웨어 공학 이론들에 큰 영향을 끼쳤다. 베리 보엠의 소프트웨어 개발의 경제학에는 생산성 변수로서 인간의 요소들이 포함되었고, 제럴드 와인버그(Gerald Weinberg)는 인간의 심리학에 근거한 소프트웨어 개발 문화를 역설했으며 켄트 벡은 인간의 용기를 프로그래밍의 주요 덕목으로 내 세운 XP를 개발하였다.

그가 세운 소프트웨어 공학의 원리들은 소프트웨어 프로젝트를 면밀히 관찰하여 데이터를 수집하고 분석하여 공학적인 원리들을 세우는 소프트웨어 공학이라는 학문이 하드웨어의 속도를 못 따라 잡는 소프트웨어의 개발에 꼭 필요하다는 웅변하였다.

안타깝게도 그는 가상 세계에 관심이 많다.

1965년 IBM을 떠난 그는 North California, Chapel Hill 대학에 컴퓨터 공학과를 세우고 교수가 되었다. 지금까지 20년 동안 활발한 연구를 진행하고 있으며 현재 3차원 인터액티브 컴퓨터 그래픽과 가상 세계(Virtual World), 원자 그래픽(Molecular Graphics)에 관심이 많다. 안타까운 것은 그가 소프트웨어 공학이 아니라 가상 세계에 연구를 집중하고 있다는 것이다. 1975년에 보인 그의 통찰력을 현재의 소프트웨어 공학에서도 찾아 볼 수 있었으면 하는 아쉬움이 있다.

그는 운영 체제의 발전과 소프트웨어 공학에 기여한 공로로 1999년에 튜링상을 수상하였다.


“소프트웨어 공학(Software Engineering)”이라는 용어는 1968년 NATO 소프트웨어 공학 컨퍼런스에서 공식화되었고 그때 이후로 널리 사용되고 있다. 소프트웨어 공학의 정의는 다양하지만 IEEE Std 610-1990에서 정의한 것은 다음과 같다[4].
“(1) 소프트웨어의 개발, 운영, 유지보수를 할 때 체계적, 규율적, 정량적인 접근 방식을 응용한 것(The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software)
(2) (1)에 대한 연구”



관련 인물들
1) 베리 보엠

참고 자료
[1] 프레드릭 브룩스의 “Man Month 의 신화”
Frederic P. Brooks, “The Mythical Man Month : Essays on Software Engineering”, Addsion-Wesley, 1975 (1995년에 20주년 기념판이 출간됨)
[2] 프레드릭 브룩스의 “은총알은 없다” 원문
[3] 브래드 콕스의 “’은총알은 없다’를 재고하며” 원문
[4] IEEE의 The Software Engineering Body of Knowledge(SWEBOK)
[5] 위키피디아의 프레드릭 브룩스 페이지
[6] 프레드릭 브룩스 홈페이지


[ 참고 : 한빛 네트워크 ]
Posted by 열라착한앙마

댓글을 달아 주세요

2006. 10. 8. 23:52

SPICE(Software Process Improvement Capability dEtermination) 소개  

 ●  SPICE의 공식 홈페이지(http://www.sqi.gu.edu.au/spice/)

 ●   등장배경
 CMM, Trillium, Bootstrap 등과 같은 기존의 소프트웨어 프로세스 평가 모델은 조직의 규모나 유형에 따라 적용의
 범용성이 부족하고, 지역적 표준으로 국제적 합의를 얻기가 힘들다는 점을 착안하여 소프트웨어공학 표준화 그룹
 인 ISO/IEC JTC1/SC7은 1992년에 소프트웨어 프로세스 평가를 목적으로 SPICE라고 부르는 프로젝트를 만들었
 다. 1998년에는 국제표준 승인 전 최종단계인 "Type 2" 규격이 발표되었고, 2002년에 비로소 ISO 15504로써 국제
 표준으로 승인되었다. .

 ●  SPICE의 2차원 평가 모델
 
SPICE의 2차원 평가 모델은 프로세스 차원과 수행 능력 수준 차원으로 이루어 진다.

      / 프로세스 차원(Process Dimension)
5개 프로세스 범주의 40개 프로세스에 대해 기본 프랙티스(Practices)의 실행 여부와 작업 산출물 유무로 판정한다.

      (1) 고객-공급자 프로세스 범주 (10개 프로세스)
소프트웨어를 개발하여 고객에게 전달하는 것을 지원하고, 소프트웨어를 정확하게 운용하고 사용하도록 하기 위한 프로세스로 구성되어 있다.

      (2) 공학 프로세스 범주 (9개 프로세스)
시스템과 소프트웨어 제품을 직접 명세화, 구현, 유지 보수하는 프로세스로 구성되어 있다.

      (3) 지원 프로세스 범주 (8개 프로세스)
소프트웨어 생명주기에서 다른 프로세스에 의해 이용되는 프로세스로 구성되어 있다.

      (4) 관리 프로세스 범주 (4개 프로세스)
소프트웨어 생명주기에서 프로젝트 관리자에 의해 사용되는 프로세스로 구성되어 있다.

      (5) 조직 프로세스 범주 (9개 프로세스)
조직의 업무 목적을 수립하고, 조직이 업무 목표를 달성하는데 도움을 주는 프로세스로 구성되어 있다.

[그림 1 : 프로세스 차원]

     / 프로세스 수행 능력 수준 차원(Process Capability Dimension)
능력 수준별 구분된 프로세스 수준으로 표현하며 6개 능력 수준이 있다.

      (1) 수준 0 - 불완전 단계(Incomplete)
프로세스가 구현되지 않았거나 프로세스가 그 목적을 달성하지 못한다.

      (2)수준 1 - 수행 단계(Performed)
프로세스가 정의된 산출물을 산출한다.

      (3)수준 2 - 관리 단계(Managed)
정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도한다.

      (4)수준 3 - 확립 단계(Established)
소프트웨어 공학 원칙(Principles)에 기반하여 정의된 프로세스가 수행된다.

      (5) 수준 4 - 예측 단계(Predictable)
프로세스가 목적달성을 위해 통제되고 양적인 측정을 통해서 일관되게 수행된다.

      (6) 수준 5 - 최적화 단계(Optimizing)
프로세스 수행을 최적화하고, 지속적으로 업무 목적을 만족시킨다.

[그림 2 : 프로세스 수행 능력 수준 차원]

 ●  프로세스 속성(Process Attributes)

 표1은 SPICE의 프로세스 속성을 설명하고 있다.

[표1: 프로세스 속성]

수준

프로세스 속성

내용


수준 1


1.1 프로세스 수행


프로세스의 목적을 만족시키는 각종 산출물을 생산하기 위해 프로세스가 수행될 때, 프랙티스(Practices)를 사용하는 정도


수준 2


2.1 수행 관리


프로세스의 목적을 만족시키는 각종 산출물을 생산하기 위해 프로세스가 수행될 때, 프랙티스(Practices)를 사용하는 정도


2.2 작업 산출물 관리


작업산출물이 품질목표에 따르고, 문서화되고 통제되면서 요구사항을 만족시키는 작업산출물을 생산하기 위해 프로세스가 관리되는 정도


수준 3


3.1 프로세스 정의


프로세스가 조직의 표준 프로세스에 기반을 둔 프로세스 정의를 사용하는 정도


3.2 프로세스 자원


프로세스가 업무 목적에 효과적으로 기여할 수 있는 적절한 인적 자원과 프로세스 하부 구조를 사용하는 정도


수준 4


4.1 프로세스 측정


프로세스가 목적 달성에 기여하고 있다는 것을 확인할 수 있도록 목적과 척도를 사용하는 정도


4.2 프로세스 통제


프로세스 목적을 반드시 달성할 수 있도록 필요 시 프로세스의 수행을 통제하고 정정하기 위해 척도의 수집과 분석을 통해 프로세스가 통제되는 정도


수준 5


5.1 프로세스 변경


프로세스의 정의, 관리, 수행에 대한 변경이 조직의 업무 목적을 달성하기 위해 더 잘 통제되는 정도


5.2 계속적 개선


조직의 정의된 업무 목적 달성에 있어서 계속적인 향상이 일어날 수 있도록 프로세스의 변경이 식별되고 구현되는 정도


Posted by 열라착한앙마

댓글을 달아 주세요

  1. BlogIcon 2006.10.10 14:16 신고  댓글주소  수정/삭제  댓글쓰기

    스파이스 걸스 가 생각 나는군

  2. BlogIcon homemade anal dildo 2008.03.13 05:54  댓글주소  수정/삭제  댓글쓰기

    관심을 끌. 너가 동일할 좋을 지점을 다시 배치할 것 을 나는 희망한다.