소프트웨어 프로젝트를 개발하는 방법론에는 20여 가지의 개발 프로세스 모델들이 존재한다. 그러나 모든 소프트웨어의 특성을 만족시킬 수 있는 일반화된 하나의 모델이 없는 실정으로 개발조직은 여러 모델들을 적절히 혼합하여 개발될 시스템과 개발팀의 능력에 맞도록 새로운 모델을 개발하여야만 한다. 본 논문에서는 다양한 소프트웨어 개발 상황에 보다 적합할 것으로 판단되는 동시개발 프로세스 모델을 제안한다. 먼저, 개발 요구사항 목록들이 작성되면, 요구사항을 중요도에 따라 20:80 비율로 분할하고, 중요한 20% 요구사항의 요구사항 분석과 아키텍쳐 설계가 완료될 때까지는 순차적으로 수행한다. 20%의 중요 요구사항에 대해 상세설계를 시작하는 시점에서 나머지 80%의 요구사항에 대한 요구사항 분석단계를 동시에 수행하는 개념이다. 동시개발은 타임박스(Timebox) 개념으로 수행되며, 이때 적용되는 순차적, 반복적 & 점진적 또는 Agile 방법들에 따라 각 타임박스에서 개발되는 요구사항의 분할 비율은 차이가 발생한다. 순차적, 반복적 & 점진적 또는 Agile 방법론을 동시개발 개념을 적용한 결과 단일화된 프로세스 모델로 표현할 수 있었다. 제안된 모델은 개발 단계들을 팀 단위로 수행할 경우 개발자원 활용의 비효율성을 크게 줄일 수 있다. 또한, 동시개발 개념을 적용하여 단계들이 중첩되어 수행되므로 개발기간도 크게 단축시키는 장점이 있다. 따라서 제안된 모델은 보다 빠른 시간에 보다 저렴한 비용으로 보다 좋은 품질의 소프트웨어를 개발하여 고객에게 납품할 수 있어 고객을 만족도를 향상시킬 수 있으며, 더불어 소프트웨어 개발 성공률을 높이는데도 기여할 것으로 판단된다.
소프트웨어 프로젝트를 개발하는 방법론에는 20여 가지의 개발 프로세스 모델들이 존재한다. 그러나 모든 소프트웨어의 특성을 만족시킬 수 있는 일반화된 하나의 모델이 없는 실정으로 개발조직은 여러 모델들을 적절히 혼합하여 개발될 시스템과 개발팀의 능력에 맞도록 새로운 모델을 개발하여야만 한다. 본 논문에서는 다양한 소프트웨어 개발 상황에 보다 적합할 것으로 판단되는 동시개발 프로세스 모델을 제안한다. 먼저, 개발 요구사항 목록들이 작성되면, 요구사항을 중요도에 따라 20:80 비율로 분할하고, 중요한 20% 요구사항의 요구사항 분석과 아키텍쳐 설계가 완료될 때까지는 순차적으로 수행한다. 20%의 중요 요구사항에 대해 상세설계를 시작하는 시점에서 나머지 80%의 요구사항에 대한 요구사항 분석단계를 동시에 수행하는 개념이다. 동시개발은 타임박스(Timebox) 개념으로 수행되며, 이때 적용되는 순차적, 반복적 & 점진적 또는 Agile 방법들에 따라 각 타임박스에서 개발되는 요구사항의 분할 비율은 차이가 발생한다. 순차적, 반복적 & 점진적 또는 Agile 방법론을 동시개발 개념을 적용한 결과 단일화된 프로세스 모델로 표현할 수 있었다. 제안된 모델은 개발 단계들을 팀 단위로 수행할 경우 개발자원 활용의 비효율성을 크게 줄일 수 있다. 또한, 동시개발 개념을 적용하여 단계들이 중첩되어 수행되므로 개발기간도 크게 단축시키는 장점이 있다. 따라서 제안된 모델은 보다 빠른 시간에 보다 저렴한 비용으로 보다 좋은 품질의 소프트웨어를 개발하여 고객에게 납품할 수 있어 고객을 만족도를 향상시킬 수 있으며, 더불어 소프트웨어 개발 성공률을 높이는데도 기여할 것으로 판단된다.
Though a dozen of different software life cycle models are suggested, there is no universal model which can satisfy all the characteristics of software. Organizations mix and match different life cycle models to develop a model more tailored for their systems and capabilities. We suggest overlapped-...
Though a dozen of different software life cycle models are suggested, there is no universal model which can satisfy all the characteristics of software. Organizations mix and match different life cycle models to develop a model more tailored for their systems and capabilities. We suggest overlapped-concurrent development life cycle model that is more suitable in various software development environment. Firstly, we divided the development process into abstract and implementation stage. Abstract stage is from software concept phase to detailed design starting time, and implementation stage is from detailed design phase to system testing phase. Next, the abstract stage introduced the overlapped phase concept that begins the next phase when the step is completed 20% by applying pareto's law. In the implementation stage, we introduced the concurrent development which the several phases are performed some time as when one use-case (UC) is completed the next development phase is started immediately. The proposed model has an advantage that it can reduce the inefficiency of development resource greatly. This model can increase the customer satisfaction with a great product at a low cost and on a short schedule. Also, this model can contribute to increase the software development success rate.
Though a dozen of different software life cycle models are suggested, there is no universal model which can satisfy all the characteristics of software. Organizations mix and match different life cycle models to develop a model more tailored for their systems and capabilities. We suggest overlapped-concurrent development life cycle model that is more suitable in various software development environment. Firstly, we divided the development process into abstract and implementation stage. Abstract stage is from software concept phase to detailed design starting time, and implementation stage is from detailed design phase to system testing phase. Next, the abstract stage introduced the overlapped phase concept that begins the next phase when the step is completed 20% by applying pareto's law. In the implementation stage, we introduced the concurrent development which the several phases are performed some time as when one use-case (UC) is completed the next development phase is started immediately. The proposed model has an advantage that it can reduce the inefficiency of development resource greatly. This model can increase the customer satisfaction with a great product at a low cost and on a short schedule. Also, this model can contribute to increase the software development success rate.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
동시개발 프로세스를 유도하기 위해 먼저, 프로젝트 개발 일정을 보다 단축시킬 수 있는 방법으로 동시개발 개념을 적용한 프로세스 모델 연구가 있는지 살펴본다. 그림 5와 같이 폭포수 모델의 각 단계들을 중첩시켜 동시에 수행하는 프로세스는 Sashimi (중첩된 폭포수 모델)가 있다.
이 방법에 속하는 모델들로는 Waterfall with Subprojects, Staged Delivery, Design-toSchedule, Evolutionary Delivery와 Spiral이 있다. 따라서 본 논문에서는 DD 단계부터 시스템을 동시에 개발하는 방법을 채택한다.
본 논문에서는 Monumental과 Agile을 모두 포함하는 단일화된 소프트웨어 개발 프로세스를 제안한다. 제안된 모델을 실제 적용하기 위해서는 Monumental이나 Agile 등 주어진 소프트웨어 개발에 가장 적합한 것으로 선택하여 동시개발 (Concurrent Development)하면 된다.
본 논문에서는 다양한 소프트웨어 개발 상황에 보다 적합할 것으로 판단되는 동시개발 프로세스 모델을 제안하였다. 제안된 모델의 특징은 먼저, SC 단계에서 얻은 100% 요구사항 리스트를 기반으로 요구사항을 20:80으로 분할한다.
전형적인 소프트웨어 개발 프로세스는 요구사항들로부터 시작된다. 요구사항에 대한 최적의 분할 비율을 고찰하여 보자. 80:20 법칙을 요구사항 관리에 적용하기 위해 “80%의 중요한 요구사항과 20%의 중요하지 않은 요구사항으로 분리한다.
이 방법은 20%의 중요한 요구사항 분석과 개략설계를 완료한 후 상세설계와 나머지 80%에 대한 요구사항 분석을 동시에 수행하는 방법을 채택한다. 이 방법을 제시하는 근거로 소프트웨어 개발 분야에서 파레토 법칙을 적용하고 있는 사례를 살펴보자.
또한, 만약 요구사항을 분할한다면 분할하는 비율은 얼마로 할 것인가가 문제로 대두된다. 이러한 문제를 해결하기 위해 먼저, 소프트웨어 위기 (Software Crisis)를 해소하기 위한 방법들을 고찰해 보자.
파이를 대상으로 이들 개발 방법론들을 설명하여 보자. 순차적 개발은 SC 단계에서 개략적인 파이 형태를 형성하고 RA, AD, DD, I 등의 단계를 거치면서 파이 내부가 점차 명확해지는 형태이다.
제안 방법
다음으로 20%의 중요한 요구사항에 대해 추상화 단계 (RA→AD)를 순차적으로 수행하여 시스템 아키텍쳐 기반을 형성하고 20% 요구사항에 대한 DD 단계를 시작하는 시점에서 나머지 80%의 요구사항에 대한 RA 단계를 동시에 수행하는 동시개발 개념을 적용하였다.
그림 3의 반복적 & 점진적 RUP의 경우 하나의 서브시스템에 대한 RA 단계 (RA팀 수행) 종료와 다음 서브시스템 RA 시작 간에 시간 낭비가 많다. 반면에, 제안된 방법은 하나의 RA 단계를 완료한 이후 다음 서브시스템의 RA를 케스케이드 형태로 수행하는 방법으로 시간 낭비를 감소시킬 수 있으며, 이로 인해 전체 프로젝트의 개발일정을 크게 단축시킬 수 있다.
본 논문에서는 100% 요구사항 분석 후 개략설계를 수행하는 순차적 방법, 분할된 요구사항 각각에 대해 캐스케이드로 요구사항 분석과 개략설계를 수행하는 반복적 & 전진적 방법과는 다른 방법을 제안한다.
본 장에서는 그림 4와 같이 최적의 동시개발 시작 시점을 찾고, 시스템 아키텍쳐가 안정화 될 수 있는 최적의 요구사항 분할 비율을 구하여 시스템 아키텍쳐가 안정화된 시점부터 시스템을 서브시스템으로 분할하여 동시 개발하는 프로세스를 제안한다.
소프트웨어 개발 과정에 대해서는 다양한 분류 방법이 존재하지만 본 논문에서는 SC, RA, AD, DD, I, UT, IT, ST, AT로 통일하여 개발 프로세스들을 살펴본다.
제안되는 프로세스 모델은 그림 6과 같이 SC 단계에서 소프트웨어 요구사항 목록이 작성되고, 최우선순위 요구사항 20%를 RA 단계에서 상세히 분석 완료하여 AD 단계에서 시스템 아키텍쳐 기반을 형성하고, 20%의 요구사항이 DD 단계를 수행하는 시점부터 나머지 80%의 요구사항에 대해 RA 단계부터 동시에 수행하는 방식이다. 이와 같이 동시개발 프로세스를 얻은 결과 순차적 엄격 (Sequential Rigorous), 반복적 & 점진적 엄격(Iterative & Incremental Rigorous)과 반복적 & 점진적 민첩 (Iterative & Incremental Agile) 프로세스 모두 단일화된 프로세스로 통일시킬 수 있었으며, 단지 요구사항 파이의 크기를 분할하는 양에만 차이가 있다.
본 논문에서는 Monumental과 Agile을 모두 포함하는 단일화된 소프트웨어 개발 프로세스를 제안한다. 제안된 모델을 실제 적용하기 위해서는 Monumental이나 Agile 등 주어진 소프트웨어 개발에 가장 적합한 것으로 선택하여 동시개발 (Concurrent Development)하면 된다. Ⅱ장에서는 지금까지 제안된 생명주기 모델을 살펴보고 개발될 프로젝트 특성에 따른 모델의 성능을 살펴본다.
본 논문에서는 다양한 소프트웨어 개발 상황에 보다 적합할 것으로 판단되는 동시개발 프로세스 모델을 제안하였다. 제안된 모델의 특징은 먼저, SC 단계에서 얻은 100% 요구사항 리스트를 기반으로 요구사항을 20:80으로 분할한다. 다음으로 20%의 중요한 요구사항에 대해 추상화 단계 (RA→AD)를 순차적으로 수행하여 시스템 아키텍쳐 기반을 형성하고 20% 요구사항에 대한 DD 단계를 시작하는 시점에서 나머지 80%의 요구사항에 대한 RA 단계를 동시에 수행하는 동시개발 개념을 적용하였다.
지금까지 다양한 개발 프로세스들이 제안되었지만 모든 소프트웨어의 특성을 만족시킬 수 있는 일반화된 프로세스가 없는 실정이다. 제안된 프로세스들은 개발 전 단계에 걸쳐 시스템의 기능을 전혀 분할하지 않고 개발하는 방법, 초기 단계부터 기능을 분할하여 개발하는 방법과 상세설계 단계부터 기능을 분할하여 개발하는 방법으로 분류할 수 있다. 이들 3가지 분류 모델들 각각은 장·단점을 갖고 있어 개발될 소프트웨어 시스템에 가장 적합한 하나의 프로세스를 선정하는데 어려움이 있다.
현존하는 개발 프로세스 모델들을 분류하는 방법에는 다양한 의견이 존재할 수 있으나 본 논문에서는 무(Nothing), 순차적 개발 (Sequential Development)과 반복적 & 점진적 개발 (Iterative & Incremental Development)로 분류한다.
성능/효과
(1) Agile 방법론에서 제기되는 리펙토링을 최소화 시킬 수 있다.
(3) 개발기간 단축 및 인력 활용을 극대화로 인력 낭비를 최소화 시킬 수 있다.
”는 법칙을 유도하여 이를 적용하고자 한다. 20%의 중요한 요구사항으로부터 시스템 아키텍쳐의 기반이 결정되면 추후에 어떠한 기능이 추가되더라도 시스템 아키텍쳐가 그 것을 수용할 수 있다. 따라서 20%의 중요한 요구사항으로부터 도출된 시스템 아키텍쳐는 개발 초기에 안정화된 아키텍쳐를 얻을 수 있다.
만약, 프로젝트를 8개의 서브프로젝트로 분할하여 하나의 서브프로젝트에 대한 요구사항 분석-개략설계-상세설계-코딩-시험이 1.5개월(45일)에 끝나고, 각각이 9일씩 걸린다면 제안된 방법은 요구사항 분석은 0일∼72일(8*9), 개략설계는 10(9+1)일+72일, 상세설계는 19(2*9+1)일+72일, 코딩은 28일(3*19+1)+72일, 시험은 37일(4*9+1)+72일=109일 소요.
이와 같은 사례들로부터 SC 단계에서 파악된 초기의 100% 요구사항 목록에 대해 20:80으로 분할하여 중요한 20% 요구사항을 먼저 개발하는 것이 보다 효율적일 것이다.
이와 같이 동시개발 프로세스를 얻은 결과 순차적 엄격 (Sequential Rigorous), 반복적 & 점진적 엄격(Iterative & Incremental Rigorous)과 반복적 & 점진적 민첩 (Iterative & Incremental Agile) 프로세스 모두 단일화된 프로세스로 통일시킬 수 있었으며, 단지 요구사항 파이의 크기를 분할하는 양에만 차이가 있다.
후속연구
다음으로 제기되는 문제는 SC 단계에서 얻은 요구사항 목록들을 분할하지 않고 RA-AD 단계를 순차적으로 1회만 수행할 것인가 아니면 분할하여 캐스케이드나 Concurrent로 수행할 것인가이다. 또한, 만약 요구사항을 분할한다면 분할하는 비율은 얼마로 할 것인가가 문제로 대두된다.
아직까지 본 제안된 모델을 실제 적용하여 모델의 적합성을 검증하지는 못하였다. 따라서 추후 본 제안 모델을 실제로 적용하여 모델의 적합성 검증에 대한 연구를 수행할 예정이다.
동시개발에는 한 단계에서 완료된 요구사항들이 바로 다음 단계 수행 팀에게 전달하여 여러 단계가 동시 수행되어 개발하는 형태를 취하고 있어 개발자원 활용의 비효율성을 크게 줄일 수 있는 장점이 있다. 또한, 여러 단계들이 중첩되어 동시에 수행되기 때문에 기존의 캐스케이드 개발 방법들 보다 개발기간을 현저하게 단축시키는 효과를 얻어 소프트웨어 개발 성공률을 높이는데도 기여할 것으로 판단된다.
아직까지 본 제안된 모델을 실제 적용하여 모델의 적합성을 검증하지는 못하였다. 따라서 추후 본 제안 모델을 실제로 적용하여 모델의 적합성 검증에 대한 연구를 수행할 예정이다.
이와 같은 문제점을 해결하기 위해 Ⅲ장에서는 시스템 아키텍쳐를 안정화 시킨 시점부터 시스템을 서브시스템으로 분할하여 동시에 정복하는 동시개발 프로세스 모델을 제안한다. 이와 같이 하면 요구사항 변경과 리펙토링 최소화를 시킬 수 있으며, 기존 프로세스 모델들 보다 개발기간도 단축시킬 수 있어 개발 성공률도 높일 수 있을 것이다.
질의응답
핵심어
질문
논문에서 추출한 답변
전형적인 소프트웨어 개발 과정은?
소프트웨어 개발 과정은 전형적으로 User's Software Requirements List, User Stories List나 Use Cases List 등을 결정하는 소프트웨어 개념정립 (SC, Software Concepts), 요구사항을 구체적으로 분석하고 모델링하는 요구사항 분석 (RA, Requirement Analysis), 시스템의 아키텍쳐를 설계하는 아키텍쳐 설계 (AD, Architecture Design, Preliminary Design 또는 High-level Design), 상세설계 (DD, Detail Design), 구현 (I, Implementation 또는 Coding), 단위시험 (UT, Unit Test), 통합시험 (IT, Integration Test), 시스템시험 (ST, System Test)과 수락시험 (AT, Acceptance Test)을 거친 후 고객에게 납품(Delivery)된다.
본 연구에서 제안한 최종 동시개발 프로세스 모델을 설명하시오.
본 논문에서는 다양한 소프트웨어 개발 상황에 보다 적합할 것으로 판단되는 동시개발 프로세스 모델을 제안하였다. 제안된 모델의 특징은 먼저, SC 단계에서 얻은 100% 요구사항 리스트를 기반으로 요구사항을 20:80으로 분할한다. 다음으로 20%의 중요한 요구사항에 대해 추상화 단계 (RA→AD)를 순차적으로 수행하여 시스템 아키텍쳐 기반을 형성하고 20% 요구사항에 대한 DD 단계를 시작하는 시점에서 나머지 80%의 요구사항에 대한 RA 단계를 동시에 수행하는 동시개발 개념을 적용하였다. 동시개발에는 한 단계에서 완료된 요구사항들이 바로 다음 단계 수행 팀에게 전달하여 여러 단계가 동시 수행되어 개발하는 형태를 취하고 있어 개발자원 활용의 비효율성을 크게 줄일 수 있는 장점이 있다. 또한, 여러 단계들이 중첩되어 동시에 수행되기 때문에 기존의 캐스케이드 개발 방법들 보다 개발기간을 현저하게 단축시키는 효과를 얻어 소프트웨어 개발 성공률을 높이는데도 기여할 것으로 판단된다.
본 연구에서 말하는 프로젝트 4중 제약사항을 설명하시오.
고객은 일정 품질 수준 (Quality Level)을 만족하는 제품의 기능 (Scope)을 얻기 위해 개발자에게 시간 (Time)과 비용 (Cost)를 지불한다. 개발자는 주어진 시간과 비용 한도 내에서 고객이 원하는 품질수준을 만족시키는 제품 기능을 제공해야만 한다. 이를 프로젝트 4중 제약사항이라 한다.
참고문헌 (40)
J. Marasco, "The Project Pyramid," The Rational Edge E-zine on-line magazine, http://www-128.ibm.com/developerworks/rational/library/4291.html, 2004.
M. Fowler, "The New Methodology," Thought-Works, 2005.
B. Lewis, "The 70-Percent Failure," Infoworld. http://archive. infoworld.com/articles/op/xml/01/10/29/011029/opservival.html, 2003.
K. Curran, "Project Management: Project Lifecycle Plannin, "http://www.infm.ulst.ac.uk/kevin/com820/week3.ppt, University of Ulster, Magee Collage, N. Ireland, 2005.
T. Sloan, "Development Models," http://www.nesc.ac.uk/talks/Wodsmes/day3/dev-models.pdf, National e-Science Centre, 2002.
N. B. Priyanto, "Software Project Management: Planning," Computer Science at University of Indonesia, 2005.
J. F. Dooley, "Life Cycle Models," http://deptorg.knox.edu/CS322/322PDFLectures/L2LifeCycle.pdf, KNOX College, 2005.
D. F. Rico, "Using Cost Benefit Analysis to Development Software Process Improvement (SPI) Strategies, http://www.dacs.dtic.mil/techs/RICO/2-6cycles.shtml
M. Lindvall and I. Rus, "Process Diversity in Software Development," IEEE Software, Vol. 17, No. 4, pp. 14-18, 2000.
Java.net, "What Term Best Describes Your Software Development Process?," http://java.net/pub/pg/94, 1994.
J. Mohr, "The Software Life Cycle," http://www.augustana.ab.ca/mohrj/courses/2005.fall/csc220/, Augustana Faculty, University of Alberta, Canada, 2005.
C. Wallin and R. Land, "Software Development Lifecycle Models: The Basic Types," Research Methodology for Computer Science and Engineering, 2001.
J. J. Kuhl, "Project Lifecycle Models: How They Differ and When to Use Them," Business eSolution, http://www.business-esolutions.com/islm.htm, 2002.
S. Huitsing, "Lifecycle Models," http://faculty.washington.edu/sharonh0/UW-HIA421/,UW Computing & Communications, 2001.
S. Cohen, "Software Life Cycles," Electrical & Computer Engineering, University of Pittsburgh, http://j7.ee.pitt.edu, 2005.
R. Lewallen, "Software Development Life Cycles Model," http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx, 2005.
M. Lines, J. Bames, J. Holmes, and S. W. Ambler, "Agile RUP: Experiences From The Trenches," http://www.ibm.com/developerworks/library/edge/feb08/lines_bames_holms_ambler/index.html, The Rational Edge, 2008.
P. Jalote, A. Palit, and P. Kurien, "The Timeboxing Process Model for Iterative Software Development," http://www.cse.iitk.ac.in/jalote/papers/Time.boxingChap.pdf, 2005.
A. Crain, "Overlapping Iterations in a RUP -based Projects," http://www-106.ibm.com/developerworks/rational/library/may05/crain/, The Rational Edge, 2005.
E. Dijkstra, "The Humble Programmer," Communications of the ACM, 1972.
Standish group, "The CHAOS Report," http://www.standishgroup.com/sample/PDFpages/chaos1994.pdf, 1994.
E. Kazmierezak, "Requirements Engineering, " The University of Melbourne, 2003.
M. Fowler, "Is Design Dead?," Thoughtworks, 2004.
B. Kaehms, "80/20 Rule in Software Development," http://www.mnl.com/ourideas/opensource/8020_rule_in_software_developm_1.php, Media NetLink, Inc., 2008.
R. Kalaver, "Prioritizing For Success; Living, Breathing 80-20,"http://stealthemode.wordpress.com/2007/11/11/living-breathing-80-20/,wordpress.com, 2007.
P. Schiller, "The Critical, The Few, The Vital, But Not Necessarily The Only," http://www.leader2leaders.com/80-20, Leader2leaders, 2000.
P. Clair, "Evaluating and Managing Software Requirement Risk," Soutwest Research Institute, 2004.
B. Kaehms, "80/20 Rule in Software Development," Media Net Link, Inc., 2008.
A. B. Pyster and R. H. Thayer, "Software Engineering Project Management 20 Years Later," IEEE Computer Society, 2005.
W. Bock, "The Five Ps of Leadership," megastarmedia.com, 2003.
Shmula.com, "The Pareto Principle," http://www.shmula.com/129/the-pareto-principle, 2006.
J. Zhuk, "Integration-Ready Architecture and Design," Cambridge University Press, 2004.
Royce, "Managing the development of large software systems: concepts and techniques," Proceedings of the 9th international conference on Software Engineering, pp. 328-338, 1987.
J. Martin, "Rapid Application Development," Macmillan Coll Div, 1991.
W. Maner, "Rapid Application Development," http://www.cs.bgsu.edu/maner/domains/RAD.htm, 1997.
Xware.com, "Putting the 'I' in 'IT'," http://www.xware.com/files/credentials/CIOAdvartorial_Bell_2006.pd, Xware.com, 2006.
S. Adcock, "Rapid Application Development: The Iterative Approach to Systems Analysis," http://www.umsl.edu/ -asan74/, University of Missouri.
Wikipedia, "Dynamic Systems Development Method," http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method, WikimediaFoundation, Inc., 2008.
A. Irons, "Agile Methods - Silver Bullet or Red Herring?," The British Computer Society, 2006.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.