소프트웨어 개발

소프트웨어 개발 프로세스 **소프트웨어 개발**(software development)은 특정 **사용자 요구 사항 또는 비즈니스 목표**를 충족하기 위해 **소프트웨어 애플리케이션을 설계, 생성, 테스트 및 유지 관리하는 프로세스**이다. 이 프로세스는 목표 구상, 타당성 평가, 요구 사항 분석, 설계, 테스트 및 배포를 포함한다는 점에서 프로그래밍, 즉 코드 작성보다 더 포괄적이다. 이 프로세스는 소프트웨어 공학의 일부이며, 여기에는 조직 관리, 프로젝트 관리, 구성 관리 및 기타 측면도 포함된다.p=1 소프트웨어 개발에는 프로그래밍, 테스트, 문서화, 그래픽 디자인, 사용자 지원, 마케팅, 모금 등 다양한 기술과 직무 전문 분야가 포함된다. 소프트웨어 개발에는 도구를 포함하여 컴파일러, 통합 개발 환경 (IDE), 버전 관리, 컴퓨터 지원 소프트웨어 공학, 워드 프로세서와 같은 많은 도구들이 관련된다. 개발 노력에 사용되는 프로세스의 세부 사항은 다양하다. 프로세스는 공식적이고 문서화된 표준에 국한될 수도 있고, 개발 노력에 맞게 맞춤화되고 창발적일 수도 있다. 프로세스는 각 주요 단계(즉, 설계, 구현, 테스트)가 다음 단계가 시작되기 전에 완료되는 순차적일 수 있지만, 작은 측면이 개별적으로 설계, 구현 및 테스트되는 반복적인 접근 방식은 위험과 비용을 줄이고 품질을 향상시킬 수 있다.
# 방법론
소프트웨어 개발 방법론 반복적 개발 모델인 [[진화적 프로토타이핑 모델의 흐름도p=12]] 사용 가능한 각 방법론은 다양한 기술, 조직, 프로젝트 및 팀 고려 사항에 따라 특정 종류의 프로젝트에 가장 적합하다.System Development Methodologies for Web-Enabled E-Business: A Customization Framework Linda V. Knight (DePaul University, USA), Theresa A. Steinbach (DePaul University, USA), and Vince Kellen (Blue Wolf, USA) * 가장 간단한 방법론은 "코드 앤 픽스(code and fix)"이며, 일반적으로 소규모 프로젝트를 수행하는 한 명의 프로그래머가 사용한다. 프로그램의 목적을 간략히 고려한 후, 프로그래머는 코드를 작성하고 실행하여 작동하는지 확인한다. 완료되면 제품이 출시된다. 이 방법론은 프로토타입에 유용하지만 더 정교한 프로그램에는 사용할 수 없다.pp=8-9 * 하향식 폭포수 모델에서는 타당성, 분석, 설계, 개발, 품질 보증 및 구현이 순차적으로 발생한다. 이 모델은 다음 단계가 시작되기 전에 한 단계가 완료되어야 하므로 지연이 발생하며, 필요한 경우 이전 단계를 수정하는 것이 불가능하다.p=9pp=2-3, 5–6p=8 * 반복적 프로세스를 사용하면 이러한 단계가 서로 얽혀 유연성, 효율성 및 보다 현실적인 스케줄링이 향상된다. 프로젝트를 한 번에 모두 완료하는 대신, 한 번에 하나의 구성 요소로 대부분의 단계를 진행할 수 있다. 반복적 개발은 또한 개발자가 가장 중요한 기능을 우선 순위로 지정할 수 있게 하여 필요한 경우 나중에 낮은 우선 순위 기능을 삭제할 수 있도록 한다.pp=2-3, 5–6p=11 애자일은 원래 작거나 중간 규모의 프로젝트를 위해 고안된 인기 있는 방법 중 하나로, 개발자가 작업하는 기능에 대한 더 많은 제어권을 부여하여 시간 또는 비용 초과 위험을 줄이는 데 중점을 둔다.p=13 애자일의 파생물로는 익스트림 프로그래밍과 스크럼이 있다.p=13 오픈 소스 소프트웨어 개발은 분산된 자원 봉사자 네트워크에 의존하기 때문에 일반적으로 동시 설계, 코딩 및 테스트를 포함하는 애자일 방법론을 사용한다.pp=41-42 * 애자일을 넘어 일부 기업은 정보기술 (IT) 운영을 컴퓨터 보안을 포함한 소프트웨어 개발과 통합하는데, 이를 데브옵스 또는 데브섹옵스라고 부른다.pp=1-2 데브옵스는 지속적인 개발, 테스트, 버전 관리 시스템에 새로운 코드 통합, 새로운 코드의 배포, 그리고 때로는 고객에게 코드 전달을 포함한다.doi-access=free 이 통합의 목적은 IT 서비스를 더 빠르고 효율적으로 제공하는 것이다.pp=1-2 많은 프로그래밍 방법론의 또 다른 초점은 보안 취약점 및 버그와 같은 문제를 가능한 한 일찍 포착하여(쉬프트-레프트 테스트) 추적 및 수정 비용을 줄이는 것이다.p=17 2009년에는 소프트웨어 프로젝트 중 32%가 정시에 예산 범위 내에서 모든 기능을 갖춘 채로 제공되었다고 추정되었다. 추가로 44%는 제공되었지만 적어도 하나의 기능이 누락되었다. 나머지 24%는 출시 전에 취소되었다.p=6
# 단계
소프트웨어 개발 수명 주기는 애플리케이션 개발의 체계적인 프로세스를 의미한다.pp=46–47
## 타당성
소프트웨어 제품에 대한 아이디어의 원천은 풍부하다. 이러한 아이디어는 잠재적인 신규 고객의 인구 통계, 기존 고객, 제품을 거부한 잠재 고객, 다른 내부 소프트웨어 개발 직원 또는 창의적인 제3자를 포함한 시장 조사에서 나올 수 있다. 소프트웨어 제품에 대한 아이디어는 일반적으로 먼저 마케팅 담당자가 경제적 타당성, 기존 유통 채널과의 적합성, 기존 제품 라인에 대한 가능한 영향, 필요한 기능 및 회사의 마케팅 목표와의 적합성을 평가한다. 마케팅 평가 단계에서는 비용 및 시간 가정이 평가된다.p=1.10 타당성 분석은 프로젝트의 투자자본수익률, 개발 비용 및 기간을 추정한다. 이 분석을 기반으로 회사는 추가 개발에 투자할지 여부에 대한 사업 결정을 내릴 수 있다.p=7 소프트웨어 개발을 결정한 후, 회사는 추정된 비용 및 시간 내에, 높은 품질 표준(즉, 버그 없음)과 원하는 기능을 갖춘 제품을 제공하는 데 중점을 둔다. 그럼에도 불구하고 대부분의 소프트웨어 프로젝트는 지연되며, 때로는 마감일을 맞추기 위해 기능이나 품질에서 타협이 이루어진다.pp=3, 8
## 분석
소프트웨어 분석은 소프트웨어의 비즈니스 요구 사항을 파악하기 위한 요구사항 분석으로 시작된다.p=8 요구 사항 식별의 과제는 현재 또는 잠재적 사용자가 다르거나 호환되지 않는 요구 사항을 가질 수 있고, 자신의 요구 사항을 이해하지 못할 수 있으며, 소프트웨어 개발 과정에서 요구 사항을 변경할 수 있다는 것이다.pp=2-3 궁극적으로 분석의 결과는 개발자가 작업할 수 있는 제품에 대한 상세한 사양이다. 소프트웨어 분석가는 종종 비용 효율성, 효율성 및 신뢰성 향상을 위해 프로젝트를 더 작은 객체, 재사용 가능한 구성 요소로 분해한다.p=8 프로젝트를 분해하면 멀티프로세서 컴퓨터에서 훨씬 빠르게 실행되는 다중 스레드 구현이 가능해진다.pp=193–194 소프트웨어 개발의 분석 및 설계 단계에서 구조적 분석은 고객의 요구 사항을 소프트웨어 프로그래머가 구현할 수 있는 조각으로 분해하는 데 자주 사용된다.pp=103-104 프로그램의 기본 논리는 데이터 흐름도, 데이터 사전, 의사코드, 상태 전이도 및 개체-관계 다이어그램으로 표현될 수 있다.pp=117, 127, 131, 137, 141 프로젝트에 모델링되지 않은 레거시 소프트웨어 조각이 포함된 경우, 이 소프트웨어를 모델링하여 새로운 소프트웨어와 올바르게 통합되었는지 확인하는 데 도움이 될 수 있다.p=106
## 설계
소프트웨어 설계 설계는 어떤 프로그래밍 언어와 데이터베이스 소프트웨어를 사용할지, 또는 하드웨어 및 네트워크 통신이 어떻게 구성될지와 같은 소프트웨어 구현에 대한 선택을 포함한다. 설계는 시행착오 과정을 통해 사용자와 그들의 요구 사항에 대해 협의하면서 반복적으로 이루어질 수 있다. 설계에는 종종 데이터베이스 설계, 화면 아키텍처, 서버 및 기타 하드웨어 성능과 같은 측면의 전문가들이 참여한다.p=8 설계자는 종종 소프트웨어 기능에서 패턴을 찾아내어 객체 지향 프로그래밍으로 재사용할 수 있는 별개의 모듈을 생성하려고 한다. 이의 한 예는 그래픽 사용자 인터페이스와 백엔드 사이의 인터페이스인 모델-뷰-컨트롤러이다.p=142
## 프로그래밍
컴퓨터 프로그래밍 소프트웨어 개발의 핵심은 원하는 기능을 구현하는 소프트웨어를 만들고 이해하는 것이다.p=31 코드를 작성하는 다양한 전략이 있다. 응집력 있는 소프트웨어는 서로 독립적인 다양한 구성 요소를 가지고 있다.p=8 결합은 서로 다른 소프트웨어 구성 요소 간의 상호 관계를 나타내는데, 이는 유지 보수의 어려움을 증가시키므로 바람직하지 않은 것으로 간주된다.pp=8–9 종종 소프트웨어 프로그래머는 업계 모범 사례를 따르지 않아 비효율적이거나 이해하기 어렵거나 기능에 대한 문서화가 부족한 코드를 생성한다.pp=31-32 이러한 표준은 특히 마감일이 임박했을 때 무너지기 쉽다.pp=34-35 결과적으로 코드 테스트, 디버깅 및 수정이 훨씬 더 어려워진다. 예를 들어 코드에 더 많은 주석을 추가하는 리팩터링은 코드의 이해도를 향상시키는 해결책이다.pp=31-32, 35
## 테스트
소프트웨어 테스트 테스트는 코드가 오류 없이 올바르게 실행되는지 확인하는 과정이다. 각 소프트웨어 개발자는 자신의 코드에 대해 디버그를 수행하여 코드가 의도한 대로 작동하는지 확인한다. 특히, 결과가 정확하지 않더라도 소프트웨어가 모든 입력에 대해 실행되는 것이 중요하다.p=9 다른 개발자들의 코드 검토는 프로젝트에 추가된 새 코드를 면밀히 조사하는 데 자주 사용되며, 일부 추정치에 따르면 테스트 완료 후에도 남아있는 버그의 수를 극적으로 줄인다.p=272 코드가 제출되면, 대부분의 대기업에서는 비프로그래머로 구성된 별도의 부서인 품질 보증이 전체 소프트웨어 제품의 정확성을 테스트한다. 원래 소프트웨어 요구 사항에서 파생된 인수 테스트는 이를 위한 인기 있는 도구이다.p=9 품질 테스트에는 또한 스트레스 및 부하 검사(소프트웨어가 높은 수준의 입력 또는 사용에 견고한지 여부), 통합 시험 (소프트웨어가 다른 소프트웨어와 적절하게 통합되었는지 확인), 호환성 테스트 (다른 운영체제 또는 브라우저에서 소프트웨어의 성능 측정)가 포함되는 경우가 많다.p=9 코드를 작성하기 전에 테스트를 작성하는 것을 테스트 주도 개발이라고 한다.p=9
## 프로덕션
프로덕션은 소프트웨어가 최종 사용자에게 배포되는 단계이다.p=10 프로덕션 중에 개발자는 사용자를 위한 기술 지원 리소스를 생성하거나p=37p=10 이전에 발견되지 않은 버그 및 오류를 수정하는 프로세스를 생성할 수 있다. 사용자 요구 사항이 변경되거나 오해되었을 경우 초기 개발 단계로 돌아갈 수도 있다.p=10
# 작업자
소프트웨어 개발은 일반적으로 팀으로 일하는 **소프트웨어 개발자**가 수행한다. 팀 구성원 간의 효율적인 의사소통은 성공에 필수적이다. 팀이 작고, 함께 일하는 데 익숙하며, 서로 가까운 곳에 위치할 경우 더 쉽게 달성할 수 있다.p=2 의사소통은 또한 개발 초기 단계에서 문제를 식별하고 중복된 노력을 피하는 데 도움이 된다. 많은 개발 프로젝트는 여러 작업자가 각 구성 요소에 익숙하도록 하여 한 직원만 가지고 있는 필수 지식을 잃을 위험을 피한다.pp=30–31 소프트웨어 개발에는 프로그래머뿐만 아니라 제품의 전략과 로드맵을 설정하는 제품 관리자,language=en 테스트, 문서 작성, 그래픽 디자인, 사용자 지원, 마케팅, 모금 전문 인력 등 다양한 분야의 전문가들이 참여한다. 독점 소프트웨어 작업자는 급여를 받지만, 대부분의 오픈 소스 소프트웨어 기여자는 자원 봉사자이다.p=7 또는 소프트웨어 판매가 아닌 서비스 및 오픈 소스 소프트웨어 수정과 같은 다른 사업 모형을 가진 회사로부터 급여를 받을 수도 있다.pp=14-15
# 모델 및 도구

## 컴퓨터 지원 소프트웨어 공학
컴퓨터 지원 소프트웨어 공학 (CASE)은 소프트웨어 개발의 부분적 자동화를 위한 도구이다.p=22 CASE는 설계자가 프로그램의 논리를 스케치할 수 있게 하는데, 이는 작성될 프로그램이든, 또는 새로운 코드와 통합하거나 역공학하기 위한(예: 프로그래밍 언어 변경) 이미 존재하는 프로그램이든 상관없다.pp=108–110, 206
## 문서화
소프트웨어 문서화 문서화는 일반적으로 분리되어 유지되는 두 가지 형태로 제공된다. 하나는 소프트웨어 개발자를 위한 것이고, 다른 하나는 최종 사용자가 소프트웨어를 사용하는 데 도움이 되도록 제공된다.p=243p=192 대부분의 개발자 문서는 각 파일, 클래스 및 메서드에 대한 코드 주석 형태로 되어 있으며, 애플리케이션 프로그래밍 인터페이스 (API)—다른 소프트웨어 조각이 소프트웨어 조각에 접근하는 방법—와 종종 구현 세부 사항을 다룬다.pp=193–195 이 문서는 새로운 개발자가 프로젝트에 참여할 때 프로젝트를 이해하는 데 도움이 된다.p=143 애자일 개발에서는 문서가 종종 코드와 동시에 작성된다.p=144 사용자 문서는 기술 작가가 더 자주 작성한다.p=204
## 노력 추정
소프트웨어 개발 노력 추정 정확한 추정은 타당성 단계와 제품을 정시에 예산 범위 내에서 제공하는 데 매우 중요하다. 추정치 생성 과정은 종종 프로젝트 관리자에 의해 위임된다.pp=50–51 노력 추정은 완성된 애플리케이션의 크기와 직접적으로 관련되어 있기 때문에 요구 사항의 기능 추가에 크게 영향을 받는다. 즉, 요구 사항이 많을수록 개발 비용이 높아진다. 소프트웨어 개발자의 경험 및 코드 재사용성과 같이 기능과 관련 없는 측면도 추정에서 고려해야 할 필수 요소이다.pp=52–53 2019, 소프트웨어 개발에 필요한 시간과 자원량을 추정하는 대부분의 도구는 기존 애플리케이션용으로 설계되었으며 웹 애플리케이션 또는 모바일 애플리케이션에는 적용할 수 없다.p=45
## 통합 개발 환경
GNOME 환경용 C 및 C++ IDE인 Anjuta 통합 개발 환경 (IDE)은 단순한 문서 편집기에 비해 향상된 기능으로 소프트웨어 개발을 지원한다.p=68 IDE는 종종 자동화된 컴파일, 오류 구문 강조,p=236 디버깅 지원,p=239 버전 관리와의 통합 및 테스트의 반자동화를 포함한다.p=68
## 버전 관리
버전 관리 버전 관리는 소프트웨어 변경 사항을 관리하는 인기 있는 방법이다. 새 버전이 체크인될 때마다 소프트웨어는 수정된 모든 파일의 백업을 저장한다. 여러 프로그래머가 소프트웨어에서 동시에 작업하는 경우, 코드 변경 사항의 병합을 관리한다. 소프트웨어는 두 가지 변경 세트 간에 충돌이 있는 경우를 강조 표시하고 프로그래머가 충돌을 해결할 수 있도록 한다.pp=246–247
## 뷰 모델
TEAF 뷰 및 관점 매트릭스 뷰 모델은 소프트웨어 개발 프로세스에서 사용될 시스템과 그 환경에 대한 관점을 제공하는 프레임워크이다. 이는 뷰의 기본 의미론을 그래픽으로 표현한 것이다. 관점과 뷰의 목적은 인간 엔지니어가 매우 복잡한 시스템을 이해하고 전문 지식 영역을 중심으로 문제의 요소를 조직화할 수 있도록 하는 것이다. 물리적으로 집중적인 시스템의 공학에서는 관점이 종종 공학 조직 내의 역량 및 책임에 해당한다.Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration date=25 January 2017 NIST 2003.
## 적합성 함수
적합성 함수는 새로운 개발이 설정된 제약 조건, 검사 및 규정 준수 통제에서 벗어나지 않도록 보장하는 자동화되고 객관적인 테스트이다.isbn=978-1492043454
# 지식 재산권
개발자가 오픈 소스 코드 또는 라이브러리를 독점 제품에 통합할 때 지식 재산권 문제가 발생할 수 있는데, 소프트웨어에 사용되는 대부분의 오픈 소스 라이선스는 수정 사항이 동일한 라이선스 하에 출시되어야 한다고 요구하기 때문이다. 대안으로, 개발자는 독점적인 대안을 선택하거나 자체 소프트웨어 모듈을 작성할 수 있다.pp=44-45