* Rapid software development
- 요즘에는 소프트웨어를 빠르게 개발해야할 사항이 많아졌다.
Because, 사업환경의 변화가 빠르기 때문에 이에 대응하여 요구사항이 지속적으로 변하기 때문에
- 명세, 디자인, 구현의 경계를 없엔다.
- System version을 여러개로 나눠서 구현을 한다.
- IDE(Interactive Development System) tool등을 이용해 UI를 자동 생성한다.
* Agile methods
- 설계보다 코드(소스)에 중점을 둔다.
- 반복적인 접근 방법으로 나눠서 개발을 한다.
- 빠르게(빠른 기간내에) 돌아가는 Software를 만든다.
- Principles(원리)
> 고객을 개발에 참여 시킨다.
> Incremental delivery
> 별도의 process를 강제하지 않고, 자산의 방법대로 개발하게 둔다.(기간만 지정해준다)
> 변화를 받아들인다. 변화에 대한 예상을 예측하면서 개발한다.
> 단순하게 모든일을 행하라. (단순함을 유지하라)
- 특징
> 작거나 중간 규모의 프로젝트나 특정고객을 대상으로한 시스템 개발에 적합
> 고객이 직접 개발 과정에 참여가능해야 하며 SW변경 가능성이 작은 경우에 적합
* Extreme programming(XP)
- Agile method의 하나의 프로그래밍 모델이다.
- extreme의 의미
> 한 소프트웨어에 대한 버젼이 하루에 여러개 나올 수 있다.
> 매 2주(Optimal length)에에 한번식 고객과 접촉을 하며 회의를 한다.
> 고객에게 보여주거나 넘겨줄 것은 모두 Test가 되있어야 한다.
- Extreme programming의 원리 및 조언
> Incremental planning (점진적 계획) : 중요도에 따라 해당 release에 포함될 story를 결정, task단위로 나눔
> Small releases : 작은 규모로 여러번 버젼업을 한다.(Optimal length인 2주안에 가능한 일 단위로 나눔)
> Simple design : 간단하게 디자인해라.
> Test-first development : 개발을 하기전에 test부분을 구현해라.
> Re-factoring : 지속적으로 프로그램 구조를 리뉴얼 한다. class 계층재조직, 중복 코드제거, 속성 이름변경 등
> Pair Programmings : 한 프로그램당 짝을 이뤄서 개발을 해라.
> collective ownership : 서로의 프로그램을 약간씩 겹치고 공유하게 하라. 사고에 대한 대처가 필요하다.
> continuous integration : Task 개발이 되면 될때마다 합친다.
> sustainable pace : 무리하지 말고 꾸준하게 자신의 상태를 유지하라.
> On-site customer : 고객또한 같이 개발에 참여해야한다.
- Testing
> 구현전에 test수행 프로그램을 만든다.
> 각각의 task에 tool을 적용하여 test program을 만든다.
이 프로그램들을 test harnesses 위에 올려 돌아가면서 test 한다.
- 요즘에는 소프트웨어를 빠르게 개발해야할 사항이 많아졌다.
Because, 사업환경의 변화가 빠르기 때문에 이에 대응하여 요구사항이 지속적으로 변하기 때문에
- 명세, 디자인, 구현의 경계를 없엔다.
- System version을 여러개로 나눠서 구현을 한다.
- IDE(Interactive Development System) tool등을 이용해 UI를 자동 생성한다.
* Agile methods
- 설계보다 코드(소스)에 중점을 둔다.
- 반복적인 접근 방법으로 나눠서 개발을 한다.
- 빠르게(빠른 기간내에) 돌아가는 Software를 만든다.
- Principles(원리)
> 고객을 개발에 참여 시킨다.
> Incremental delivery
> 별도의 process를 강제하지 않고, 자산의 방법대로 개발하게 둔다.(기간만 지정해준다)
> 변화를 받아들인다. 변화에 대한 예상을 예측하면서 개발한다.
> 단순하게 모든일을 행하라. (단순함을 유지하라)
- 특징
> 작거나 중간 규모의 프로젝트나 특정고객을 대상으로한 시스템 개발에 적합
> 고객이 직접 개발 과정에 참여가능해야 하며 SW변경 가능성이 작은 경우에 적합
* Extreme programming(XP)
- Agile method의 하나의 프로그래밍 모델이다.
- extreme의 의미
> 한 소프트웨어에 대한 버젼이 하루에 여러개 나올 수 있다.
> 매 2주(Optimal length)에에 한번식 고객과 접촉을 하며 회의를 한다.
> 고객에게 보여주거나 넘겨줄 것은 모두 Test가 되있어야 한다.
- Extreme programming의 원리 및 조언
> Incremental planning (점진적 계획) : 중요도에 따라 해당 release에 포함될 story를 결정, task단위로 나눔
> Small releases : 작은 규모로 여러번 버젼업을 한다.(Optimal length인 2주안에 가능한 일 단위로 나눔)
> Simple design : 간단하게 디자인해라.
> Test-first development : 개발을 하기전에 test부분을 구현해라.
> Re-factoring : 지속적으로 프로그램 구조를 리뉴얼 한다. class 계층재조직, 중복 코드제거, 속성 이름변경 등
> Pair Programmings : 한 프로그램당 짝을 이뤄서 개발을 해라.
> collective ownership : 서로의 프로그램을 약간씩 겹치고 공유하게 하라. 사고에 대한 대처가 필요하다.
> continuous integration : Task 개발이 되면 될때마다 합친다.
> sustainable pace : 무리하지 말고 꾸준하게 자신의 상태를 유지하라.
> On-site customer : 고객또한 같이 개발에 참여해야한다.
- Testing
> 구현전에 test수행 프로그램을 만든다.
> 각각의 task에 tool을 적용하여 test program을 만든다.
이 프로그램들을 test harnesses 위에 올려 돌아가면서 test 한다.