named.ca
========================================================
ftp://ftp.rs.internic.net/domain으로 접속한다.
named.cache 파일을 받아서 확장자를 named.ca로 바꿔준다.
접속이 잘 되지 않으면 첨부 파일을 사용한다.

named.zip - Last update : 2004년 01월 28일 ← 첨부파일========================================================

☆ named.conf
- 빨간색 부분을 변경하여 저장
========================================================
options {
directory "c:\dns\etc"; <- 설치 경로명
};

zone "." IN {
type hint;
file "named.ca"; 
};
zone "localhost" IN {
type master;
file "scmlab.zone";
allow-update {none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update {none; };
};
key "key" {
algorithm hmac-md5;
secret "+vjvsrwnJ54fRgQjDqxe+A=="; <-rndc.key 에서 생성 된 값 입력
};
zone "scmlab.com" IN {  <-자신이 사용할 도메인 이름 저는 scmlab.com 으로 설정
type master;
file "scmlab.zone";
allow-update {none ;};
};
zone "24.241.203.in-addr.arpa" IN { <-IP주소 ex; 203.241.24.78 인 경우
type master;
file "scmlab.rev";   <- 도메인 이름
allow-update {none; };
};
========================================================


☆ named.local
- default 값으로 저장
========================================================
$ORIGIN .
$TTL 1D
localhost 86400 IN SOA localhost. local.localhost. (
    2001061401 ;Serial
    28800  ;Refresh (8 hours)
    7200  ;Retry (2 hours)
    604800  ;Expire (1 week)
    86400  ;Minimum (1 day)
                                )
IN NS localhost.     
IN A 127.0.0.1
========================================================


☆ scmlab.zone
- 빨간색 부분을 변경하여 자신의 도메인 이름.zone으로 저장
========================================================
$TTL 43200
@  IN SOA ns.scmlab.com. root.scmlab.com.(     <- 자신의 도메인명, 끝에 콤마 주의
   20010504 ;Serial
   10800  ;Refresh
   3600  ;Retry
   3600000  ;Expire
   43200 )  ;Minumum
IN NS ns.scmlab.com<- 자신의 도메인명, 끝에 콤마 주의
IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
IN HINFO "Intel Pentium" "Windows XP"
ns  IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
www  IN A 203.241.24.78 <-IP주소 ex; 203.241.24.78 인 경우
========================================================


☆ scmlab.rev
빨간색 부분을 변경하여 자신의 도메인 이름.rev으로 저장
========================================================
$TTL 43200
@  IN SOA ns.scmlab.com. root.scmlab.com.(    <- 자신의 도메인명, 끝에 콤마 주의
   20010504 ;Serial
   10800  ;Refresh
   3600  ;Retry
   3600000  ;Expire
   43200 )  ;Minumum
IN NS ns.scmlab.com<- 도메인명, 끝에 콤마 주의
78  IN PTR scmlab.com<- 자신의 도메인명, 끝에 콤마 주의
========================================================

위의 파일들을 생성 후 bind9를 실행시키면 됩니다.


출처 : 리룩스포털

출처 : http://gag.aaa.tohttp://gagstory.aaa.to

'Programming > tool' 카테고리의 다른 글

04) named.ca, localhost.zone, named.local 파일 만들기  (0) 2010.03.19
03) named.conf 파일 만들기  (0) 2010.03.19
01) XP에 DNS 설치  (0) 2010.03.19
IIS, FTP 설치  (0) 2010.03.19
VS2008로 작성한 프로젝트를 VS2005열기  (0) 2010.03.18

☆ 1. 다운로드(http://www.isc.org)
- 아래 그림처럼 윈도용 최신버전을 다운받는다.

dns01.jpg

- BIND9.3.2.zip를 다운받았으면 압축을 풀고 폴더를 확인한다.다음과 같을 것이다.
dns02.jpg


☆ 2. 설치
- BINDinstall.exe를 실행시킨다.

dns03.gif
① 설치할 경로를 지정한다. 없다면 생성할것인가라는 창이뜬다. 필자는 C:\dns로 지정했다.
② 패스워드를 적는다..솔직히 왜 적는지 모르겠다. 3번은 확인차 적는것이다.
④ install을 클릭하면 자동으로 설치가 완료된다.


☆ 3. 설정
- 설치후 c:\dns 폴더를 확인하면 bin과 etc폴더가 생성되어 있음을 알수있다.
dns04.gif
- bin 폴더에는 프로세서를 실행할수 있는 파일들이 있고, etc 폴더는 비어있다.
- 이상태로는 아무것도 실행을 할 수 없다.
- 기본적으로 local.zone named.conf 파일과 domain.zone 파일 domain.rev파일 named.ca파일은 존재해야한다.
- 필자는 위 파일 모두를 etc폴더에 위치시켰다.
- 어떤 경로에서 프로세서를 실행할 수 있도록 Path에 C:\dns\bin 을 추가하자.

[path추가]
- 시스템등록정보 -> 고급 -> 환경변수로 들어간다.
- 편집클릭
dns05.gif

- 다음을 추가한다.
dns06.gif
- 확인 -> 확인 -> 확인
- 이젠 도스창 어느경로에서든 DNS관련 프로세서를 실행시킬 수 있다.


[etc 폴더 살펴보기]
- 여기까지 필자의 폴더를 한번 살펴보겠다.
- bin 폴더는 설치때 생성된것이라 모두 같을 것이다.
- etc 폴더에는 필자가 5개의 파일을 생성했다.
5개의 파일 생성 샘플 보기
Snap21.png

[rndc.key생성 rndc.conf설정]
- rndc.key 생성
- 시작 -> 실행 -> cmd 도스창을 띄운후 아래와 같이 실행한다.


Snap2.png
- rndc-confgen 까지는 띄우지 말고 붙여서 작성하고 -a 는 한칸 띄워서 적는다.

- rndc.conf 생성

Snap5.png

- 위와 똑같이 rndc-confgen > c:\dns\etc\rndc.conf 를 적어 준다.


- c:\dns\etc 폴더에 rndc.key와 rndc.conf 가 생성되었다.

Snap3.png 


-rndc.key를 메모장으로 열어보자.

Snap4.png

-밑줄친 부분을  named.conf에 넣어 주면 된다.


☆ 4. 실행
모든 설정이 완료된 후에 실행을 한다. (5개의 파일 생성 샘플 보기)
- 실행은 아래와 같이 한다.(command창에서)

dns12.gif
- 프로세서가 실행되었는지 확인한다.
dns13.gif

- 윈도우 작업관리자에 네임서버 프로세서가 활성화 되었음이 확인된다.
- 모든것이 이상없이 실행이 되었다.


☆ 5. 기타
- zone파일과 zone.rev파일을 잘 설정하면 여러가지 도메인을 사용할 수 있을것이다.
- 위 두 파일에 서브도메인을 추가한 후 프로세서를 다시 시작하려면...
- 이때 rndc를 사용하면 아주 편리하다.
- 네임서버가 가동된 상태에서 프로세서를 다시구동하려면 rndc reload 해주면 만사 OK

[rndc reload]
dns14.gif
- 위와 같이 server reload successful 메세지가 출력되면 새로운내용이 적용된 것이다.
- 이렇게 해서 모든 설명이 끝났다.


☆ 6. 프로세서 서비스 설정
- 시스템이 시작하면 프로세서가 자동으로 작동되어야 한다.
- DNS서버를 인스톨할때 서비스에 자동으로 ISC BIND가 등록이된다.


dns15.gif

- 현재는 서비스가 중지된 상태이다.

- 서비스를 자동 시작되도록 설정한다.
dns16.gif

- 로컬 시스템 계정 선택한다.
dns17.gif

- 서비스 시작 클릭
dns18.gif

- 서비스가 자동 시작으로 설정된것을 확인한다.

dns19.gif
- 시스템을 재시작후 윈도우 작업관리자에 named.exe 프로세서가 가동중임을 확인한다.



출처 : welchsjam blog

출처 : http://gag.aaa.tohttp://gagstory.aaa.to

'Programming > tool' 카테고리의 다른 글

03) named.conf 파일 만들기  (0) 2010.03.19
02) [DNS for XP] BIND9에서 named.conf, zone 파일 설정  (0) 2010.03.19
IIS, FTP 설치  (0) 2010.03.19
VS2008로 작성한 프로젝트를 VS2005열기  (0) 2010.03.18
Visual Studio 2008 설정  (0) 2010.03.18

사용자 요구조건 조사

조사 단계는 시스템의 모습과 임무를 파악하는 단계이다. 이 단계에서 고객은 시스템의 목표 기술문(vision statement) 작성을 담당한다. 목표 기술문은 20~30 단어 정도로 구성되며 전체적인 시스템 메타포의 개발을 이끌 수 있어야 한다. 고개과 개발자는 이 단계에서 함께 일하면서 기술적 옵션, 요구 사항 분석을 조사하며 유저 스토리의 목록을 완성한다.


목표 기술문은 시스템의 목적을 기술하는 추상적인 문장이다. '이 시스템의 목적은 인터넷을 통해 서적을 판매하는 것이다' 와 같은 것이 그 예이다.
시스템 메타포는 팀에서 시스템을 개념화하는 방식이며 보통 비즈니스 분야의 말들로 쓰여진다. "고객이 들어와서 열람, 검색하고 책을 살 수 있는 가상의 서점" 같은 것이 그 예이다.
유저 스토리는 사용자의 요구 사항을 이해하는 하나의 도구이다. 유저 스토리는 사용 실례 같은 것과 비슷하며, 고객에 의해서 비전문적인 용어로 쓰여진다. 보통의 유저 스토리는 3~4 문장 정도의 길이이다.


유저 스토리 작성하기

프로젝트 시작 단계에서 고객은 중요하고 유저 추상적인 유저 스토리를 작성하고 개발자는 해당되는 개발에 필요한 시간을 추정해 본다. 물론 고객과 개발자 서로가 이 상태에서늬 예측은 상당히 추상적인 것이며 앞으로 개발이 진행되면서 이터레이션 단계에서 상세화될 것이라는 생각을 갖고 있다. 어떤 경우에는 개발자들이 좀 더 자세한 예측을 위해서 스파이킹(spiking - 프로토타이핑이나 기술적 연구)을 하는 경우도 있다. 기술 전문가나 컨설턴트가 추상적 수준에서의 타당성 검토나 관련 연구를 도울 수도 있다. 스파이킹은 단순하지만 개발에 필요한 노력과 방법론을 이해하는 데 커다란 도움이 된다.


스파이킹은 프로토타입을 만들면서 조사하는 것이다. 스파이킹은 일반적인 기술 연구에 시간을 들인다기보다는 특정 목적을 갖고 이루어진다.


스파이킹이 끝나면 개발팀이 그에 대한 지식을 얻게 되는 것이고 스파이킹에 사용된 코드는 버려진다. 스파이킹은 수시간에 이루어질 수도 있지만 보통의 경우에는 수일이 걸리게 된다. 작업이 진전되면서 어려운 문제에 대한 스파이킹을 포기하는 경우도 생기는데 이것은 일반적인 상황은 아니다.


스파이킹 기간에 작성된 코드는 보통 재사용할 만큼 품질이 좋지 못해서 버려지는 것이 일반적이다. 스파이킹을 할 때 개발자는 연구의 일환으로 코드를 작성하는 것이지 특정 디자인에 입각해서 짜는 것이 아니기 때문이다.


추정과 발견(Estimating and Discovering)

조사의 단계는 대부분 발견에 관한 것이다. 고객은 그들이 원하는 것은 발견해가고 개발자는 그들의 문제에 대한 접근 방식을 발견해 가면서 또 스파이킹을 통해서 추정을 해나간다. 스파이킹을 하는 데 필요한 시간을 추정하고 실제 드는 시간과 비교하는 것만으로 간단하게 처리된다. 이렇게 해서 조사 단계에서는 개발팀이 좀더 정밀한 추정 기술을 습득하게 하는 장점도 갖게 된다. 이런 기술은 이후 이터레이션 계획이 시작해지면 아주 중요해진다.


'SE > agile' 카테고리의 다른 글

UML: 클래스 다이어그램 기초  (0) 2010.07.08
Observer Pattern  (0) 2010.06.18
02] XP 개발 주기의 개괄  (0) 2010.03.18
01] XP 정의, 4개 구성  (0) 2010.03.18

XP 개발 주기의 개괄

XP에서의 기본 전제는 고객과 개발자가 함께 진정한 가치를 지닌 소프트웨어를 만들어 나간다는 것이다. 고객은 XP 프로젝트의 개발 주기에 따라서 사업적 가치를 창출해내기 위해서 개발팀에 방향을 제시해 준다. 고객이 프로젝트에 능동적으로 참여하는 것이다.


Snap6.jpg 이 그림은 XP 개발 주기가 지속적으로 가치를 정의하고 만들어 가는 과정임을 보여준다. 이 과정은 이전의 패러다임과 다를 것이 하나도 없어 보인다. 모든 개발에서 고객은 가치를 정의하고 개발자는 가치를 만들어 낸다. XP에서의 차이점은 그런 주기가 매우 짧게 일어난다는 것이다. 개발팀은 새로운 기능을 매 분, 매 시간마다 만들어 낸다. 이것이 고객에게 프로젝트를 보완하고 수정할 수 있는 여지를 제공한다.












단계설명
조사 기간 프로젝트 시작, 추상적 수준의 사용자 요구분석, 기술적인 프로토타이핑
계획 작업의 우선순위 부여, 릴리즈 단위로의 분할, 초기 계획 작성
이터레이션(iteration) 시스템의 개발과 테스트, 2차로 작업을 나누어 이터레이션 계획 수립, 실 사용자가 이 단계에서 ㅇ이너페이스를 개량하고 사용 편의성을 확인하기 위해 일할 수 있다.
제품화 고객의 작업 환경에 소프트웨어를 설치
유지 보수 지속적 유지, 보수, 기능 향상


XP 프로젝트는 고객의 제품에 대한 시각을 우선 릴리즈 단위로 나누고 다시 릴리즈를 이터레이션 단위로 나눈다. 계획 단계는 프로젝트가 진행됨에 따라 점차 상세화, 발전되는 과정으로 인식된다.


Snap2(1).jpg 각각의 이터레이션에서 새 코드를 작성해서 통합될 때마다 build가 이루어지게 된다. 빌드의 수는 사용되는 기술의 종류와 팀에서 채택한 개발 스타일에 따라 다르다. 그렇다면 릴리즈와 이터레이션의 주된 차이점은 무엇인가? 릴리즈 단위가 끝날 때면 개발진은 작동하는 소프트웨어를 고객에게 넘겨주는 반면 이터레이션에서는 개발팀 내부적인 확인만 이루어진다. 이런 식으로 개발팀에 상주하는 고객과 개발자 사이에서 프로젝트의 진행 정도를 확인하고 조절하게 된다.





build는 시스템의 구성요소가 하나로 통합되어서 제대로 작동하는지 테스트하는 과정이다.


[그림 4.3]은 XP 가 가진 이터레이션 중심의 특징을 보여준다. 

Snap3(1).jpg 조사 이후에 개발팀은 릴리즈 계획을 세우고 소프트웨어가 완성되어 제품화 준비를 할 때 까지 이터레이션 작업을 계속하게 된다. 제품화나 각 릴리즈의 종료 시점에서는 소프트웨어가 작업 현장에 투입되어서 테스트된다. 제품화는 그 소프트웨어를 사용하여 실제 사업적 가치를 얻기 시작한다는 점에서 중요하다. 제품화가 이루어진 후의 다른 특성은 이제 제품의 문제로 생기는 비용이 훨씬 커진다는 것이다. 이 때문에 신중한 고객들은 최종 점검 테스트를 한다.




'SE > agile' 카테고리의 다른 글

UML: 클래스 다이어그램 기초  (0) 2010.07.08
Observer Pattern  (0) 2010.06.18
① 사용자 요구조건 조사  (0) 2010.03.18
01] XP 정의, 4개 구성  (0) 2010.03.18

1. XP 정의하기

XP는 4개의 부분, 가치, 원칙, 활동, 기법으로 구성된다. XP는 별도로 고안되었다기 보다는 협동, 작업의 흐름, 시스템 속에서 나타났다고 하는 편이 옳을 것이다. 이런 소프트웨어 개발의 유기적인 관점을 유지하면서 XP는 가치와 원칙들에 기반하여 만들어져서 그로부터 기법과 활동을 고안해냈다.


1) 가치

XP는 개발을 위한 공통의 가치(value)에 의해서 이끌어 진다.

가치설명
단순성 XP에서 단순성은 "동작하는 최대한 단순한 작업을 하는 것"으로 정의된다. 당장의 문제를 가급적 단순하게 해결하고 이후의 문제는 그 때 해결될 것이라고 믿는 것이다. 보통의 방법론들은 어느 정도 앞날을 대비한 계획을 세우고 고객은 전체 시스템에 대해서 예상해 보게 된다. 이런 방법론에 깔린 생각은 이후의 수정이 불가능하지는 않더라도 어려울 것이라는 것이다. XP는 당장 고객이 원하는 것을 하는 것으로 관점을 달리한다. XP 그룹들에서 하는 이야기가 있다. "아마 그건 필요 없을껄" 이것이 의미하는 것은 개발팀은 단순한 생각을 갖고 고객이 필요할 것 같은 것이 아니라 고객이 당장 필요로 하는 것을 구현해야 한다는 것이다. 왜 앞으로 필요할 것 같은 기능에 대해서 미리 디자인하는 걸까? 그것은 이후 수정이 일어날 경우 그 비용이 너무 높기 때문이다. 요약하자면, 단순한 시스템이 커뮤니케이션 비용이 적게 들고 통합이 용이하며 더 나은 확장성을 가지고 있다.
커뮤니케이션 모든 방법론은 내부적으로 커뮤니케이션 과정을 가지고 있지만 XP에서는 특별히 핵심 가치로 존재한다. 커뮤니케이션의 초점은 문서나 보고서, 계획서에 있지 않고 대화에 있다. 모든 팀 구성원간의 커뮤니케이션이 없이는 협업은 약해지고, 결국은 실패할 것이다. XP에는 작업에 커뮤니케이션을 요구하는 짝 프로그래밍 같은 기법을 사용한다. 1장 "XP 가 나오게 된 배경"에서 '이해'가 소프트웨어 개발에 얼마나 커다란 어려움인지에 대해서 이미 이야기했다. XP는 이를 인정하고 팀 멤버간의 장벽을 허물기 위해 노력한다. XP 에서 모든 문서는 사람들간의 커뮤니케이션을 돕는 데 쓰인다.
피드백 XP 에서는 모든 시스템에 대한 계속되는 질문에 대한 대답이 지속적이고 구체적인 피드백에 의해 이루어진다. 제품은 시행착오를 거쳐서만이 검증 될 수 있다. 이것은 엄연한 사실이기 때문에 개발팀은 소프트웨어를 빨리 만들어낸 후, 고객에게 데모를 해야 한다.
용기 용기는 빨리 작업하고, 필요시 다시 개발하겠다는 자신감이다. XP 에서의 용기는 다른 세 가지 가치들과 하나의 문맥에서 생각해 보아야 한다. 그만큼 중요한 것이다. 하지만 XP의 용기는 강력하고 자동화된 테스트에 기반한 대단함이지 모르는 것에 대한 무모한 노력은 아니다.


2) 원칙

XP의 핵심 가치를 바탕으로 소프트웨어 개발에 지침이 될 다섯 개의 주요 원칙(Principle) 이다.

원칙설명
피드백은 신속히 신속한 피드백은 개발자가 짧은 단위로 고객의 피드백을 받아서 고객의 요구를 잘 반영하고 있는지 확인하는 것을 의미한다.
단순함을 전제 단순함을 전제하는 것은 문제를 대할 때 간단히 문제가 풀릴 것이라 생각하라는 것이다. 또 그것은 현재 문제에 집중해서 작업하고 미래의 일에 대해서는 걱정하지 말라는 것을 의미한다.
점진적인 수정 문제를 풀 때의 과정을 작은 교정의 연속이라고 생각하라. 이것은 계획, 개발, 디자인에 모두 적용된다. 예를 들어 고객이 이미 웹 사이트를 가지고 있고, 거기에 JSP를 포팅하고 할 경우 XP 팀은 한번에 완성해서 끝내는 것을 목표로 하기 보다는 사업부에서의 요구에 따라서 여러 차례 소규모의 출시를 할 것이다.
변화의 인정 현존하는 문제를 풀면서 옵션의 여지가 있는 방법을 택하라.
고품질의 작업 작업의 품질은 타협의 대상이 아니다. XP는 테스트 위주 프로그래밍으로 그 무엇보다 코드와 테스트의 중요성을 강조한다


3) 활동

지금까지 가치와 원칙들에 대해 알아보았는데, 그렇다면 실제 XP에서 하는 일은 어떤 것 인가? 몇 가지 XP 사이클에서의 활동(Activity)에 대해 알아보자.

활동설명
듣기 XP는 능동적인 듣기를 요구한다. 형식적인 문서에 대한 의존도가 늦은 대신에 고수준의 구두 커뮤니케이션이 요구된다. 단순히 개발자가 고객의 말에 귀기울여야 한다는 것 이상으로 XP는 보다 나은 커뮤니케이션을 지향한다.  문서에 대한 의존 없이 XP 사용자들은 다른 형태의 구두 의사소통을 익히고 능숙해져야 한다.
테스트 XP에서의 테스트는 고객에게 출시하기 전에 하는 작업이 아니라 개발 전 과정에 걸쳐 일어나는 공정의 일부이다. 심지어 개발자는 코드를 작성하기 전에 테스트를 먼저 작성할 정도이다. XP 테스트는 정확성이나 결점을 측정하는 데 국한되는 것이 아니라 제품의 성능이나 적응도까지 점검한다. 코드를 짜기 전에 테스트를 만드는 것은 개발자에게 생각의 전환을 요구한다. 그 결과로 코드는 비용이 많이 드는 개발의 후반부에 별도의 디버깅 과정 없이 그 자체로 높은 품질을 지니게 된다.
디자인

문서화된 디자인이 적은 대신 XP 개발자는 코드를 작성할 때 의도적으로 그 의미를 표현하려 한다. 소스 코드를 읽는 것만으로 다른 팀의 멤버들은 논리와 알고리즘, 흐름을 이해할 수 있다. 여기서 이야기하는 것은 주석에 대한 이야기가 아니라 소스 코드 그 자체가 커뮤니케이션의 수단이 된다는 것임에 주의하기 바란다. 소스코드는 실제 제품에 우리가 가장 가까이 접근할 수 있는 것 이다.

XP의 기초 아이디어 중 하나는 디자인이 프로젝트 전체에 걸쳐서 발전해 나간다는 것이다. 디자인은 멈추어 있거나 특정 단계에서 이루어지는 것이 아니라 팀 기반의 동적인 것이다. 어떤 면에서 소프트웨어는 언제나 디자인 중이라고 이야기할 수도 있다. 디자인 단계를 제한해서 이런 점들을 무시하는 대신 XP는 자연스런 시스템의 발전을 수용한다.


4) 기법

그렇다면, 어떻게 XP의 활동들을 실행에 옮길 수 있을까? XP는 이들 활동들을 12개의 핵심적인 기법(Practice)으로 표현한다. 이 기법들이 XP팀들이 매일 현장에서 시스템을 개발하는 데 사용하는 것들이다.

번호기법설명
1 계획 짜기 게임 계획 짜기 게임의 역할은 빠른 시간 안에 다음의 출시 계획이나 일정을 빨리 세우기 위한 것이다.
2 짧은 릴리즈 XP 개발 사이클은 사업적 가치를 달성하기 위해 짧은 릴리즈로 이루어진다.
3 메타포 메타포는 프로젝트를 표현하는 데 쓰이는 시각적인 것, 단어, 언어이다.
4 단순한 디자인 디자인은 반드시 단순해야 한다. XP에서의 단순함의 의미는 동작하는 것 중에서 가장 단순해야 한다는 것이다.
5 테스트 XP 개발의 핵심은 자동화된 테스트이다. 개발시에는 가장 먼저 테스트부터 작성해야 하고 테스트 툴에 의해서 사용된다.
6 리팩토링 리팩토링은 시스템 외적 동작의 변화 없이 기존 코드의 디자인을 향상시키는 작업이다.
7 짝 프로그래밍 짝 프로그래밍은 두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 개발작업을 진행하는 것이다.
8 공동 소유 공동 소유는 언제, 누구라도 코드를 수정해서 더 좋게 만들 수 있게 해준다.
9 지속적인 통합 시스템의 부분은 하루에도 수 차례 통합 작업을 거친다.
10 주당 40시간 근무 초과근무가 많은 곳에서는 일괄적인 품질의 유지가 어려워진다. XP는 품질을 위해서 일반 업무시간의 준수를 요구한다.
11 현장의 고객 고객이 현장에 있고 개발팀에 참가한다.
12 코딩 표준 코딩 표준은 모든 개발자가 개발시 지키기로 합의한 약정이다.

아 빡시다. 계속 써놔야한디. 아나ㅋㅋ 언제 다하지...

'SE > agile' 카테고리의 다른 글

UML: 클래스 다이어그램 기초  (0) 2010.07.08
Observer Pattern  (0) 2010.06.18
① 사용자 요구조건 조사  (0) 2010.03.18
02] XP 개발 주기의 개괄  (0) 2010.03.18

+ Recent posts