Introduction
•
S/W 작성이란 용어는 코딩, 검증, 단위/통합 시험 및 디버깅의 조합을 통해 동작 가능하고 의미 있는 S/W를 뜻함.
•
모든 KA와 연계되지만 가장 관련 있는 KA는 설계와 시험으로, 작성은 설계의 출력임과 동시에 시험의 입력임.
•
작성에 앞서 세부 설계가 이루어지지만 많은 설계 작업이 작업 활동 자체에서 이루어짐
•
작성 전체에 걸쳐 단위/통합 시험이 이루어짐
•
S/W 작성은 보통 다수의 관리가 필요한 구성 항목(소스 파일, 컨텐츠, 테스트케이스 등)을 만들어냄. 그러므로 S/W 구성 KA 역시 S/W 작성 KA와 연계됨
•
S/W 작성은 도구와 방법에 크게 종속되어 가장 도구에 집중되는 KA이므로 SWE 도구 및 방법 KA와도 연계
•
모든 KA에서 S/W 품질이 중요함과 동시에 코드는 S/W 프로젝트의 최종 전달물이므로 S/W 품질도 연계
•
SWE의 관련 규율(discipline) 중 S/W 작성 KA는 알고리즘과 세부 코딩 작업이란 컴퓨터 과학 영역의 것에 관계됨. 또한 프로젝트 관리하고도 연계됨.
Breakdown of topics
1. S/W 작성 기본(Software Construction Fundamentals)
S/W 작성 기본에는 아래 나열된 목록이 포함되어, 첫 3개 개념은 작성 뿐 아니라 설계에도 적용됨.
1.1. 복잡도 최소화(Minimizing Complexity)
인간의 의도를 컴퓨터에 옮기기는 인간의 제한된 능력인 기억력에 의존함. 이로 인해 S/W 작성의 가장 큰 동력은 복잡도의 최소화에 있음. 복잡도를 줄이는 것은 S/W 작성에 대한 검증과 시험 프로세스에 특히나 중요.
S/W 작성에서 복잡도를 줄인다는 것은 코드를 단순하고 읽기 쉽게 작성한다는 것임(not clever but simple, readable).
또한 1.4 작성 표준에서 논의하는 표준을 사용하고 '3.3 코딩'에서 요약하는 많은 기법을 사용하는 것 역시 복잡도를 줄이는 방법임. '3.5 작성 품질'의 작성-집중(construction-focused) 품질 기법 또한 복잡도를 줄이는 방법임.
1.2. 변화 예상(Anticipating Change)
S/W는 변하기 마련이며 변화의 예상은 S/W 작성의 많은 면에 영향을 줌. S/W는 외부 환경 변화를 피할 수 없음. 변화 예상은 3.3. 코딩 토픽의 많은 기법을 통해 이룸.
1.3. 검증 가능 작성(Constructing for Verification)
검증 가능 작성이란 S/W를 만들 때 S/W 구현, 시험 및 운영 중에 결함을 미리 발견 가능하도록 구현함을 뜻함. 구현 가능 작성을 가능케 하는 기법은 코드 검토, 단위 시험, 시험 자동화를 지원하는 코드 구성, 복잡 요소 제한 및 난해한 언어 구조 제한을 지원함.
1.4. 작성에서의 표준(Standards in Construction)
작성 이슈에 직접적 영향을 미치는 표준으로,
•
의사소통 방법(ex. 문서 형식 및 내용에 대한 표준)
•
프로그래밍 언어(ex. Java나 C++과 같은 언어 표준)
•
플랫폼(ex. OS 호출을 위한 API 표준)
•
도구(ex. UML과 같은 도식적 표기를 위한 표준)이 있음.
외부 표준 사용 : 작성은 작성 언어, 작성 도구, 기술적 인터페이스 및 S/W 작성과 타 KA 간 상호작용을 위한 타 표준의 사용에 영향을 받음. 표준에는 IEEE나 ISO와 같은 국제 조직이나 H/W, S/W 인터페이스 명세를 다루는 OMG이 있음.
내부 표준 사용 : 표준은 조직 협력 수준에서의 조직 기반이나 특정 프로젝트에서 사용하기 위해 생성됨. 이들 표준은 그룹 활동 조정, 복잡도 감소, 변화 예상, 검증 가능 작성을 지원.
2. 작성 관리(Managing Construction)
2.1. 작성 모형(Construction Models)
S/W 개발을 위한 다양한 모형이 있는데, 이들 중 몇몇은 타 모형에 비해 작성을 좀더 강조함.
폭포수나 단계적 인수 생명주기 모형 등의 몇몇 모형은 작성 관점으로 보았을 때 좀더 선형적이며, 이들에서의 작성 단계는 주루 코딩을 강조함.
진화적 프로토타이핑, XP, 스크럼 등의 좀더 반복적 모델에서는 작성이 요구사항이나 설계, 계획과 병행하여 이루어지거나 중복되기도. 이들 접근법에서는 설계, 코딩 및 시험 활동이 섞여, 각 활동의 조합을 작성으로 다룸.
결론적으로 '작성'이란 각 생명주기 모형에 따라 달라짐.
2.2. 작성 계획(Construction Planning)
작성 방법의 선택은 계획 활동의 핵심으로, 본 선택은 작성 선결조건의 수행 여부 범위까지 영향을 미침. 작성 접근법은 복잡도 감소, 변화 예상, 검증을 위한 작성을 위한 프로젝트의 능력에 영향을 미치며, 이들 각각의 목표는 요구사항 및 설계단계 프로세스에서도 중요시 되는데, 이들 프로세스 역시 작성 기법 선택의 영향을 받음.
작성 계획은 선택한 방법에 따라 컴포넌트의 생성 및 통합 순서, S/W 품질 관리 공정, 작업 할당 및 타 작업을 정의
2.3. 작성 측정기준(Construction Measurement)
수많은 작성 활동 및 산출물, 즉 코드 개발, 수정, 재사용, 파기, 코드 복잡도, 코드 인스펙션 통계, 결함-수정/결함-발견 비율, 노력, 일정 등 모두 측정 대상임. 이들 측정물은 작성 관리, 작성 중 품질 검증, 작성 공정 향상 등 다양한 부분에서 유용함. SWE 공정 KA 참조.
3. 실제적 고려사항(Practical Considerations)
작성은 임의적이고 혼돈적인 실세계의 제한조건을 받아들이고 정확히 실행해야 하는 활동임. 실세계의 제한조건에 근접하기 위해 작성은 타 KA보다 실제적 고려사항의 영향을 더 많이 받으며, 본 영역에서 SWE는 가장 공예적(craft-like)이게 됨.
3.1. 작성 설계(Construction design)
몇몇 프로젝트에서는 작성에 설계 활동이 이루어지는데, 이는 실세계의 문제가 야기하는 변경 불가능한 제한조건에 기인함. 물리적 구조를 만드는 작성자(construction worker)가 소규모 수정을 통해 기존 계획에서 발생한 예상치 못한 차이(gap)를 메우는 데 적응해야 하는 듯이, S/W 작성자 역시 수정을 통해 S/W 설계의 세부 사항에 살을 붙여야 함.
작성 단계에서의 설계 세부 활동은 S/W 설계 KA의 그것과 본질적으로 동일하지만, 좀더 작은 규모에 적용된다는 점이 다름.
3.2. 작성 언어(Construction Languages)
작성 언어는 인간이 컴퓨터에 실행 가능한 문제 해결책을 지정 가능한 모든 형태의 의사소통을 포함함. 가장 단순한 작성 언어는 구성(configuration) 언어, 즉 기 정의된 일정의 옵션을 통해 새 S/W 설치를 가능케 하는 언어임. Windows와 Unix의 텍스트 기반 구성 파일이나 메뉴 스타일은 이에 대한 한 예임
툴킷(toolkit; 응용프로그램에 특화된 재사용부의 통합 집합(integrated set)) 언어 역시 구성 언어보다는 복잡하지만 작성 언어로서, 스크립트(script)가 여기에 포함됨.
프로그래밍 언어는 가장 유연한 형태의 작성 언어로, 특정 응용 영역 및 개발 프로세스에 대한 최소한의 정보만을 지니기에 효과적인 사용을 위해 훈련과 기술(skill)을 요구함. 본 언어에 사용되는 일반적 표기법은 다음과 같이 세 가지로 분류됨.
•
언어적(linguistic)
•
정형적(formal)
•
시각적(visual)
언어적 표기법은 복잡한 S/W 작성을 표현하는 데 텍스트의 단어적 열(word-like string)과 이들의 조합인 문장적 구문(sentence-like syntax) 패턴을 사용하며, 적절히 사용될 경우 직관적인 이해를 가능케 하는 강력한 의미론적 함축을 가능케 함.
정형적 표기법은 덜 직관적이지만 각 단어와 텍스트 문자열에 정확하고, 명확하며, 정형적(또는 수학적)인 정의가 담김. 정형 작성 표기법과 정형 기법(formal method)은 시스템 프로그래밍, 즉 정확성, 시간 행동(time behavior), 시험용이성(testability)이 중요시되는 영역의 핵심임. 정형 작성은 또한 정확히 정의된 방법, 즉 많은 자연어 기반 작성이 보이는 모호함을 제거하기 위한 조합 심볼을 사용.
시각적 표기법은 직접적이고 시각적 해석 및 S/W의 하부요소를 나타내는 시각적 요소(entity)의 배치에 사용. 시각적 요소의 이동 기반한 본 표기법은 복잡한 문장 구성에는 적합하지 않지만, 프로그램의 시각적 인터페이스에 대한 제작(build) 및 조정(adjust)과 일찍이 정의된 세부 행동에 대한 프로그래밍이 주를 이룰 경우 유용함.
3.3. 코딩(Coding)
다음과 같은 사항이 S/W 작성의 코딩 활동에 적용됨
•
이해 용이한 소스 코드의 생산 기법. 여기에는 네이밍(naming)과 소스 코드 배치(layout)이 포함
•
클래스, 열거형, 변수, 명명된 상수 및 이들과 유사한 요소(entity)
•
제어 구조의 사용
•
오류 조건 처리 - 계획된 오류 및 예외 포함
•
코드 수준의 보안 허점 방지
•
배제(exclusion) 메커니즘을 통한 자원 사용 및 직렬적 자원(쓰래드, DB lock 등) 접근 원칙
•
소스 코드 구성(organization; 문장, 루틴, 클래스, 패키지 등에 대한)
•
코드 문서화
•
코드 튜닝(tuning)
3.4. 작성 시험(Construction Testing)
작성 시에는 S/W 기술자에 의해 단위 및 통합 시험이 수행됨. 작성 시험의 목적은 코드에 결함이 삽입된 시간과 결함이 발견된 시간의 차이를 줄이는 데 있음. 작성 시험은 코드가 작성된 후 수행되기도 하며 코드 작성 전에 테스트케이스가 만들어지기도 함.
Construction testing typically involves a subset of types of testing, which are described in the Software Testing KA. For instance, construction testing does not typically include system testing, alpha testing, beta testing, stress testing, configuration testing, usability testing, or other, more specialized kinds of testing.
두 가지 표준이 있음. 하나는 IEEE 829-1998, IEEE Standard for Software Test Documentation이고, 다른 하나는 1008-1987, IEEE Standard for Software Unit Testing임. 본 시험에 상응하는 S/W 시험 KA는 2.1.1 단위 시험 및 2.1.2 통합 시험임.
3.5. 재사용(Reuse)
IEEE1517-99에서는 "S/W 재사용은 라이브러리(libraries of assets)의 생성과 사용 이상을 요구한다. S/W 재사용은 재사용 프로세스 및 활동을 S/W 생명주기에 통합하는 정형적 활동을 요구한다."라고 논함. 하지만 재사용은 S/W 작성에 매우 중요하므로 본 장에 포함.
S/W 작성에서 코딩과 시험 중 재사용이 관계되는 작업으로는
•
재사용 단위, 데이터베이스, 시험 절차 또는 시험 데이터의 선택
•
코드 또는 시험 재사용성의 평가
•
새 코드, 시험 절차 또는 시험 데이터에 대한 재사용 정보에 대한 보고가 있음.
3.6. 작성 품질(Construction Quality)
코드 품질을 검증할 수많은 기법이 있는데, 작성에서 사용되는 주요 기법으로는,
•
단위 시험 및 통합 시험(3.4. 작성 시험에서 논의됨)
•
시험 선도 개발(Test-first development; S/W 시험 KA의 2.2 시험 목적 참조)
•
코드 단계화(Code stepping)
•
단언문(assert) 사용
•
디버깅
•
기술 검토(Technical reviews; S/W 품질 KA의 3.3 기술 검토 참조)
•
정적 분석(Static analysis; IEEE1028. S/W 품질 KA의 3.3. 검토 및 감사 참조) 이 있음.
기법은 S/W의 본성과 S/W 기술자의 스킬에 따라 선택됨.
작성 품질 활동은 코드 및 소규모 설계 등의 코드에 밀접히 관련된 산출물에 집중됨.
3.7. 통합(Integration)
작성 중 핵심 활동 중 하나로 각기 나뉜 루틴, 클래스, 컴포넌트, 하위 시스템을 통합하는 것임. 또한 어떤 S/W 시스템은 타 S/W 또는 H/W 시스템과 통합되어야 하기도 함. 통합에 관련한 사항으로, 통합 대상 컴포넌트의 순서화, 임시 버전을 지원하기 위한 비계(scaffold) 생성, 통합 전의 컴포넌트에 대한 시험 및 품질 작업의 수준 결정, 임시 버전에 대한 시험 시점 결정이 있음.