Computerized System 공급사의 품질관리

Computerized System 개발 공급사의 품질관리

 

Computerized System 개발 및 최종제품을 관리하기 위한

품질시스템 요구사항

 

 

관리 항목

 

- 프로그래밍 언어

- 코딩 표준

- 버전 관리

- 명명 규칙 (Naming Conventions)

- 코드 리뷰

- 문서화된 빌드 과정 (Documented build processes)

- 하드웨어(H/W) 변경 관리

- 상업제품 출시 관리 및 출시 기준

- 패치 관리

- 보안 관리

- 백업 관리

- 기타.

---

명명 규칙 (Naming Conventions)??

 

소프트웨어(S/W) 개발에서 'naming conventions'는 코드 내에서 변수, 함수, 클래스, 모듈 등의 식별자 이름을 지정할 때 따르는 일련의 규칙이나 가이드라인을 의미합니다. 이러한 명명 규칙은 코드의 가독성을 높이고, 유지 보수를 용이하게 하며, 개발자 간의 협업을 효율적으로 만드는 데 중요한 역할을 합니다.

 

Naming Conventions의 중요한 요소들:

 

명확성(Clarity):

식별자의 이름은 그것이 무엇을 하는지, 어떤 역할을 하는지 명확하게 표현해야 합니다. 예를 들어, 변수가 사용자의 나이를 저장한다면 age나 userAge와 같이 의미가 명확한 이름을 사용하는 것이 좋습니다.

 

일관성(Consistency):

전체 코드 베이스에서 일관된 명명 규칙을 사용함으로써, 코드를 읽고 이해하는 데 필요한 노력을 줄일 수 있습니다. 예를 들어, 클래스 이름에는 항상 대문자로 시작하는 CamelCase를 사용하고, 변수와 함수 이름에는 소문자로 시작하는 camelCase나 snake_case를 사용하는 등의 규칙을 정할 수 있습니다.

 

언어 및 프레임워크의 관례:

대부분의 프로그래밍 언어와 프레임워크는 자체적인 명명 규칙을 가지고 있습니다. 예를 들어, Python에서는 변수와 함수 이름에 snake_case를, 클래스 이름에는 CamelCase를 사용하는 것을 권장합니다. Java에서는 변수와 메소드 이름에 camelCase를, 클래스 이름에는 CamelCase를 사용합니다.

 

약어 사용의 제한:

약어를 사용할 때는 주의가 필요합니다. 널리 알려진 약어는 괜찮지만, 특정 프로젝트나 팀 내에서만 사용되는 약어는 피하는 것이 좋습니다. 코드를 외부인이 읽거나 유지 보수할 경우, 약어의 의미를 이해하지 못할 수 있기 때문입니다.

 

길이의 적절성:

너무 짧은 이름은 정보를 충분히 제공하지 못할 수 있고, 너무 긴 이름은 가독성을 저하시킬 수 있습니다. 적절한 길이의 이름을 선택하는 것이 중요합니다.

 

 

명명 규칙의 예:

 

CamelCase:

각 단어의 첫 글자를 대문자로 하여 모든 단어를 이어붙임 (예: UserProfile)

 

snake_case:

단어를 소문자로 작성하고, 단어 사이에 언더스코어(_)를 사용 (예: user_profile)

 

PascalCase:

CamelCase와 유사하지만, 첫 단어의 첫 글자도 대문자로 시작 (주로 클래스 이름에 사용됨, 예: UserProfile)

 

kebab-case:

단어를 소문자로 작성하고, 단어 사이에 하이픈(-)을 사용 (HTML과 CSS에서 주로 사용, 예: user-profile) 명명 규칙은 개발자 또는 팀이 결정할 수 있으며, 프로젝트나 조직의 특정 요구에 맞게 조정될 수 있습니다.

 

가장 중요한 것은 일단 결정되면 일관성 있게 적용하는 것입니다.

---

문서화된 빌드 과정 (Documented build processes)??

 

소프트웨어(S/W) 개발에서 'documented build processes'는 소프트웨어 빌드 및 배포 과정을 체계적으로 기록한 문서를 말합니다. 이 문서화 과정은 개발, 테스트, 배포 단계에서 필요한 모든 단계, 도구, 환경 설정, 의존성 관리 및 특정 명령어 실행 방법 등을 포함할 수 있습니다. 목적은 소프트웨어의 빌드 및 배포 과정을 표준화하고, 이를 통해 프로젝트의 투명성, 재현성, 유지보수 용이성을 높이는 것입니다.

 

Documented Build Processes의 주요 구성 요소:

 

빌드 환경 설정:

사용되는 개발 환경, 필요한 도구 및 라이브러리, 버전 관리 시스템 등의 설정 방법을 설명합니다. 이는 모든 개발자가 동일한 조건에서 작업할 수 있도록 보장합니다.

 

의존성 관리:

프로젝트에서 사용하는 외부 라이브러리나 모듈의 목록, 이들을 설치하고 관리하는 방법을 포함합니다. 예를 들어, Java 프로젝트의 경우 Maven이나 Gradle 설정 파일을 통해 의존성을 관리할 수 있습니다.

 

빌드 명령어:

소스 코드를 컴파일하고, 실행 가능한 파일이나 패키지를 생성하는 데 필요한 명령어 또는 스크립트의 정확한 순서와 방법을 기술합니다. 이는 빌드 과정을 자동화하는 데 필수적인 정보입니다.

 

환경 변수:

빌드 과정에서 필요한 환경 변수 설정을 명시합니다. 이는 빌드 과정이나 실행 시 필요한 구성 정보를 외부에서 설정할 수 있게 해줍니다.

 

테스트 및 검증:

코드를 빌드한 후 실행해야 하는 테스트 케이스, 테스트 자동화 스크립트, 품질 검증 절차 등을 설명합니다. 이는 빌드의 안정성과 품질을 보장하는 데 중요합니다.

 

배포 지침:

빌드된 소프트웨어를 실제 운영 환경에 배포하는 방법, 필요한 사전 조건, 백업 및 롤백 절차 등을 상세하게 기록합니다.

 

버전 관리:

빌드 프로세스 문서 자체의 버전을 관리하는 방법을 명시하여, 프로세스의 변경 사항을 추적할 수 있게 합니다.

 

Documented Build Processes의 이점:

 

재현성:

누구나 문서를 따라 동일한 방법으로 소프트웨어를 빌드하고 배포할 수 있습니다.

 

효율성:

빌드 및 배포 과정의 자동화를 용이하게 하여, 수동 작업의 오류를 줄이고 속도를 향상시킵니다.

 

지식 공유:

새로운 팀원이 프로젝트에 쉽게 참여할 수 있도록 하며, 팀 내 지식의 중앙화를 돕습니다.

 

유지보수 용이:

문서화된 프로세스를 기반으로 시스템의 변경이나 업그레이드를 보다 쉽게 관리할 수 있습니다.

 

이러한 문서화된 빌드 프로세스는 소프트웨어 개발의 품질과 효율성을 높이는 데 중요한 역할을 합니다.