[소프트웨어 공학] 04. Quality Configuration and Management

Software quality management(소프트웨어 품질 관리)

• 소프트웨어 제품에서 필요한 품질 수준이 달성되도록 보장하는 데에 중점을 둡니다.
• 세 가지 주요 관심사:
  • 조직 수준(Organization level)
    • 품질 관리(QM)는 고품질 소프트웨어로 이어질 조직 프로세스 및 표준의 체계(a framework of organizational processes and standards)를 수립하는 데 중점을 둡니다.
  • 프로젝트 수준(Project level)
    • QM은 특정 품질 프로세스(quality processes)의 적용과 이러한 계획된 프로세스가 따라졌는지 확인하는 데 관여합니다.
    • QM은 또한 프로젝트를 위한 품질 계획(quality plan) 수립에도 관심이 있습니다.

 

Quality management activities(품질 관리 활동)

• 품질 관리는 소프트웨어 개발 프로세스에 대한 독립적인 검사를 제공합니다.
• 품질 관리 프로세스(quality management process)는 프로젝트 산출물이 조직 표준 및 목표(organizational standards and goals)와 일치하는지 확인합니다.
• 품질 팀은 개발 팀과 독립적이어야 하므로 소프트웨어에 대한 객관적인 관점을 취할 수 있습니다.
  • 이를 통해 소프트웨어 개발 문제의 영향을 받지 않고 소프트웨어 품질에 대해 보고할 수 있습니다.

 

Software quality(소프트웨어 품질)

• 품질이란 제품이 그 명세를 충족해야 함(a product should meet its specification)을 의미합니다.
• 이는 소프트웨어 시스템에서 문제가 될 수 있습니다.
  • 고객의 품질 요구사항(효율성, 신뢰성 등)과 개발자의 품질 요구사항(유지보수성, 재사용성 등) 사이에 긴장이 있습니다.
  • 일부 품질 요구사항은 모호하지 않게 명시하기 어렵습니다.
  • 소프트웨어 명세는 보통 불완전하고 종종 일관성이 없습니다.
• 초점은 '규격 준수'(fitness for purpose : validation에 해당)보다는 '목적에 맞는 적합성'(specification conformance : verification)에 맞춰야 합니다.

 

Non-functional characteristics(비기능적 특성)

• 소프트웨어 시스템의 주관적 품질은 주로 비기능적 특성에 기반합니다.
• 이는 실제 사용자 경험을 반영합니다.
  • 만약 소프트웨어의 기능성이 예상과 다르다면, 사용자는 종종 이를 우회하여 원하는 작업을 찾습니다.
• 그러나 소프트웨어가 불안정하거나 너무 느리면 그들이 목표를 달성하는 것은 사실상 불가능합니다.

 

Quality conflicts(품질 충돌)

• 어떤 시스템도 모든 비기능적 속성에 대해 최적화될 수 없습니다. (it is not possible for any system to be optimized for all of the non-functional attributes)
  • 예를 들어, 강건성을 향상시키는 것은 성능 저하로 이어질 수 있습니다.
  • 예를 들어 보안 대 사용성 - 강력한 비밀번호, 이중 인증 등.
• 따라서 품질 계획은 개발 중인 소프트웨어에 대해 가장 중요한 품질 속성을 정의해야 합니다.
• 계획에는 또한 다음을 포함해야 합니다:
  • 품질 평가 프로세스의 정의
  • 유지보수성이나 강건성과 같은 품질이 제품에 존재하는지 평가하는 합의된 방법

 

Process and product quality(프로세스 및 제품 품질)

• 개발된 제품의 품질(The quality of a developed product)은 생산 프로세스의 품질(the quality of the production process)에 의해 영향을 받습니다.
• 이는 일부 제품 품질 속성 평가가 어려워 소프트웨어 개발에 중요합니다.
• 소프트웨어 프로세스와 제품 품질 간의 관계는 매우 복잡하고 잘 이해되지 않습니다.
  • 개인의 기술과 경험의 적용은 소프트웨어 개발에서 특히 중요합니다.
  • 외부 요인으로 인해 제품 품질이 저하될 수 있습니다.
  • 예) 가속화된 개발 일정.

 

Quality culture(품질 문화)

• 품질 관리자는 소프트웨어 개발에 책임이 있는 모든 사람이 제품 품질 달성에 전념하는 '품질 문화'(quality culture)를 개발하는 것을 목표로 해야 합니다.
• 팀이 작업의 품질에 대한 책임을 지고 품질 개선을 위한 새로운 접근 방식을 개발하도록 격려해야 합니다.
• 품질의 무형적인 측면에 관심이 있는 사람들을 지원하고 모든 팀원의 전문적인 행동을 장려해야 합니다.

 

Review and inspections(리뷰와 검사)

• 한 그룹이 프로세스나 시스템 및 그 문서의 전부 또는 일부를 검토하여 잠재적 문제를 찾습니다.
• 목표가 다른 다양한 리뷰 유형이 있습니다:
  • 결함 제거를 위한 검사(제품) (Inspections for defect removal(product));
    • 디버깅 과정과 유사
  • 진행 상황 평가를 위한 리뷰(제품 및 프로세스);
  • 품질 리뷰(제품 및 기준).

 

Program inspections(프로그램 검사)

• 동료 리뷰로서 엔지니어들이 이상 및 결함을 발견하기 위한 목적(the aim of discovering anomalies and defects)으로 시스템의 원천을 검사합니다.
• 검사는 시스템의 실행을 필요로 하지 않으므로(do not require execution of a system) 구현 전에 사용될 수 있습니다.
• 요구 사항, 설계, 구성 데이터, 테스트 데이터 등 시스템의 어떤 표현에도 적용될 수 있습니다.
• 프로그램 오류 발견에 효과적인 기술로 입증되었습니다.
• 정적 분석 vs 동적 분석

 

Inspection checklist(검사 체크리스트)

• 일반적인 오류의 체크리스트는 검사를 이끄는 데 사용되어야 합니다.
• 오류 체크리스트는 프로그래밍 언어에 의존적이며 언어에서 발생할 가능성이 있는 특정 오류를 반영합니다.
• 일반적으로 타입 체킹이 약할수록 체크리스트는 더 큽니다.
  • 예: 초기화, 상수 명명, 루프 종료, 배열 경계 등.
• 정적 분석 도구는 이러한 검사를 자동으로 수행하고 해당 체크리스트에 대한 보고서를 제공합니다.
  • 예) FindBugs(Java). IDE 오류/경고, Lint/린터 등.

Checklist

• 데이터 오류(Data faults)
  • 모든 프로그램 변수가 사용되기 전에 초기화 되었나요?
  • 모든 상수가 명명 되었나요?
  • 배열의 상한은 배열의 크기와 같아야 하나요, 아니면 크기 -1 이어야 하나요?
  • 문자열을 사용하는 경우, 구분자가 명확하게 지정되었나요?
  • 버퍼 오버플로우의 가능성이 있나요?
• 제어 오류(Control faults)
  • 각 조건문에 대해, 조건이 올바른가요?
  • 모든 루프가 종료될 것인가요 확실한가요?
  • 복합문이 올바르게 괄호로 묶여 있나요?
  • case 문에서, 가능한 모든 경우가 고려되었나요?
  • case 문에서 각 경우 후 break가 필요한 경우 포함되었나요?
• 입/출력 오류(Input/Output faults)
  • 모든 입력 변수가 사용되었나요?
  • 모든 출력 변수에 값이 할당되기 전에 출력이 되었나요?
  • 예상치 못한 입력이 데이터 손상을 일으킬 수 있나요?
• 인터페이스 오류(Interface faults)
  • 모든 함수 및 메소드 호출에 올바른 수의 파라미터가 있습니까?
  •  형식 매개변수 유형과 실제 매개변수 유형이 일치합니까?
  • 매개변수가 올바른 순서입니까?
  • 구성 요소가 공유 메모리에 액세스하는 경우 공유 메모리 구조의 모델이 동일합니까?
• 저장소 관리 오류(Storage managements faults)
  • 연결 구조가 수정될 경우, 모든 연결이 올바르게 재할당되었습니까?
  • 동적 저장소를 사용하는 경우, 공간이 올바르게 할당되었습니까?
  • 더 이상 필요하지 않은 공간이 명시적으로 해제되었습니까?
• 예외 관리 오류(Exception management faults)
  • 모든 가능한 오류 조건을 고려하였습니까?

 

Quality management and agile development(품질 관리 및 애자일 개발)

• 애자일 개발에서의 품질 관리는 문서 기반보다 비형식적입니다.
• 이것은 모든 팀 구성원이 소프트웨어 품질에 대해 책임감을 가지고 품질이 유지되도록 활동하는 '품질 문화'를 구축하는 데 의존합니다.(relies on establishing a quality culture)
• 애자일 커뮤니티는 ISO 9001에서 구현된 표준 기반 접근법과 품질 프로세스의 관료적 부담을 근본적으로 반대합니다.

 

Shared good practice(공유된 좋은 관행)

• 체크인 전 검사(Check before check-in) (commit)
  • 프로그래머는 코드를 빌드 시스템에 체크인하기 전에 다른 팀 구성원들과 자신의 코드 리뷰를 조직하는 책임이 있습니다.
• 빌드를 절대 깨지 마세요(Never break the build)
  • 팀 구성원은 시스템을 실패하게 만드는 코드를 체크인해서는 안됩니다.
  • 개발자는 전체 시스템에 대해 코드 변경 사항을 테스트하고 이러한 변경 사항이 예상대로 작동하는지 확신해야 합니다.
• 문제를 발견했을 때 수정하세요(Fix problems when you see them) 
  • 프로그래머가 다른 사람이 개발한 코드에서 문제나 불분명한 점을 발견한 경우, original developer에 이 사항을 전달하는 대신,이를 직접 수정할 수 있습니다.

 

리뷰와 애자일 방법론(Reviews and agile methos)

• 애자일 소프트웨어 개발에서 리뷰 프로세스는 대개 비형식적입니다.
  • 품질 문화에 의존하는 것이 특정한 형식적인 프로세스보다 중요합니다.
• 스크럼에서는 각 반복 이후에 소프트웨어 리뷰 회의(스프린트 리뷰)가 있어 품질 문제 및 문제에 대해 논의할 수 있습니다.
• 익스트림 프로그래밍에서는 페어 프로그래밍이 코드가 지속적으로 검토되고 다른 팀 구성원에 의해 리뷰되도록 합니다.

 

Configuration management(구성 관리)

• 소프트웨어 시스템은 개발 및 사용 중 지속적으로 변경됩니다.
• 구성 관리(Configuration management, CM, 회사에서 형상관리라고 함)는 변화하는 소프트웨어 시스템을 관리(managing  changing software systems)하기 위한 정책, 프로세스 및 도구와 관련이 있습니다.
• CM이 필요한 이유는 각 시스템 버전에 어떤 변경 사항, 어떤 component 버전이 포함되었는지 쉽게 알 수 없기 때문입니다
• CM은 다양한 개발자들에 의해 이루어진 변경사항을 통제하는 팀 프로젝트에 필수적입니다.

 

CM activities(CM 활동)

• 버전 관리(Version management)
  • 시스템 구성 요소의 다양한 버전을 추적하고 서로 다른 개발자들에 의한 변경사항이 서로 간섭하지 않도록 합니다.
• 시스템 빌딩(System building)
  • 프로그램 구성 요소, 데이터 및 라이브러리를 조립하여 실행 가능한 시스템을 생성하는 과정입니다.
• 변경 관리(Change management)
  • 소프트웨어에 대한 변경 요청을 추적하고 변경의 비용과 영향을 계산하여 변경사항을 실행할지 결정합니다.
• 릴리즈 관리(Release management)
  • 외부 릴리즈를 위한 소프트웨어를 준비하고 고객이 사용할 시스템 버전을 추적합니다.

 

Agile development and CM(애자일 개발과 CM)

• 애자일 개발은, 하루에 여러 번 변경되는 컴포넌트와 시스템을 다루는 곳에서, CM 도구 없이는 불가능합니다.
• 컴포넌트의 확정 버전은 공유 프로젝트 저장소에 보관되며 개발자들은 이를 자신의 작업 공간으로 복사합니다.
• 그들은 코드에 변경을 가한 후 자신의 컴퓨터에서 시스템 빌딩 도구를 사용하여 새 시스템을 테스트합니다.
  • 변경사항에 만족하면 수정된 컴포넌트를 프로젝트 저장소로 반환합니다.

 

Multi-version systems(다중 버전 시스템)

• 대규모 시스템의 경우, '작동'하는 하나의 버전만 있는 것이 아닙니다.
• 항상 여러 단계의 개발 단계에서 여러 버전의 시스템이 있습니다.
• 다양한 시스템 버전의 개발에 여러 팀이 관련될 수 있습니다.

 

Multi-version system development

 

• 아이폰 유저라면 IOS 버전을 생각해보면 파악하기 쉽다
  • IOS 17.3.1 --> Major Version : 17, Minor version : 3, 버그 수정용?:1

 

CM terminology

용어설명

기준선 (Baseline)	기준선은 시스템을 구성하는 컴포넌트 버전들의 모음입니다. 기준선은 통제되므로, 시스템을 구성하는 컴포넌트의 버전을 변경할 수 없습니다. 이는 항상 구성 요소들로부터 기준선을 재생성할 수 있다는 것을 의미합니다.
분기 (Branching)	기존 코드라인의 버전에서 새로운 코드라인을 생성하는 것입니다. 새로운 코드라인과 기존 코드라인은 독립적으로 개발될 수 있습니다.
코드라인 (Codeline)	소프트웨어 컴포넌트와 해당 컴포넌트에 의존하는 다른 구성 요소들의 버전 세트입니다.
구성 (버전) 제어 (Configuration (version) control)	시스템과 컴포넌트의 버전을 기록하고 유지하여 변경사항이 관리되고 시스템의 전체 수명 동안 컴포넌트의 버전이 식별되고 저장되도록 하는 과정입니다.
주선 (Mainline)	시스템의 다른 버전을 나타내는 기준선들의 순서입니다.

 

병합(Merging)	서로 다른 코드라인의 별도 버전을 병합하여 새로운 소프트웨어 컴포넌트 버전을 생성하는 것. 이전 코드라인의 분기로 생성될 수 있음.
릴리즈(Release)	사용자나 조직에 사용될 시스템의 버전.
저장소(Repository)	소프트웨어 컴포넌트의 버전과 변경사항에 대한 메타정보를 저장하는 공유 데이터베이스.
시스템 빌딩(System building)	컴포넌트와 라이브러리를 컴파일하고 링크하여 실행 가능한 시스템 버전을 생성하는 과정.
버전(Version)	다른 항목의 인스턴스와 다른 방식으로 다른 구성 항목의 인스턴스. 버전은 항상 고유한 식별자를 가짐.
작업 공간(Workspace)	다른 개발자들이 사용하거나 수정할 수 있는 소프트웨어를 방해 받지 않고 수정할 수 있는 개인 작업 영역.

 

 

Version managment(버전 관리)

• 버전 관리(Version management, VM)는 소프트웨어 구성 요소나 설정 항목의 다양한 버전을 추적하고 사용하는 시스템을 관리하는 과정입니다.
• 다른 개발자들이 이러한 버전에 변경을 가할 때(changes made by different developers) 서로 간섭하지 않도록 하는 것(do not interfere with each other)을 포함합니다.
• 따라서 버전 관리는 코드 라인과 베이스라인을 관리하는 과정으로 생각할 수 있습니다.
• 버전 관리 활동은 버전 제어 시스템(Version Control System, VCS)과 통합 개발 환경(IDE)에 의해 지원됩니다.
  • 예를 들어, Git, GitHub 및 그들의 IDE와의 통합이 있습니다.

 

Codelines and baselines

 

 

Version control systems(버전 제어 시스템)

• 버전 제어 시스템(VCS)은 구성 요소의 다양한 버전에 대한 식별, 저장 및 접근을 관리합니다. 현대 버전 제어 시스템의 두 가지 유형이 있습니다.
  • 중앙집중식 시스템(Centralized systems)은 단일 주 저장소가 개발 중인 모든 소프트웨어 구성 요소의 버전을 유지합니다.
    • Subversion은 중앙집중식 VCS의 널리 사용되는 예입니다.
• 분산 시스템(Distributed systems)은 여러 버전의 구성 요소 저장소가 동시에 존재합니다.
  • Git은 분산 VCS의 널리 사용되는 예입니다.

 

Public repository and private workspaces(공개 저장소와 개인 작업 공간)

• 개발자가 서로 간섭 없이 독립적으로 개발할 수 있도록 지원하기 위해, VCS는 프로젝트 저장소(project repository)와 개인 작업 공간(private workspace) 개념을 사용합니다.
  • git에서는 종종 "remote"와 "local" 저장소로 나뉩니다.
• 프로젝트 저장소는 모든 구성 요소의 'main' 버전을 유지합니다.
  • 시스템 구축을 위한 베이스라인을 생성하는 데 사용됩니다.
• 개발자가 구성 요소를 수정할 때, 이들은 저장소에서 작업 공간으로 구성 요소를 복사(체크 아웃)하여 이 복사본에서 작업합니다.
  • 변경이 완료되면, 변경된 구성 요소를 저장소로 반환(체크 인)합니다.

 

Repository Check-in/Check-out

Centralized Version Control

 

Distributed version control(분산 버전 제어)

• 'main' 저장소는 개발 팀이 만든 코드를 유지하는 서버에 생성됩니다.
• 필요한 파일을 체크 아웃하는 대신, 개발자는 프로젝트 저장소의 클론을 생성(a developer creates a clone of the project repository)하여 자신의 컴퓨터에 다운로드하고 설치합니다.
• 개발자는 필요한 파일에서 작업하고 자신의 개인 저장소에서 새로운 버전을 유지(maintain the new versions on their private repository)합니다.
• 변경이 완료되면, 그들은 이 변경 사항을 자신의 개인 저장소에 '커밋'(commit)합니다.
• 그런 다음 이러한 변경 사항을 프로젝트 저장소로 '푸시'(push)할 수 있습니다.

 

 

Benefits of distributed version control(분산 버전 제어의 이점)

• 저장소를 위한 백업 메커니즘을 제공합니다.
  • 저장소가 손상되었을 경우, 로컬 복사본에서 프로젝트 저장소를 복원하여 작업을 계속할 수 있습니다.
• 개발자가 네트워크 연결이 없어도 오프라인으로 작업을 할 수 있도록 해줍니다.
  • 충돌 없이 로컬 변경을 수행할 수 있습니다.
• 프로젝트 지원이 기본 작업 방식입니다.
  • 개발자는 전체 시스템을 자신의 로컬 기기에서 컴파일하고 만든 변경 사항을 테스트할 수 있습니다.

 

Open source development(오픈 소스 개발)

• 분산 버전 제어는 오픈 소스 개발에 필수적입니다.
  • 여러 사람이 중앙 집중적인 조정 없이 동시에 같은 시스템에서 작업할 수 있습니다.
• 개인 컴퓨터의 프라이빗 저장소뿐만 아니라,
  • 개발자는 변경된 구성 요소의 새 버전을 푸시하는 공개 서버 저장소도 유지합니다.
• 그러면 오픈 소스 시스템 '매니저'가 이러한 변경 사항을 최종 시스템으로 풀할 시기를 결정합니다.
  • 예) GitHub에서의 풀 리퀘스트.
• '포크'를 사용하여 같은 소프트웨어의 다른 버전을 개발할 수 있습니다.

 

 Branching and merging(브랜칭과 병합)

• 버전이 시간에 따라 변화를 반영하는 선형적인 순서가 아니라, 여러 독립적인 시퀀스가 있을 수 있습니다.
  • 이것은 시스템 개발에서 일반적인 것으로, 다양한 개발자들이 소스 코드의 다양한 버전에서 독립적으로 작업하여 서로 다른 방식으로 변경할 수 있습니다.
• 어떤 단계에서는 모든 변경 사항을 포함하는(includes all changes that have been made) 구성 요소의 새 버전을 만들기 위해 코드라인 브랜치를 병합해야 할 수도 있습니다(it may be necessary to merge codeline branches).
  • 변경 사항이 코드의 다른 부분들을 포함하는 경우, 구성 요소 버전은 코드에 적용되는 델타(차이점 목록)를 결합하여 자동으로 병합될 수 있습니다.

 

Storage management(저장소 관리)

• 버전 제어 시스템이 처음 개발될 때, 저장 관리는 그들의 가장 중요한 기능 중 하나였습니다.
• 디스크 공간이 비쌌고, 다양한 복사본 구성 요소로 사용되는 디스크 공간을 최소화하는 것이 중요했습니다.
• 각 버전의 전체 복사본을 유지하는 대신, 시스템은 한 버전과 다른 버전 사이의 차이점(델타) 목록을 저장합니다.(the system stores a list of differences(deltas)
  • 이것을 주 버전(보통 가장 최신 버전)에 적용함으로써, 타겟 버전을 재생성할 수 있습니다.

 

Storage management in Git(Git의 저장소 관리)

• 디스크 저장소가 이제 상대적으로 저렴해져서, Git은 더 빠른 대안을 사용합니다.
• Git은 델타를 사용하지 않고 저장된 파일과 관련 메타 정보에 표준 압축 알고리즘을 적용합니다.
• 중복 파일 복사본을 저장하지 않습니다.
  • 파일을 검색하는 것은 단순히 압축을 풀고 일련의 작업을 적용하는 것을 포함합니다.
• Git은 또한 여러 개의 작은 파일이 하나의 색인된 단일 파일로 결합되는 팩파일의 개념을 사용합니다.

 

System building(시스템 빌딩)

• 시스템 빌딩(System Building)은 시스템 구성 요소, 외부 라이브러리, 구성 파일 등을 컴파일하고 연결하여 완전한 실행 가능한 시스템을 만드는 과정(process of creating a complete executable system)입니다.
• 시스템 빌딩 도구와 버전 관리 도구는 빌드 과정에 포함되며, 빌드 과정에서 버전 관리 시스템에서 구성 요소 버전을 체크아웃해야 합니다.
• 시스템 빌딩 도구가 사용하는 구성 설명은 기준선(baseline)을 식별하는 데에도 사용됩니다.

 

Build platforms(빌드 플랫폼)

• 개발 시스템(The development system), 여기에는 컴파일러, 소스 코드 편집기 등 개발 도구가 포함됩니다.
  • 개발자는 시스템에 변경을 가하기 전에 버전 관리 시스템에서 개인 작업 공간으로 코드를 체크아웃합니다.
• 빌드 서버(The build server)는 시스템의 결정적인, 실행 가능한 버전을 빌드하는 데 사용됩니다.
  • 개발자는 빌드되기 전에 버전 관리 시스템에 코드를 체크인합니다.
  • 시스템 빌드는 버전 관리 시스템에 포함되지 않은 외부 라이브러리에 의존할 수 있습니다.
• 타겟 환경(The target environment)은 시스템이 실행되는 플랫폼입니다.
  • 실시간 및 내장 시스템의 경우, 타겟 환경은 종종 개발 환경(예: 휴대폰)보다 작고 단순합니다.

 

Development, build, and target platforms

• CI / CD : Continuous Integration / Continous Delivery, Deployment
  • 개발자가 개발을 마친 후 Application을 빌드하고, 원격 저장소에 코드를 업데이트하고, 이를 배포하는 전 과정을 자동화 하는 것

 

Continous Integration(지속적 통합)

Agile Building(애자일 빌딩)

 

 

• 버전 관리 시스템에서 메인라인 시스템을 체크아웃(Check out the mainline system)하여 개발자의 개인 작업 공간에서 시스템을 빌드하십시오.
• 시스템을 빌드하고 자동화된 테스트를 실행(Build the system and automated tests)하여 빌드된 시스템이 모든 테스트를 통과하는지 확인합니다.
  • 만약 그렇지 않다면, 빌드가 깨진 것이고 마지막에 체크인한 사람에게 문제를 고치도록 알려야 합니다.
• 시스템 구성 요소에 변경을 가합니다.(Make the changes)
• 개인 작업 공간에서 시스템을 빌드(Build the system)하고 시스템 테스트를 다시 실행합니다(re-run system tests).
  • 테스트가 실패하면 계속 편집합니다.
  • 이것은 Maven, Gradle과 같은 빌드 시스템에 의해 지원될 수 있습니다.
• 시스템이 테스트를 통과하면, 빌드 시스템에 체크인(check it into build system)하지만 새 시스템 기준선으로 커밋하지 않습니다.

• 빌드 서버에서 시스템을 빌드하고 테스트를 실행합니다.(Build the system on the build server and run the tests)
  • 다른 사람들이 시스템 체크아웃 이후 구성 요소를 수정했을 경우를 대비해야 합니다.
  • 만약 그런 경우라면, 실패한 구성 요소를 체크아웃하여 귀하의 개인 작업 공간에서 테스트가 통과하도록 수정하세요.
• 시스템이 빌드 시스템에서 테스트를 통과하면(the system passes its test), 변경사항을 시스템 메인라인의 새 기준선으로 커밋(commit)합니다.
• 요즘 지속적 통합 및 배포(CI/CD)는 소프트웨어를 더 빠르게 발전시키는 데 있어 점점 더 중요해지고 있습니다.
• CI/CD 활동은 다양한 도구에 의해 지원될 수 있습니다.
  • 예) Jenkins(Java), Docker, GitHub Actions, GitLab 등.

 

Pros and cons of continuous integration(지속적 통합의 장단점)

• 장점
  • 지속적 통합의 장점은 다른 개발자 간의 상호 작용으로 인한 문제를 가능한 빨리 발견(discovered and repaired as soon as possible)하고 수리할 수 있게 한다는 것입니다.
  • 메인라인에서 가장 최신 시스템이 확정적인 작업 시스템입니다(the mainline is the definitive working system).
• 단점
  • 시스템이 매우 크면, 특히 다른 어플리케이션 시스템과의 통합이 관련되어 있을 경우 빌드 및 테스트에 오랜 시간이 걸릴 수 있습니다(it may take a long time to build and test).
    • 모듈화는 이 문제를 피하는 데 중요합니다 - 예) 마이크로 서비스.
  • 개발 플랫폼이 타겟 플랫폼과 다른 경우(the development platform is different from the target platform), 개발자의 개인 작업 공간에서 시스템 테스트를 실행할 수 없을 수 있습니다.
    • 컨테이너 & 클라우드 인스턴스 등을 예로 들 수 있습니다.

 

Release management(릴리스 관리)

• 시스템 릴리스는 고객에게 배포되는 소프트웨어 시스템의 버전입니다.
• 대중 시장 소프트웨어의 경우, 일반적으로 두 가지 유형의 릴리스를 식별할 수 있습니다:
  • 주요 릴리스(major releases)는 중요한 새 기능을 제공합니다.
  • 소규모 릴리스는(minor releases) 버그를 수정하고 보고된 고객 문제를 해결합니다.
• 보통 이는 <major>.<minor>.<patch>와 같은 버전 번호 규칙으로 표시됩니다.
  • 예) 1.4.2 - 두 개의 패치를 포함한 첫 번째 주요 버전입니다.

 

Release components(릴리스 구성 요소)

• 실행 가능한 코드 뿐만 아니라 릴리스에는 다음도 포함될 수 있습니다:
  • 특정 설치에 대해 릴리스가 어떻게 구성되어야 하는지 정의하는 구성 파일(configuration files);
  • 성공적인 시스템 운영에 필요한 오류 메시지 파일 등의 데이터 파일(data files);
  • 타겟 하드웨어에 시스템을 설치하는 데 도움이 되는 설치 프로그램(an installation program);
  • 시스템을 설명하는 전자 및 종이 문서(electronic and paper documentation);
  • 해당 릴리스를 위해 디자인된 포장 및 관련 홍보 자료(packaging and associated publicity).

 

Online Delivery(온라인 배송)

• 최근 소프트웨어 생태계에서의 발전으로 릴리스의 배송이 크게 변화했습니다.
• 이제, 릴리스는 주로 '앱 마켓'을 통해 다운로드 및 업데이트됩니다.
• 자체 채널을 통해 배포되는 스탠드얼론 소프트웨어의 경우, 릴리스의 자동 배송이 상당히 흔합니다.
  • 예) 게임 클라이언트, 앱 스토어, OS 등.
• 개발 프로세스 측면에서, 시스템 빌딩을 지원하는 도구는 릴리스 생성을 훨씬 쉽게 만듭니다.
  • 필요한 자료를 기반으로 '패키지'를 빌드하고 '포장'할 수 있습니다.

 

Software as a service(서비스로서의 소프트웨어 (SaaS))

• 서비스로서의 소프트웨어(SaaS) 제공은 릴리스 관리의 문제를 줄입니다.
• 릴리스 관리와 고객의 시스템 설치를 단순화합니다.
• 소프트웨어 개발자는 기존 릴리스를 새 릴리스로 교체하는 책임이 있으며(software developer is responsible for replacing the existing release of a system with a new release), 이는 모든 고객에게 동시에 제공됩니다.
• 그러나 신뢰할 수 있는 소프트웨어 서비스를 제공하는 것은 또 다른 고려사항입니다.

 

Summary

• 소프트웨어 품질 관리는 요구사항을 충족하는 소프트웨어 시스템을 개발하는 데 중요합니다.
  • 그러나 목적에 맞는 적합성은 규격 준수보다 더 중요합니다 - 검증 및 확인(V & V) : Validation이 더 중요!
• 구성 관리는 변경되는 소프트웨어 시스템을 관리하는 문제입니다.
  • 활동에는 버전 관리, 지속적 통합 및 릴리스 관리가 포함됩니다.
  • 애자일 방법론으로, 변화는 성공적인 구성 관리에 필수적입니다.