소프트웨어 개발 프로세스

Software development process
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 엔지니어링에서 소프트웨어 개발 프로세스는 설계, 제품 관리를 개선하기 위해 소프트웨어 개발 작업을 더 작은, 병렬 또는 순차적인 단계 또는 하위 프로세스로 나누는 프로세스입니다.Software Development Life Cycle(SDLC; 소프트웨어 개발 라이프 사이클)이라고도 합니다.방법론에는 애플리케이션 [1]개발 또는 유지보수를 위해 프로젝트 팀에 의해 작성 및 완료된 특정 성과물 및 아티팩트의 사전 정의가 포함될 수 있습니다.

대부분의 현대 개발 프로세스는 민첩하다고 모호하게 설명할 수 있습니다.다른 방법론으로는 폭포수, 프로토타이핑, 반복 및 증분 개발, 나선형 개발, 신속한 애플리케이션 개발, 익스트림 프로그래밍 등이 있습니다.

라이프 사이클의 「모델」은, 방법론의 카테고리의 보다 일반적인 용어이며, 소프트웨어 개발의 「프로세스」는, 특정의 [citation needed]조직에 의해서 선택된 특정의 프로세스를 나타내는 보다 구체적인 용어로 간주되는 경우가 있습니다.예를 들어, 나선형 라이프 사이클 모델에 적합한 많은 특정 소프트웨어 개발 프로세스가 있습니다.이 분야는 종종 시스템 개발 라이프 사이클의 서브셋으로 간주됩니다.

역사

소프트웨어 개발 방법론(SDM이라고도 함) 프레임워크는 1960년대에야 등장했습니다.엘리엇(2004)에 따르면, 시스템 개발 수명 주기(SDLC)는 빌딩 정보 시스템을 위한 가장 오래된 공식화된 방법론 프레임워크라고 할 수 있다.SDLC의 주요 아이디어는 "매우 신중하고 구조적이며 체계적인 방법으로 정보 시스템의 개발을 추구하는 것"으로, 아이디어의 시작부터 최종 시스템의 제공까지 라이프 사이클의 각 단계를 적용 중인 프레임워크의 맥락에서 엄격하고 [2]순차적으로 수행하도록 요구하는 것이었다.1960년대 이 방법론의 주요 목표는 "대규모 기업 대기업 시대에 대규모 기능 비즈니스 시스템을 개발하는 것이었다.정보 시스템 활동은 대량의 데이터 처리와 수치 계산 루틴을 중심으로 진행되었습니다."[2]

방법론, 프로세스 및 프레임워크는 조직이 일상 업무에 직접 사용할 수 있는 특정 규범적 단계부터 특정 프로젝트 또는 그룹의 요구에 맞는 맞춤형 단계를 생성하기 위해 사용하는 유연한 프레임워크까지 다양합니다.경우에 따라서는, 「스폰서」또는 「유지보수」조직이 프로세스를 설명하는 공식 문서를 배포합니다.구체적인 예는 다음과 같습니다.

1970년대
  • 1969년 이후 구조화된 프로그래밍
  • 캡 제미니 SDM은 원래 PANDATA에서 온 것으로 1974년에 첫 영어 번역본이 출판되었습니다.SDM은 System Development Methodology의 약자입니다.
1980년대
1990년대
2000년대

2010년대

1994년 DSDM 이후 RUP를 제외한 상기 목록의 모든 방법론은 민첩한 방법론을 채택하고 있습니다.그러나 많은 조직, 특히 정부기관에서는 여전히 사전 대응 프로세스(대부분의 경우)를 사용하고 있습니다.소프트웨어 프로세스와 소프트웨어의 품질은 밀접하게 관련되어 있습니다.실제로 몇 가지 예기치 않은 측면과 효과가 관찰되고 있습니다.

그 중에서도 오픈 소스에서 또 하나의 소프트웨어 개발 프로세스가 확립되어 있습니다.이러한 베스트 프랙티스를 기업의 범위 내에서 이미 알려져 확립된 프로세스를 채택하는 것을 내부 소스라고 부릅니다.

시제품 제작

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

기본 원칙은 다음과 같습니다.[1]

  • 프로토타이핑은 독립적이고 완전한 개발 방법론이 아니라 전체 방법론(예: 증분, 나선형 또는 신속한 애플리케이션 개발(RAD))의 맥락에서 특정 기능을 시험하는 접근 방식입니다.
  • 프로젝트를 작은 세그먼트로 분할하여 개발 프로세스 중에 보다 쉽게 변경할 수 있도록 함으로써 내재된 프로젝트 리스크를 줄이려고 합니다.
  • 고객은 개발 프로세스 전체에 관여하고 있기 때문에 최종 구현에 대한 클라이언트의 수용 가능성이 높아집니다.
  • 일부 프로토타입은 폐기될 것이라는 예상 하에 개발되기도 하지만, 경우에 따라 프로토타입에서 작업 시스템으로 진화할 수도 있습니다.

잘못된 문제를 해결하는 것을 피하기 위해서는 기본적인 비즈니스 문제에 대한 이해가 필요하지만, 이는 모든 소프트웨어 방법론에 해당됩니다.

방법론

신속한 개발

주요 기사:신속한 소프트웨어 개발

"Agile Software Development(신속한 소프트웨어 개발)"는 반복적인 개발에 기초한 소프트웨어 개발 프레임워크의 그룹을 말합니다.여기서 요건과 솔루션은 자기 조직적인 교차 기능 팀 간의 협업을 통해 발전합니다.이 용어는 애자일 매니페스토가 만들어진 2001년에 만들어졌다.

신속한 변화를 위한 소프트웨어 개발은 반복적인 개발을 기반으로 하지만 기존의 접근 방식보다 가볍고 사람 중심의 관점을 옹호합니다.신속한 변화를 위한 프로세스에는 기본적으로 반복과 소프트웨어 시스템을 순차적으로 개선하고 제공하기 위해 제공하는 지속적인 피드백이 포함됩니다.

신속한 변화를 위한 모델에는 다음과 같은 소프트웨어 개발 [4]프로세스도 포함됩니다.

지속적인 통합

주요 기사:지속적인 통합

지속적인 통합은 모든 개발자 작업 복사본을 하루에도 [5]여러 번 공유 메인라인에 병합하는 작업입니다.Grady Boch는 1991년 자신의 [6]방법으로 CI를 처음 명명하고 제안했지만 하루에 여러 번 통합을 지지하지는 않았습니다.Extreme Programming(XP; 익스트림 프로그래밍)은 CI의 개념을 채택하여 하루에 한 번 이상(아마도 하루에 수십 번) 통합을 지지했습니다.

증분 개발

주요 기사:반복 및 증분 개발

선형 및 반복 시스템 개발 방법론을 결합하는 데는 다양한 방법이 허용되며, 각각의 주요 목표는 프로젝트를 더 작은 세그먼트로 분할하고 개발 프로세스 중에 더 쉽게 변경할 수 있도록 함으로써 고유한 프로젝트 위험을 줄이는 것입니다.

증분 [1]개발에는 세 가지 주요 변형이 있습니다.

  1. 일련의 미니 워터폴이 수행되며, 여기서 다음 증분으로 진행되기 전에 시스템의 작은 부분에 대해 폭포의 모든 단계가 완료됩니다.
  2. 전체적인 요건은 시스템의 개별 증분의 진화적 최소 워터폴 개발을 진행하기 전에 정의된다.
  3. Waterpal을 통해 초기 소프트웨어 개념, 요구사항 분석 및 아키텍처 및 시스템 코어의 설계를 정의한 후 증분 구현을 통해 최종 버전인 작업 시스템을 설치합니다.

신속한 응용 프로그램 개발

주요 기사: 신속한 애플리케이션 개발
신속한 애플리케이션 개발(RAD) 모델

RAD(Rapid Application Development)는 소프트웨어 개발 방법론으로, 많은 양의 사전 계획 대신 반복 개발 및 프로토타입의 신속한 구축을 선호합니다.RAD를 사용하여 개발된 소프트웨어의 '계획'은 소프트웨어 작성 자체와 연동됩니다.일반적으로 광범위한 사전 계획이 없기 때문에 소프트웨어를 훨씬 빠르게 작성할 수 있고 요구 사항을 쉽게 변경할 수 있습니다.

신속한 개발 프로세스는 구조화된 기술을 사용한 예비 데이터 모델 및 비즈니스 프로세스 모델의 개발에서 시작됩니다.다음 단계에서는 프로토타이핑을 사용하여 요구사항을 검증하고, 최종적으로 데이터와 프로세스 모델을 세분화합니다.이러한 단계를 반복하여 개발하면 "새로운 시스템 구축에 사용되는 비즈니스 요건과 기술 설계서를 합친 것"[7]이 됩니다.

이 용어는 1991년 James Martin에 의해 도입된 소프트웨어 개발 프로세스를 설명하기 위해 처음 사용되었습니다.Whitten(2003)에 따르면, 소프트웨어 시스템 [7]개발을 가속화하기 위해 다양한 구조화 기술, 특히 데이터 기반 정보기술 엔지니어링이 프로토타이핑 기술과 결합된 것입니다.

신속한 애플리케이션 개발의 기본 원칙은 다음과 같습니다.[1]

  • 주요 목표는 비교적 낮은 투자 비용으로 고품질 시스템을 신속하게 개발하고 제공하는 것입니다.
  • 프로젝트를 작은 세그먼트로 분할하여 개발 프로세스 중에 보다 쉽게 변경할 수 있도록 함으로써 내재된 프로젝트 리스크를 줄이려고 합니다.
  • 주로 반복적인 프로토타이핑(모든 개발 단계에서), 능동적인 사용자 참여 및 컴퓨터 개발 도구를 통해 고품질 시스템을 신속하게 제작하는 것을 목표로 합니다.이러한 툴에는 Graphical User Interface(GUI; 그래피컬 사용자 인터페이스), Computer Aided Software Engineering(CASE; 컴퓨터 지원 소프트웨어 엔지니어링) 도구, 데이터베이스 관리 시스템(DBMS), 4세대 프로그래밍 언어, 코드 생성기 및 객체 지향 기술이 포함될 수 있습니다.
  • 중요한 것은 비즈니스 요구를 충족시키는 것이지만, 기술이나 엔지니어링의 우수성은 그다지 중요하지 않습니다.
  • 프로젝트 관리에는 개발의 우선순위를 정하고 납품 기한 또는 "타임박스"를 정의하는 작업이 포함됩니다.프로젝트가 지연되기 시작하면 마감 시간을 늘리는 것이 아니라 타임박스에 맞게 요구사항을 줄이는 것이 중요합니다.
  • 일반적으로 사용자가 구조화된 워크샵 또는 전자적으로 촉진된 상호작용을 통해 시스템 설계에 깊이 관여하는 공동 애플리케이션 설계(JAD)가 포함됩니다.
  • 적극적인 사용자 참여가 필수적입니다.
  • 일회용 프로토타입이 아닌 생산 소프트웨어를 반복적으로 생산합니다.
  • 향후 개발 및 유지보수를 용이하게 하기 위해 필요한 문서를 작성합니다.
  • 표준 시스템 분석 및 설계 방법을 이 프레임워크에 적용할 수 있습니다.

폭포 개발

주요 기사:워터폴 모델
워터폴 모델에 나타난 소프트웨어 개발 프로세스의 활동.이 프로세스를 나타내는 다른 모델이 몇 가지 있습니다.

워터폴 모델은 순차적 개발 접근 방식으로, 개발은 여러 단계를 통해 (폭포와 같이) 꾸준히 아래쪽으로 흐릅니다. 일반적으로 다음과 같습니다.

이 방법의 첫 번째 공식 설명은 윈스턴 W에 의해 발행된 기사로 종종 인용된다. 로이스는[8] 1970년에 이 기사에서 "waterfall"이라는 용어를 사용하지 않았다.Royce는 이 모델을 결함이 있는 비작동 [9]모델의 예로 제시했습니다.

기본 원칙은 다음과 같습니다.[1]

  • 프로젝트는 순차적인 단계로 나뉘며, 단계 간에 일부 중복 및 스플래시백이 허용됩니다.
  • 시스템 전체의 계획, 일정, 목표일, 예산 및 구현에 중점을 두고 있습니다.
  • 광범위한 서면 문서, 공식 검토, 대부분의 단계 종료 시 다음 단계를 시작하기 전에 발생하는 사용자의 승인/사인오프 및 정보기술 관리를 통해 프로젝트 수명 동안 엄격한 관리가 유지됩니다.문서화는 각 단계에 대한 명시적인 성과물입니다.

워터폴 모델은 소프트웨어 엔지니어링에 적용되는 전통적인 엔지니어링 접근 방식입니다.엄격한 워터폴 어프로치에서는,[according to whom?] 그 전의 단계가 완료하면, 재검토나 수정이 불필요하게 됩니다.순수한 폭포수 모델의 이러한 "반사성"은 다른 "반사성" 모델을 지지하는 사람들로부터 비난을 받아왔다.이는 여러 대규모 정부 프로젝트가 예산 초과, 장기간에 걸쳐 진행되며 때로는 빅 디자인 [according to whom?]프런트 접근법 때문에 요구사항을 이행하지 못하는 것으로 널리 비난받아 왔습니다.계약상 필요한 경우를 제외하고, 워터폴 모델은 소프트웨어 개발을 [according to whom?]위해 특별히 개발된 보다 유연하고 다용도적인 방법론으로 대체되었습니다.폭포수 모델에 대한 비판을 참조하십시오.

나선 전개

나선 모형 (Boehm, 1988)
주요 기사: 나선형 모델

1988년 Barry Boehm은 하향식 개념과 상향식 개념의 장점을 결합하기 위해 폭포 모델의 주요 측면과 신속한 프로토타이핑 방법론을 결합한 공식적인 소프트웨어 시스템 개발 "스파이럴 모델"을 발표했습니다.이는 특히 대규모 복잡한 시스템에 적합한 신중한 반복 위험 분석과 같은 다른 방법론에 의해 많은 사람들이 무시당했다고 느꼈던 핵심 영역에 중점을 두었다.

기본 원칙은 다음과 같습니다.[1]

  • 리스크 평가와 프로젝트 리스크 최소화에 중점을 두고 있습니다.이것에 의해, 프로젝트를 소규모의 세그먼트(segment)로 분할해, 개발 프로세스중에 변경의 용이성을 높일 수 있습니다.또, 리스크를 평가하고, 라이프 사이클 전체에 걸쳐 프로젝트의 계속에 대한 배려를 검토할 기회를 얻을 수 있습니다.
  • 「각 사이클은, 제품의 각 부분과 그 상세 레벨에 대해서, 운용의 전체적인 개념 문서로부터 각 [10]개별 프로그램의 코딩에 이르기까지, 같은 순서로 진행됩니다.」
  • 나선형 주위를 도는 각 트립은 4개의 기본 사분원을 통과한다. (1) 반복의 목표, 대안 및 제약사항을 결정하고 (2) 대안을 평가하며, 위험을 식별 및 해결하며, (3) 반복에서 산출물을 개발하고 검증하며, (4) [11]다음 반복을 계획한다.
  • 각 사이클은 이해관계자 및 이해관계자의 "승리조건"을 특정하는 것으로 시작하고, 각 사이클을 리뷰와 [12]확약으로 종료합니다.

고도의 방법론

기타 개략적인 소프트웨어 프로젝트 방법론에는 다음이 포함됩니다.

  • 행동 중심 개발 및 비즈니스 프로세스[13] 관리
  • 혼돈 모델 - 주요 규칙은 항상 가장 중요한 문제를 먼저 해결합니다.
  • 증분 자금 조달 방법론 - 반복적 접근법
  • Lightweight 방법론 - 규칙과 프랙티스가 거의 없는 방법의 총칭
  • 구조화된 시스템 분석 및 설계 방법 - 폭포의 특정 버전
  • 느린 프로그래밍은 더 큰 슬로우 무브먼트의 일부로서 시간의 압박 없이(또는 최소한의) 세심한 점진적인 작업을 강조합니다.느린 프로그래밍은 버그와 지나치게 빠른 출시 일정을 피하는 것을 목적으로 합니다.
  • V-Model(소프트웨어 개발) - 워터폴 모델의 확장판
  • Unified Process(UP)는 Unified Modeling Language(UML)를 기반으로 한 반복적인 소프트웨어 개발 방법론 프레임워크입니다.UP는 소프트웨어의 개발을 4단계로 편성합니다.각 단계는 소프트웨어의 1개 이상의 실행 가능 반복으로 구성됩니다.각 단계는 초기, 상세, 구축 및 가이드라인입니다.UP 구현을 용이하게 하기 위해 많은 툴과 제품이 존재합니다.UP의 가장 일반적인 버전 중 하나는 Rational Unified Process(RUP)입니다.
  • 빅뱅 방법론 - 소규모 프로젝트 또는 정의되지 않은 프로젝트를 위한 접근법입니다.일반적으로 리스크가 높은 계획은 거의 또는 전혀 없습니다.

프로세스 메타 모델

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

  • ISO/IEC 12207은 소프트웨어의 라이프 사이클을 선택, 구현 및 감시하는 방법을 기술하는 국제 표준입니다.
  • 능력 성숙도 모델 통합(CMMI)은 최고의 모델 중 하나이며 모범 사례를 기반으로 합니다.독립된 평가에서는 조직이 정의된 프로세스를 얼마나 잘 따르느냐에 따라 평가되며 프로세스나 생산된 소프트웨어의 품질에 따라 평가되지 않습니다.CMMI는 CMM을 대체했습니다.
  • ISO 9000은 제품 제조를 위한 공식적으로 조직된 프로세스의 표준과 진행 상황을 관리하고 모니터링하는 방법을 기술하고 있습니다.이 표준은 원래 제조 부문용으로 작성되었지만 ISO 9000 표준은 소프트웨어 개발에도 적용되어 왔습니다.CMMI와 마찬가지로 ISO 9000에 의한 인증도 최종 결과의 품질을 보증하는 것은 아닙니다.정식화된 비즈니스 프로세스만 따르고 있습니다.
  • ISO/IEC 15504 정보 테크놀로지—프로세스 평가는 소프트웨어 프로세스 개선 능력 결정(SPICE)이라고도 하며 "소프트웨어 프로세스 평가의 프레임워크"입니다.이 표준은 공정 비교를 위한 명확한 모델을 설정하는 것을 목적으로 합니다.SPICE는 CMMI와 마찬가지로 소프트웨어 개발을 관리, 제어, 가이드 및 감시하는 프로세스를 모델링합니다.그런 다음 이 모델을 사용하여 소프트웨어 개발 중에 개발 조직 또는 프로젝트 팀이 실제로 수행하는 작업을 측정합니다.이 정보는 약점을 식별하고 개선을 촉진하기 위해 분석됩니다.또, 그 조직이나 팀에 대해서 계속적으로 또는 통상의 프랙티스에 짜넣을 수 있는 메리트를 특정합니다.
  • ISO/IEC 24744 소프트웨어 엔지니어링 - 개발 방법론을 위한 메타모델은 소프트웨어 개발 방법론을 위한 전력 타입 기반의 메타모델입니다.
  • 오브젝트 관리 그룹에 의한 SPEM 2.0
  • 소프트 시스템 방법론 - 관리 프로세스를 개선하기 위한 일반적인 방법
  • 방법공학 - 정보시스템 프로세스를 개선하기 위한 일반적인 방법

실제로

소프트웨어 개발 방법론 프레임워크에 적용되는 세 가지 기본 접근법.

이러한 프레임워크는 오랜 세월에 걸쳐 진화하고 있으며, 각각 독자적인 장점과 단점을 가지고 있습니다.하나의 소프트웨어 개발 방법론 프레임워크가 모든 프로젝트에서 사용하기에 반드시 적합한 것은 아닙니다.이용 가능한 각 방법론 프레임워크는 다양한 기술적,[1] 조직적, 프로젝트 및 팀의 고려사항에 따라 특정 종류의 프로젝트에 가장 적합합니다.

소프트웨어 개발 조직은 개발 프로세스를 용이하게 하기 위해 프로세스 방법론을 구현합니다.청부업자가 채용 방법론을 요구할 수 있는 경우가 있습니다.예를 들어 미국 방위산업은 계약을 따내기 위해 프로세스 모델에 근거한 평가를 요구합니다.소프트웨어의 라이프 사이클의 선택, 실장, 감시 방법을 기술하는 국제 표준은 ISO/IEC 12207입니다.

수십 년에 걸친 목표는 생산성과 품질을 향상시키는 반복 가능하고 예측 가능한 프로세스를 찾는 것이었습니다.어떤 사람들은 겉보기에는 다루기 어려워 보이는 소프트웨어 설계 작업을 체계화하거나 공식화하려고 한다.소프트웨어 설계에 프로젝트 관리 기술을 적용하는 기업도 있습니다.많은 소프트웨어 프로젝트가 기능, 비용 또는 제공 일정 측면에서 기대에 미치지 못하고 있습니다. 몇 가지 주목할 만한 예는 실패한 사용자 정의 소프트웨어 프로젝트 목록 및 예산 초과를 참조하십시오.

조직은 프로세스 개선의 초점인 소프트웨어 엔지니어링 프로세스 그룹(SEPG)을 만들 수 있습니다.다양한 스킬을 가진 라인 실무자로 구성된 이 그룹은 소프트웨어 엔지니어링 프로세스 개선에 관여하는 조직 내 모든 사람의 협업 노력의 중심에 있습니다.

또한 특정 개발팀은 하나 이상의 주요 프로그래밍 패러다임, 프로그래밍 스타일 규칙 또는 특정 소프트웨어 라이브러리 또는 소프트웨어 프레임워크 선택과 같은 통합 개발 환경을 사용하는 프로그램 환경의 세부 사항에 동의할 수 있습니다.이러한 세부사항은 일반적으로 모델이나 일반 방법론의 선택에 의해 결정되지 않는다.

소프트웨어 개발 라이프 사이클(SDLC)

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d e f g Medicare & Medicaid Services (CMS) Office of Information Service (2008).개발 접근법 선택.웹 기사미국 보건복지부(HHS)재검증 완료:2008년 3월 27일2008년 10월 27일 취득.
  2. ^ a b Geoffrey Elliott (2004) Global Business Information Technology: 통합 시스템 접근법.피어슨 교육 페이지 87
  3. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.
  4. ^ "software development process". 19 August 2020.
  5. ^ "Continuous Integration".
  6. ^ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Retrieved 18 August 2014.
  7. ^ a b 휘튼, 제프리 L.; 로니 D. 벤틀리, 케빈 C 디트먼.(2003).시스템 분석 및 설계 방법.제6판ISBN 0-256-19906-X.
  8. ^ Wasserfallmodell > Entsteungskontext, Markus Rerych, Institut für Gestaltungs-and Wirkungsforschung, TU-Wien.2007년 11월 28일에 온라인으로 액세스.
  9. ^ 콘래드 와이저트, 워터폴 방법론: 그런 건 없어!
  10. ^ Barry Boehm(1996). "소프트웨어 개발과 확장의 나선형 모델"입력: ACM SIGSOFT 소프트웨어 엔지니어링 노트(ACM) 11(4): 1986년8월 14-24일
  11. ^ 리처드 H.테이어, 베리 W.봄(1986년).튜토리얼: 소프트웨어 엔지니어링 프로젝트 관리.IEEE 컴퓨터 소사이어티 프레스 페이지 130
  12. ^ Barry W. Boehm(2000).Cocomo II에 의한 소프트웨어 비용 견적: Volume 1.
  13. ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117. S2CID 14539297.

외부 링크

Wikimedia Commons에는 소프트웨어 개발 방법론과 관련된 미디어가 있습니다.