close
본문으로 이동

소프트웨어 개발 프로세스

위키백과, 우리 모두의 백과사전.

소프트웨어 개발 프로세스(software development process)는 소프트웨어 개발을 위한 프로세스를 규정한다. 이는 일반적으로 전체적인 노력을 더 작은 단계나 하위 프로세스로 나누어 높은 품질의 결과를 보장하는 것을 목표로 한다. 프로세스는 구체적인 산출물–생성 및 완료되어야 할 아티팩트를 설명할 수 있다.[1]

엄격하게 제한되는 것은 아니지만, 소프트웨어 개발 프로세스는 종종 소프트웨어 시스템의 시작부터 수명 종료까지의 개발을 관리하는 상위 수준의 프로세스를 의미하며, 방법론, 모델 또는 프레임워크로 알려져 있다. 소프트웨어 개발 수명 주기(SDLC)는 소프트웨어 시스템을 포함한 시스템의 시작부터 수명 종료까지 개발 노력이 거치는 전형적인 단계들을 설명한다. 방법론은 공학자들이 시스템을 수명 주기에 따라 이동시키기 위해 어떻게 업무를 수행하는지 규정한다. 방법론은 SDLC를 위해 고안된 프로세스들의 분류 또는 프로세스 청사진이다. 예를 들어, 많은 프로세스가 나선형 모델로 분류될 수 있다.

소프트웨어 프로세스와 소프트웨어 품질은 밀접하게 상호 연관되어 있으며, 실제 사례에서 예상치 못한 측면과 효과가 관찰되기도 한다.[2]

방법론

[편집]

SDLC는 방법론이 SDLC의 단계들을 다루어야 한다는 점에서 방법론의 정의를 주도한다. 일반적으로 방법론은 컴퓨터 시스템이 복잡하고 이질적인 구성 요소를 통합할 수 있음에도 불구하고, 기대치(요구사항)를 충족하거나 초과하고 정해진 시간과 예산 내에 인도되는 고품질 시스템을 결과로 내도록 설계된다.[3] 폭포수, 나선, 애질, 고속 프로토타이핑, 점진적, 그리고 동기화 및 안정화(synchronize and stabilize)를 포함한 다양한 방법론이 고안되었다.[4]

방법론 간의 주요 차이점은 단계들이 순차적인지 아니면 반복적인지의 정도이다. XP 및 스크럼과 같은 애자일 방법론은 빠른 변화를 허용하는 가벼운 프로세스에 집중한다.[5] 래셔널 통합 프로세스 및 동적 시스템 개발 방법과 같은 반복적 방법론은 프로젝트 범위를 안정화하고 반복적으로 제품을 확장하거나 개선하는 데 집중한다. 폭포수와 같은 순차적 또는 대규모 선행 설계(BDUF) 모델은 대규모 프로젝트를 가이드하고 성공적이고 예측 가능한 결과에 대한 위험을 제한하기 위해 완전하고 정확한 계획에 집중한다.[6] 아나모픽 개발(Anamorphic development)은 프로젝트 범위와 적응형 반복에 의해 가이드된다. 예를 들어 스크럼[7]에서는 단일 사용자 스토리가 2주간의 스프린트 내에서 SDLC의 모든 단계를 거친다고 말할 수 있다. 이와 대조적으로 폭포수 방법론에서는 모든 비즈니스 요구사항이 기능 설명으로 변환되며, 이는 일반적으로 수개월 또는 그 이상의 기간에 걸쳐 모두 구현된다.

프로젝트는 서로 다른 활동을 설명하는 프로젝트 수명 주기(PLC)와 SDLC를 모두 포함할 수 있다. 테일러(Taylor, 2004)에 따르면, "프로젝트 수명 주기는 프로젝트의 모든 활동을 포괄하는 반면, 시스템 개발 수명 주기는 제품 요구사항을 실현하는 데 집중한다".[8]

역사

[편집]

SDLC라는 용어는 종종 SDLC 방법론의 약어로 사용된다. 나아가 일부에서는 폭포수 방법론을 의미하기 위해 SDLC와 전통적 SDLC라는 용어를 사용하기도 한다.

엘리엇(Elliott, 2004)에 따르면, SDLC는 "대규모 기업 집단의 시대에 대규모 기능적 비즈니스 시스템을 개발하기 위해 1960년대에 시작되었다. 정보 시스템 활동은 과중한 데이터 처리와 수치 계산 루틴을 중심으로 이루어졌다".[9] 구조적 시스템 분석 및 설계 방법(SSADM)은 1980년대 영국 정부의 상무국을 위해 만들어졌다. 엘리엇(2004)에 따르면, 그 이후로 "시스템 개발에 대한 전통적인 수명 주기 접근 방식은 전통적 SDLC의 내재된 결함 중 일부를 극복하려는 대안적인 접근 방식과 프레임워크로 점점 더 대체되었다".[9] SDLC의 주요 아이디어는 적용되는 프레임워크의 맥락 내에서 "아이디어의 시작부터 최종 시스템의 인도까지 수명 주기의 각 단계가 엄격하고 순차적으로 수행되도록 요구하면서, 매우 의도적이고 구조적이며 방법론적인 방식으로 정보 시스템 개발을 추구하는 것"이었다.[9]

나중에 다른 방법론들이 고안되었다:

1970년대
  • 1969년 이후 구조적 프로그래밍
  • Cap Gemini SDM, 원래 PANDATA에서 유래하였으며, 1974년에 첫 영문 번역본이 출판되었다. SDM은 시스템 개발 방법론(System Development Methodology)의 약자이다.
1980년대
1990년대
2000년대
  • 2005년부터 스콧 앰블러에 의해 유지 관리되는 애자일 통합 프로세스(AUP)
  • AUP를 대체한 규율 있는 애자일 인도(Disciplined agile delivery, DAD)
2010년대
  • 대규모 애자일 프레임워크(Scaled Agile Framework, SAFe)
  • 대규모 스크럼(Large-Scale Scrum, LeSS)
  • 데브옵스

1994년 DSDM 이후로, 위의 목록에 있는 방법론 중 RUP를 제외한 모든 방법론은 애자일 방법론이었으나, 여전히 많은 조직, 특히 정부는 여전히 애자일 이전의 프로세스(종종 폭포수 또는 이와 유사한 방식)를 사용한다.

예시

[편집]

다음은 인기도에 따라 어느 정도 순서가 정해진 주목할 만한 방법론들이다.

애자일

애질 소프트웨어 개발은 반복적 개발에 기초한 프레임워크 그룹을 의미하며, 여기서 요구사항과 솔루션은 자율적으로 조직되는 기능 교차 팀 간의 협업을 통해 진화한다. 이 용어는 2001년 애자일 선언이 수립되었을 때 만들어졌다.

폭포수

폭포수 모델은 순차적인 개발 접근 방식으로, 개발이 SDLC 단계를 통해 한 방향으로(폭포처럼) 흐른다.

나선형

1988년, 배리 뵘은 폭포수 모델과 고속 프로토타이핑의 주요 측면을 결합하여 상향식 및 하향식 개념의 장점을 결합하려는 노력으로 소프트웨어 시스템 개발 나선형 모델을 발표했다. 이는 다른 방법론들이 소홀히 했다고 생각되는 핵심 영역인 의도적이고 반복적인 위험 분석을 강조하며, 특히 대규모 복잡한 시스템에 적합하다.

점진적

다양한 방법들이 선형 및 반복적 방법론을 결합하며, 주요 목표는 프로젝트를 더 작은 세그먼트로 나누고 개발 프로세스 중에 변경을 더 용이하게 함으로써 내재된 프로젝트 위험을 줄이는 것이다.

프로토타이핑

소프트웨어 프로토타이핑은 프로토타입, 즉 개발 중인 소프트웨어 프로그램의 불완전한 버전을 만드는 것에 관한 것이다.

고속 (RAD)

고속 응용 프로그램 개발(RAD)은 방대한 양의 선행 계획 대신 반복적 개발과 프로토타입의 신속한 구축을 선호하는 방법론이다. RAD를 사용하여 개발되는 소프트웨어의 "계획"은 소프트웨어 작성 자체와 교차되어 이루어진다. 광범위한 사전 계획의 부재는 일반적으로 소프트웨어를 훨씬 더 빠르게 작성할 수 있게 하며 요구사항 변경을 더 쉽게 만든다.

Shape Up

Shape Up은 2018년 Basecamp에서 도입한 소프트웨어 개발 접근 방식이다. 이는 Basecamp가 프로젝트가 명확한 끝없이 질질 끌리는 문제를 극복하기 위해 내부적으로 개발한 일련의 원칙과 기술이다. 주요 대상 고객은 원격 팀이다. Shape Up에는 폭포수, 애질, 또는 스크럼과 달리 추정 및 속도 추적, 백로그 또는 스프린트가 없다. 대신 이러한 개념은 식욕(appetite), 베팅(betting), 사이클(cycles)로 대체된다. 2022년 기준으로 Basecamp 외에도 Shape Up을 채택한 주목할 만한 조직으로는 UserVoice와 Block이 있다.[10][11]

카오스 (Chaos)

카오스 모델은 하나의 주요 규칙을 가진다: 항상 가장 중요한 문제를 먼저 해결하라.

점진적 자금 조달

점진적 자금 조달 방법론(Incremental funding methodology) - 반복적인 접근 방식이다.

경량 (Lightweight)

경량 방법론(Lightweight methodology) - 규칙과 관행이 몇 가지뿐인 방법들을 일컫는 일반적인 용어이다.

구조적 시스템 분석 및 설계

구조적 시스템 분석 및 설계 방법 - 폭포수의 특정 버전이다.

느린 프로그래밍 (Slow programming)

더 큰 슬로 무브먼트의 일환으로, 시간 압박 없이(또는 최소화하여) 신중하고 점진적인 작업을 강조한다. 느린 프로그래밍은 버그와 지나치게 빠른 출시 일정을 피하는 것을 목표로 한다.

V 모델

V 모델 - 폭포수 모델의 확장이다.

통합 프로세스

통합 프로세스(UP)는 통합 모델링 언어(UML)에 기초한 반복적 소프트웨어 개발 방법론 프레임워크이다. UP는 소프트웨어 개발을 4단계로 구성하며, 각 단계는 해당 개발 단계에서 소프트웨어의 하나 이상의 실행 가능한 반복으로 구성된다: 도입(inception), 상세(elaboration), 구축(construction), 및 전이(guidelines).

비교

[편집]

폭포수 모델은 각 단계가 이전 단계의 결과물을 바탕으로 구축되도록 SDLC 단계들을 설명한다.[12][13][14][15] 모든 프로젝트가 단계들을 순차적으로 진행해야 하는 것은 아니다. 상대적으로 단순한 프로젝트의 경우 단계들이 결합되거나 겹칠 수 있다.[12] 폭포수에 대한 대안적 방법론들이 아래에서 설명되고 비교된다.[16]

방법론 비교
폭포수 RAD 오픈 소스 OOP JAD 프로토타이핑 최종 사용자
제어 공식적 MIS 약함 표준 공동 사용자 사용자
기간 김 짧음 중간 다양함 중간 짧음 짧음

–

사용자 많음 적음 적음 다양함 적음 한두 명 한 명
MIS 인력 많음 적음 수백 명 분할됨 적음 한두 명 없음
트랜잭션/DSS 트랜잭션 둘 다 둘 다 둘 다 DSS DSS DSS
인터페이스 최소한 최소한 약함 윈도우 매우 중요 매우 중요 매우 중요
문서화 및 교육 필수적 제한적 내부적 객체 내 제한적 약함 없음
무결성 및 보안 필수적 필수적 알 수 없음 객체 내 제한적 약함 약함
재사용성 제한적 일부 가능성 있음 필수적 제한적 약함 없음

프로세스 메타 모델

[편집]

일부 프로세스 모델은 조직에서 채택한 특정 프로세스를 평가, 비교 및 개선하기 위한 추상적인 설명이다.

ISO/IEC 12207

ISO/IEC 12207은 소프트웨어의 수명 주기를 선택, 구현 및 모니터링하는 방법을 설명하는 국제 표준이다.

능력 성숙도 통합 모델

능력 성숙도 통합 모델(CMMI)은 선도적인 모델 중 하나이며 베스트 프랙티스에 기초한다. 독립적인 평가는 조직이 정의된 프로세스를 얼마나 잘 따르는지에 따라 등급을 매기며, 해당 프로세스의 품질이나 생산된 소프트웨어의 품질을 평가하지는 않는다. CMMI는 능력 성숙도 모델(CMM)을 대체했다.

ISO 9000

ISO 9000은 제품을 제조하기 위한 공식적으로 조직된 프로세스와 진행 상황을 관리하고 모니터링하는 방법에 대한 표준을 설명한다. 이 표준은 원래 제조 부문을 위해 만들어졌지만, ISO 9000 표준은 소프트웨어 개발에도 적용되어 왔다. CMMI와 마찬가지로 ISO 9000 인증은 최종 결과의 품질을 보장하지 않으며, 공식화된 비즈니스 프로세스가 준수되었음만을 보장한다.

ISO/IEC 15504

ISO/IEC 15504 정보 기술—프로세스 평가(Software Process Improvement Capability Determination, SPICE)는 소프트웨어 프로세스 평가를 위한 프레임워크이다. 이 표준은 프로세스 비교를 위한 명확한 모델을 제시하는 것을 목표로 한다. SPICE는 CMMI와 매우 유사하게 사용된다. 이는 소프트웨어 개발을 관리, 제어, 가이드 및 모니터링하기 위한 프로세스를 모델링한다. 그런 다음 이 모델은 개발 조직이나 프로젝트 팀이 소프트웨어 개발 중에 실제로 무엇을 하는지 측정하는 데 사용된다. 이 정보는 약점을 식별하고 개선을 주도하기 위해 분석된다. 또한 해당 조직이나 팀의 공통 관행으로 계속 유지하거나 통합할 수 있는 강점도 식별한다.

ISO/IEC 24744

ISO/IEC 24744 소프트웨어 공학—개발 방법론을 위한 메타모델은 소프트웨어 개발 방법론을 위한 파워 유형 기반의 메타모델이다.

소프트 시스템 방법론

소프트 시스템 방법론은 관리 프로세스를 개선하기 위한 일반적인 방법이다.

방법 공학

방법 공학(Method engineering)은 정보 시스템 프로세스를 개선하기 위한 일반적인 방법이다.

같이 보기

[편집]

각주

[편집]
  1. ↑ “Selecting a development approach” (PDF). 《Centers for Medicare & Medicaid Services (CMS) Office of Information Service》. United States Department of Health and Human Services (HHS). 2008년 3월 27일. 2012년 6월 20일에 원본 문서 (PDF)에서 보존된 문서. 2008년 10월 27일에 확인함.
  2. ↑ Suryanarayana, Girish (2015). 《Software Process versus Design Quality: Tug of War?》. 《IEEE Software》 32. 7–11쪽. doi:10.1109/MS.2015.87.
  3. ↑ “Systems Development Life Cycle from”. FOLDOC. 2013년 6월 14일에 확인함.
  4. ↑ “Software Development Life Cycle (SDLC)” (PDF). 《softwarelifecyclepros.com》. May 2012. 2025년 6월 26일에 확인함.
  5. ↑ “SDLC Overview: Models & Methodologies”. 2021년 12월 12일에 확인함.
  6. ↑ Arden, Trevor (1991). 《Information technology applications》. London: Pitman. ISBN 978-0-273-03470-4.
  7. ↑ “What is Scrum?”. 2019년 12월 24일.
  8. ↑ Taylor, James (2004). 《Managing Information Technology Projects》. 39쪽.
  9. 1 2 3 Geoffrey Elliott (2004). 《Global Business Information Technology: an integrated systems approach》. Pearson Education. 87쪽.
  10. ↑ “Foreword by Jason Fried | Shape Up”. 《basecamp.com》. 2022년 9월 11일에 확인함.
  11. ↑ “Is Shape Up just a nice theory?” (오스트레일리아 영어). 《Curious Lab》. 2022년 9월 12일에 확인함.
  12. 1 2 US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.
  13. ↑ Everatt, G.D.; McLeod, R Jr (2007). 〈Chapter 2: The Software Development Life Cycle〉. 《Software Testing: Testing Across the Entire Software Development Life Cycle》. John Wiley & Sons. 29–58쪽. ISBN 9780470146347.
  14. ↑ Unhelkar, B. (2016). 《The Art of Agile Practice: A Composite Approach for Projects and Organizations》. CRC Press. 56–59쪽. ISBN 9781439851197.
  15. ↑ Land, S.K.; Smith, D.B.; Walz, J.W. (2012). 《Practical Support for Lean Six Sigma Software Process Definition: Using IEEE Software Engineering Standards》. John Wiley & Sons. 341–3쪽. ISBN 9780470289952.
  16. ↑ Post, G., & Anderson, D., (2006). Management information systems: Solving business problems with information technology. (4th ed.). New York: McGraw-Hill Irwin.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=소프트웨어_개발_프로세스&oldid=41047749"