소프트웨어 구축
Software construction| 시리즈의 일부 |
| 소프트웨어 개발 |
|---|
소프트웨어 구축은 소프트웨어 엔지니어링 분야입니다.코딩, 검증, 유닛 테스트, 통합 테스트 및 디버깅의 조합을 통해 의미 있는 소프트웨어를 상세하게 만듭니다.이는 다른 모든 소프트웨어 엔지니어링 분야, 특히 소프트웨어 설계 [1]및 소프트웨어 테스트와 관련이 있습니다.
소프트웨어 구축의 기초
복잡성 최소화
복잡성을 줄여야 하는 필요성은 대부분의 사람들이 복잡한 구조와 정보를 작업 기억 속에 저장하는 능력이 제한적이기 때문입니다.스마트한 코드보다는 단순하고 읽기 쉬운 코드 작성을 강조함으로써 복잡성을 줄일 수 있습니다.복잡성을 최소화하는 것은 표준을 사용하고 코딩의 수많은 특정 기술을 통해 달성됩니다.또한 건설 중심의 품질 [2]기술에 의해 지원됩니다.
변화를 예상하다
변화를 예상하면 소프트웨어 엔지니어는 확장 가능한 소프트웨어를 구축할 수 있습니다.즉, 기본 [2]구조를 방해하지 않고 소프트웨어 제품을 강화할 수 있습니다.25년에 걸친 연구에 따르면, 재작업 비용은 처음에 요건을 제대로 충족하는 것보다 10~100배(소규모 프로젝트의 경우 5~10배) 더 비쌀 수 있습니다.평균 프로젝트 개발 중에 요구사항의 25%가 변경된다는 점을 감안하면, 재작업 비용을 절감해야 하는 필요성은 변화를 예상해야 할 필요성을 분명히 합니다.[3]
검증을 위한 구성
검증을 위해 구축한다는 것은 소프트웨어를 작성하는 소프트웨어 엔지니어가 독립된 테스트 및 운영 활동 중에 결함을 쉽게 탐지할 수 있도록 소프트웨어를 구축하는 것을 의미합니다.검증을 위한 구축을 지원하는 특정 기술에는 [2]코드 검토, 단위 테스트, 자동화된 테스트를 지원하기 위한 코드 구성, 복잡하거나 이해하기 어려운 언어 구조의 제한된 사용이 포함된다.
재사용하다
체계적인 재사용을 통해 소프트웨어 생산성, 품질 및 비용을 크게 개선할 수 있습니다.재사용에는 밀접하게 관련된 두 [2]가지 측면이 있습니다.
- 재사용을 위한 구조:재사용 가능한 소프트웨어 자산을 생성합니다.
- 재사용을 수반하는 건설:새로운 솔루션 구축에 소프트웨어 자산을 재사용합니다.
시공기준
건설 문제에 직접 영향을 미치는 표준은 외부(국제기구에 의해 작성됨) 또는 내부(기업 차원에서 작성됨)에 관계없이 다음과 같습니다.[2]
공사 관리
건설 모형
소프트웨어를 개발하기 위해 수많은 모델이 개발되었으며, 그 중 일부는 다른 모델보다 건설을 강조합니다.폭포 및 단계별 배송 수명 주기 모델과 같이 시공 관점에서 보다 선형적인 모델도 있습니다.이러한 모델에서는 건설이 세부 요건 작업, 광범위한 설계 작업 및 세부 계획을 포함한 중요한 전제 조건이 완료된 후에만 발생하는 활동으로 간주됩니다.진화적 프로토타이핑, Extreme Programming 및 Scrum과 같은 다른 모델들은 더 반복적입니다.이러한 접근법은 구축을 요건, 설계 및 계획 등 다른 소프트웨어 개발 활동과 동시에 발생하거나 [1]중복되는 활동으로 취급하는 경향이 있습니다.
건설 계획
건설 방법의 선택은 건설 계획 활동의 중요한 측면입니다.시공 방법의 선택은 시공 전제 조건(요건 분석, 소프트웨어 설계 등)이 수행되는 정도, 수행 순서 및 시공 작업 전에 완료될 것으로 예상되는 정도에 영향을 미칩니다.또한 건설계획에서는 컴포넌트가 생성 및 통합되는 순서, 소프트웨어 품질 관리 프로세스, 특정 소프트웨어 엔지니어에게 할당되는 작업 및 기타 작업을 선택한 [1]방법에 따라 정의합니다.
시공측정
코드 개발, 코드 수정, 코드 재사용, 코드 파괴, 코드 복잡성, 코드 검사 통계, 고장 수리 및 고장 발견 비율, 작업 및 스케줄링 등 수많은 건설 활동과 아티팩트를 측정할 수 있습니다.이러한 측정은 건설 관리, 건설 중 품질 보장, 건설 공정 개선 및 기타 [1]이유로 유용할 수 있습니다.
실제 고려 사항
소프트웨어 구축은 다음과 같은 많은 실용적인 고려사항에 의해 추진됩니다.
건설 설계
소프트웨어 설계의 예상치 못한 차이를 설명하기 위해 소프트웨어 구축 중에 소프트웨어 [4]설계의 세부사항을 구체화하기 위해 일부 설계를 소규모 또는 대규모로 수정해야 합니다.
낮은 팬아웃은 연구자들이 유용한 설계 특성 중 하나입니다.정보 은닉은 4배까지 수정하기 쉬운 대형 프로그램에서 유용한 설계 기법임이 입증되었습니다.
구성 언어
구성 언어에는 인간이 컴퓨터에 실행 가능한 문제 해결 방법을 지정할 수 있는 모든 형태의 통신이 포함됩니다.여기에는 구성 언어, 툴킷 언어 및 프로그래밍 [6]언어가 포함됩니다.
- 구성 언어는 소프트웨어 엔지니어가 새로운 소프트웨어 설치 또는 커스텀 소프트웨어 설치를 작성하기 위해 제한된 사전 정의된 옵션 세트 중에서 선택하는 언어입니다.
- 툴킷 언어는 툴킷으로 애플리케이션을 빌드하기 위해 사용되며 구성 언어보다 복잡합니다.
- 스크립트 언어는 컴파일된 언어가 아닌 해석되는 스크립트를 지원하는 일종의 응용 프로그램 프로그래밍 언어입니다.
- 프로그래밍 언어는 다음 세 가지 일반적인 표기법을 사용하는 가장 유연한 유형의 구성 언어입니다.
- 특히 복잡한 소프트웨어 구조를 나타내기 위해 단어와 같은 문자열을 사용하고 이러한 단어와 같은 문자열을 문장과 같은 구문을 가진 패턴으로 조합함으로써 구별되는 언어 표기.
- 단어와 텍스트 문자열의 직관적이고 일상적인 의미에 덜 의존하며 정확하고 모호하지 않으며 형식적인(또는 수학적인) 정의에 의해 뒷받침되는 정의에 더 많이 의존하는 형식 표기.
- 언어적 및 형식적 구성의 텍스트 지향 표기에 훨씬 덜 의존하며 대신 기본 소프트웨어를 나타내는 시각적 실체의 직접적인 시각적 해석과 배치에 의존하는 시각적 표기는.
3년 이상 사용한 언어로 작업하는 프로그래머는 같은 언어를 처음 접하는 프로그래머보다 생산성이 약 30% 더 높습니다.C++, Java, Smalltalk, Visual Basic 등의 고급 언어는 어셈블리 및 C와 같은 하위 수준 언어에 비해 생산성, 신뢰성, 단순성 및 이해성이 5~15배 향상됩니다.이와 동등한 코드는 하위 [7]언어보다 상위 언어에서 구현해야 하는 행 수가 적은 것으로 나타났습니다.
코딩
소프트웨어 구축 코딩 [8]활동에는 다음 고려사항이 적용됩니다.
- 이름 지정 및 소스 코드 레이아웃을 포함하여 이해하기 쉬운 소스 코드를 만드는 기술입니다.한 연구에서는 변수의 이름이 10에서 16자 [9]사이일 때 프로그램을 디버깅하는 데 필요한 노력이 최소화된다는 것을 보여주었습니다.
- 클래스, 열거된 유형, 변수, 명명된 상수 및 기타 유사한 엔티티 사용:
- 제어 구조 사용:
- 오류 조건 처리: 계획된 오류와 예외(부정한 데이터 입력 등) 모두
- 코드 레벨 보안 침해 방지(버퍼 오버런 또는 어레이 인덱스 오버플로 등)
- 제외 메커니즘과 연속적으로 재사용 가능한 자원(스레드 또는 데이터베이스 잠금 포함)에 대한 접근 규율을 통한 자원 사용
- 소스 코드 구성(문 및 루틴으로):[11]
- 응집력이 높은 루틴은 응집력이 낮은 루틴보다 오류가 적은 것으로 나타났습니다.450개의 루틴을 조사한 결과 응집력이 높은 루틴의 50%가 결함이 없는 것으로 나타났는데 비해 응집력이 낮은 루틴은 18%에 불과했다.다른 450개의 루틴에 대한 또 다른 연구에서는 커플링 대 접착 비율이 가장 높은 루틴은 커플링 대 접착 비율이 가장 낮은 루틴보다 오류가 7배 더 많았고 수정 비용이 20배 더 많이 들었다.
- 비록 연구에서 루틴의 크기와 오류율 사이의 상관관계에 대한 결정적인 결과가 나왔지만, 한 연구는 코드 줄이 143줄 미만인 루틴이 큰 루틴보다 수정 비용이 2.4배 더 적게 든다는 것을 발견했습니다.또 다른 연구에서는 루틴이 평균 100~150줄의 코드를 최소로 변경할 필요가 있는 것으로 나타났다.또 다른 연구에서는 구조 복잡성과 루틴의 데이터 양이 크기에 관계없이 오류와 상관관계가 있는 것으로 나타났다.
- 루틴 간의 인터페이스는 프로그램에서 가장 오류가 발생하기 쉬운 영역 중 하나입니다.한 연구는 모든 오류의 39%가 일상 간의 의사소통 오류라는 것을 보여주었다.
- 사용하지 않는 파라미터는 에러율 증가와 상관관계가 있습니다.한 연구에서 참조되지 않은 변수가 두 개 이상 있는 루틴 중 오류가 없는 루틴은 17~29%에 불과했지만 사용되지 않은 변수가 없는 루틴은 46%였습니다.
- 한 번에 약 7개 이상의 정보를 추적할 수 없다는 연구 결과가 나왔기 때문에 루틴의 매개 변수 수는 최대 7개여야 한다.
- 소스 코드 구성(클래스, 패키지 또는 기타 구조체).격납을 고려할 때 클래스의 최대 데이터 멤버 수는 7±2를 초과할 수 없습니다.연구에 따르면 이 숫자는 사람이 다른 작업을 수행하는 동안 기억할 수 있는 개별 항목의 수인 것으로 나타났다.상속을 고려할 때는 상속 트리의 수준 수를 제한해야 합니다.심층 상속 트리는 장애율 증가와 상당한 관련이 있는 것으로 확인되었습니다.수업의 루틴 수를 고려할 때, 그것은 가능한 한 작게 유지되어야 한다.C++ 프로그램에 대한 연구는 루틴 수와 결함 [10]수 사이의 연관성을 발견했습니다.
- 코드 문서
- 코드 튜닝
시공 테스트
구성 테스트의 목적은 고장이 코드에 삽입되는 시간과 고장이 감지되는 시간 사이의 간격을 줄이는 것입니다.코드 작성 후 시공 테스트를 수행하는 경우도 있습니다.테스트 우선 프로그래밍에서는 코드를 작성하기 전에 테스트 케이스를 작성합니다.구축에는 [1]두 가지 형태의 테스트가 수반되며, 이러한 테스트는 코드를 작성한 소프트웨어 엔지니어가 수행하는 경우가 많습니다.
재사용하다
소프트웨어 재사용 구현은 자산 라이브러리를 만들고 사용하는 것 이상을 수반합니다.재사용 프로세스와 활동을 소프트웨어 라이프 사이클에 통합함으로써 재사용 관행을 공식화할 필요가 있습니다.코딩 및 테스트 중 소프트웨어 구축 시 재사용과 관련된 작업은 다음과 같습니다.[1]
- 재사용 가능한 단위, 데이터베이스, 테스트 절차 또는 테스트 데이터 선택.
- 코드 평가 또는 재사용 가능성 테스트.
- 새 코드, 테스트 절차 또는 테스트 데이터에 대한 재사용 정보 보고.
시공품질
구성 시 코드의 품질을 보장하기 위해 사용되는 주요 기술은 다음과 같습니다.[15]
- 유닛 테스트 및 통합 테스트한 연구에 따르면 유닛 테스트와 통합 테스트의 평균 결함 검출률은 각각 [16]30%, 35%입니다.
- 테스트 우선 개발
- 어설션 및 방어 프로그래밍 사용
- 디버깅
- 검사.한 연구에 따르면 정식 코드 검사의 평균 결함 검출률은 60%입니다.결함 발견 비용과 관련하여 코드 판독이 테스트보다 시간당 80% 더 많은 결함을 감지했다는 연구 결과가 있습니다.또 다른 연구에서는 검사를 사용하는 것보다 검사를 사용하여 설계 결점을 발견하는 데 6배나 더 많은 비용이 든다고 합니다.IBM의 연구에 따르면 코드 검사를 통해 결함을 발견하는 데 필요한 시간은 3.5시간인 반면 테스트를 통해 15-25시간인 것으로 나타났습니다.MS는 코드 검사를 통해 결함을 찾아 수리하는 데 3시간, 테스트를 통해 결함을 찾아 수리하는 데 12시간이 걸린다는 사실을 밝혀냈다.70만 회선의 프로그램에서 코드 리뷰는 [16]테스트보다 몇 배나 비용 효율적이라고 보고되었습니다.연구에 따르면 검사 결과 코드 1000줄당 결함이 공식 검토 방식보다 20~30% 감소하고 생산성이 약 20% 향상되는 것으로 나타났습니다.정식 검사에는 보통 프로젝트 예산의 10~15%가 소요되며 전체 프로젝트 비용이 절감됩니다.연구진은 [17]검사하는 물질의 종류에 따라 결과가 달라 보이기는 하지만, 2 - 3명 이상의 검토자가 공식 검사에 참여한다고 해서 발견된 결점의 수가 증가하지는 않는다는 것을 발견했습니다.
- 기술 리뷰한 연구에 따르면 비공식 코드 리뷰와 데스크 체크의 평균 결함 검출률은 각각 [16]25%, 40%입니다.워크스루에서는 결함검출률이 20~40%에 달하지만, 특히 프로젝트 압력이 높아질 때 비용이 많이 드는 것으로 나타났습니다.NASA는 코드 판독을 통해 작업 시간당 3.3개의 결함과 테스트 시간당 1.8개의 결점을 검출했습니다.또한 프로젝트 수명 동안 다양한 종류의 테스트보다 20~60% 더 많은 오류를 발견할 수 있습니다.검토회의에 대한 13건의 검토 결과, 90%의 결함이 검토회의 준비 과정에서 발견되었으며,[17] 회의 중 약 10%만이 발견된 것으로 나타났습니다.
- 정적 분석(IEEE1028)
연구에 따르면 높은 결함 검출률을 달성하려면 이러한 기술의 조합을 사용해야 합니다.다른 연구들은 다른 사람들이 다른 결점을 찾는 경향이 있다는 것을 보여주었다.한 연구에서는 페어 프로그래밍, 데스크 체크, 유닛 테스트, 통합 테스트 및 회귀 테스트와 같은 극단적인 프로그래밍 관행이 90%의 결함 감지율을 [16]달성할 수 있다는 것을 발견했습니다.숙련된 프로그래머를 대상으로 한 실험에서 평균적으로 테스트를 [18]통해 15개의 오류 중 5개(기껏해야 9개)의 오류를 찾을 수 있었습니다.
오류의 80%는 프로젝트 클래스 및 루틴의 20%에 집중되는 경향이 있습니다.오류의 50%는 프로젝트 클래스의 5%에서 발견됩니다.IBM은 425개 클래스 중 31개 클래스만 수리 또는 재작성하여 고객이 보고한 결함을 10대 1로 줄이고 IMS 시스템의 유지보수 예산을 45% 절감할 수 있었습니다.프로젝트 루틴의 약 20%가 개발 비용의 80%에 기여합니다.IBM의 고전적인 연구에 따르면 OS/360에서 오류가 발생하기 쉬운 루틴이 가장 비싼 엔티티인 경우는 거의 없는 것으로 나타났습니다.코드 1000줄당 약 50개의 결함이 있었고,[18] 이를 수리하는 데 전체 시스템 개발에 소요된 비용의 10배가 소요되었습니다.
통합
구축 시 주요 활동은 별도로 구성된 루틴, 클래스, 구성 요소 및 하위 시스템의 통합입니다.또한 특정 소프트웨어 시스템을 다른 소프트웨어 또는 하드웨어 시스템과 통합해야 할 수도 있습니다.시공 통합과 관련된 우려 사항에는 구성 요소가 통합되는 순서 계획, 소프트웨어의 중간 버전을 지원하는 발판 작성, 구성 요소가 통합되기 전에 수행되는 테스트 및 품질 작업의 정도 결정, 프로젝트 내 중간 버전이 통합되는 시점 결정 등이 포함됩니다.소프트웨어가 [1]테스트된 경우.
건설 기술
객체 지향 런타임 문제
객체 지향 언어는 데이터 추상화, 캡슐화, 모듈화, 상속, 다형성 및 [19][20]리플렉션과 같은 프로그램의 유연성과 적응성을 높이는 일련의 런타임 메커니즘을 지원합니다.
데이터 추상화는 구현 [21]세부사항을 숨기면서 데이터와 프로그램을 의미와 유사한 형태로 정의하는 프로세스입니다.학술 조사에 따르면 데이터 추상화는 기능적인 [10]프로그램보다 프로그램을 약 30% 더 쉽게 이해할 수 있습니다.
어설션, 계약에 의한 설계 및 방어적 프로그래밍
어설션은 실행 가능한 술어로 프로그램의 런타임 [19]체크를 허용하는 프로그램에 배치됩니다.계약에 의한 설계는 각 루틴에 대한 전제 조건과 사후 조건이 포함된 개발 접근법이다.방어적 프로그래밍은 잘못된 [22]입력에 의해 루틴이 중단되는 것을 방지하는 것입니다.
오류 처리, 예외 처리 및 폴트 톨러런스
오류 처리는 프로그램 실행 시 발생할 수 있는 오류 조건을 예측하고 코드화하는 프로그래밍 연습입니다.예외 처리는 프로그램 [23]실행의 정상적인 흐름을 변경하는 예외, 즉 특별한 조건의 발생을 처리하기 위해 설계된 프로그래밍 언어 구성 또는 하드웨어 메커니즘입니다.폴트 톨러런스는 오류를 검출한 후 가능한 경우 오류를 복구하거나 복구가 [22]불가능한 경우 오류를 억제하여 소프트웨어의 신뢰성을 높이는 기술 모음입니다.
상태 기반 및 테이블 기반 구축 기술
상태 기반 프로그래밍은 프로그램 동작을 설명하기 위해 유한 [22]상태 기계를 사용하는 프로그래밍 기술입니다.테이블 구동 방식은 논리문(if 및 case [24]등)을 사용하지 않고 테이블을 사용하여 정보를 검색하는 스키마입니다.
런타임 구성 및 국제화
런타임 구성은 프로그램 실행 시 변수 값과 프로그램 설정을 바인딩하는 기술로, 보통 JIT(Just-In-Time) 모드에서 구성 파일을 업데이트하고 읽습니다.국제화는 여러 로케일을 지원하는 프로그램(일반적으로 인터랙티브 소프트웨어)을 준비하는 기술 활동입니다.대응하는 액티비티(현지화)는 특정 로컬 언어를 [24]지원하도록 프로그램을 수정하는 액티비티입니다.
「 」를 참조해 주세요.
메모들
- ^ a b c d e f g 스웨복 Pierre Bourque; Robert Dupuis; Alain Abran; James W. Moore, eds. (2004). "Chapter 4: Software Construction". Guide to the Software Engineering Body of Knowledge. IEEE Computer Society. pp. 4–1–4–5. ISBN 0-7695-2330-7.
- ^ a b c d e SWEBOK 2014, 3-3페이지.
- ^ McConnell 2004, 3장.
- ^ SWEBOK 2014, 3-5페이지.
- ^ McConnell 2004, 5장.
- ^ SWEBOK 2014, 3-5-3-6페이지.
- ^ McConnell 2004, 제4장.
- ^ SWEBOK 2014, 페이지 3~6.
- ^ McConnell 2004, 11장.
- ^ a b c McConnell 2004, 6장.
- ^ a b McConnell 2004, 7장.
- ^ McConnell 2004, 12장.
- ^ a b McConnell 2004, 16장.
- ^ a b McConnell 2004, 19장.
- ^ SWEBOK 2014, 3-7페이지.
- ^ a b c d McConnell 2004, 20장.
- ^ a b McConnell 2004, 21장.
- ^ a b McConnell 2004, 22장.
- ^ a b SWEBOK 2014, 페이지 3-8.
- ^ Thayer 2013, 페이지 140–141. 오류:: 2013
- ^ Thayer 2013, 페이지 140. 오류:: 2013
- ^ a b c SWEBOK 2014, 페이지 3-9.
- ^ Thayer 2013, 페이지 142. 오류:: 2013
- ^ a b SWEBOK 2014, 페이지 3-10.
레퍼런스
- Pierre Bourque; Richard E. Fairley, eds. (2014). "Chapter 3: Software Construction". Guide to the Software Engineering Body of Knowledge Version 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1.
- McConnell, Steven (2004). Code Complete (2nd ed.). Microsoft Press. ISBN 978-0-7356-1967-8.
- Thayer, Richard; Dorfman, Merlin (2013). Software Engineering Essentials. Vol. I: The Development Process (Fourth ed.). Software Management Training Press, Carmichael, California. ISBN 978-0-9852707-0-4.
