[서평] 소프트웨어 품질관리 실무 가이드 책읽기

안녕하세요. 잡다무니입니다.

 

"소프트웨어 품질관리 실무 가이드"책을 읽었습니다.

저자는 정보통신산업진흥원, 비즈피어(주) 컨소시엄 지음입니다.

 

IT업무를 하시는 분이라면 프로젝트 사이즈가 크든 작든 상관없이 한 번은 꼭 할 것입니다.

프로젝트 관리를 어떻게 해야 할지 모르는 경우 참고해보면 좋을 것 같습니다.

프로젝트 관리자와 엔지니어가 더욱더 좋은 품질의 소프트웨어를 개발할 수 있도록 가이드하고 있습니다.

책표지 찰칵!!

프로젝트 계획 수립, 요구 사항 분석, 설계, 구현, 테스트에 이르기까지 소프트웨어 생명주기에 걸쳐 이론과 사례를 제공하고 있습니다.

큰 목차만 간략히 적었습니다.

Part 1 프로젝트 관리
: 소프트웨어 품질에 대한 정확한 이해, 프로젝트 계획 수립, 프로젝트 모니터링, 품질관리 및 형상관리
Part 2 요구사항 분석
: 요구사항 도출, 요구사항 분석과 명세, 요구사항 검증, 요구사항 관리
Part 3 설계
: SW 아키텍처 설계, 아키텍처 설계 검증과 평가, 상세설계 및 검토
Part 4 구현
: 단위 테스트 수행, 코드 품질: 코딩 표준 수립, 코드 품질: 문법, 그 이상, 코드 검증
Part 5 테스트
: 테스트 계획서 작성, 테스트 케이스 설계, 결함관리, 테스트 실행 및 관리

(p9~16)

'품질'을 물건, 제품 품질만을 생각하는 경우가 많지만, 소프트웨어도 하나의 제품이기 때문에 품질을 고려해야 합니다.

소프트웨어에는 두 가지 품질이 있다. 바로 작은 품질(Little Quality)과 큰 품질(Big Quality)이다. 작은 품질은 결함이 없는 소프트웨어를 의미한다. 이는 개발자가 주로 생각하는 품질의 개념으로 소프트웨어가 요구사항 명세를 만족하느냐 못하느냐의 여부로 품질 충족 여부를 판별한다. 반면에 큰 품질은 고객의 관점으로 고객 만족 여부가 품질의 기준이 된다. 즉, 고객이 원하는 것을 정확하게, 탁월하게 구현하여 고객 만족을 제공하는 것이다. (p23)

소프트웨어 생명주기 전반에 걸친 내용과 예시가, 업무에 바로 적용이 가능하여 도움이 될 것 같습니다.

 

개인적으로는 책 후반에 '구현', '테스트' 부분이 좋았습니다.

프로젝트라는 것과 상관없이 개발자, 엔지니어라면 참고해볼 내용입니다.

대표적으로는 '코드 품질: 코딩 표준 수립' 부분입니다.

코드 분석 시간을 줄이는 방법이 무엇일까 고민한다면, '코딩 표준'을 생각할 수 있습니다.

코드의 가독성과 이해도가 높아져 코드 검토 시간을 줄일 수 있고 향후 효율적인 협업이 가능해집니다.

(작지 않은 수의 회사들이 코딩 표준이 없거나 있어도 교육을 제대로 하지 않는 상황입니다.)

 

간략히 책에 있는 주요 코딩 표준을 인용하였습니다.

책에는 JAVA코딩 표준과 C코딩 표준이 추가, 별도로 있습니다. 참고하면 좋을 것 같습니다.

1. 명칭에 관한 규칙
[규칙] 명칭의 길이는 31자 이내로 한다.
[규칙] 동이란 변수 이름과 메소드(함수) 이름을 사용하지 않는다.
[규칙] 명칭은 "_"이외의 특수문자를 사용하지 않는다.

2. 소스 형식에 관한 규칙
[규칙] 하나의 소스 파일은 2000줄 이내로 작성한다.
[규칙] 한 줄의 길이는 80자 이내의 문자로 한다.
[규칙] 메소드나 함수의 내용은 70줄 이내로 작성한다.
[규칙] 괄호는 시작 문장의 마지막 열에 삽입, 닫는 중괄호는 새로운 시작 열에 삽입한다.
[규칙] 하나의 문장이 여러 줄로 작성될 경우 아래와 같은 규칙에 의해 행을 나눈다.
  - 80자 초과 시, 쉼표 다음 문자부터 새로운 행을 시작한다.
  - 이전 행과 동일한 수준의 표현식과 열을 맞춘다.
[규칙] 동일 수준의 문장은 같은 위치에서 시작하고 끝난다.

3. 주석에 관한 규칙
[규칙] 프로그램은 최초작성자, 최초작성일, 최종변경일, 목적, 개정 이력 및 저작권을 기술하는 주석으로 시작해야 한다.
[규칙] 메소드나 함수 주석은 목적, 매개변수, 반환값 및 변경 이력을 기술하는 주석으로 시작한다.

4. 변수 선언에 관한 규칙
[규칙] 같은 용도의 변수는 같은 선언에 둔다.
[규칙] 불필요한 변수를 선언하지 않는다.
[규칙] 배열을 선언하는 경우 반드시 요소 수를 명시적으로 선언하거나 초기화에 의해 묵시적으로 결정되도록 한다.
[규칙] 지역 변수는 선언과 동시에 초기화한다.

5. 상수에 관한 규칙
[규칙] 8진수로 표현된 상수를 사용하지 않는다.
[규칙] 숫자 리터럴을 직접적으로 소스 코드 안에 삽입하지 않는다.

6. 수식에 관한 규칙
[규칙] 단항 연산자는 피연산자와 붙여 쓴다.
[규칙] 조건부 연산자에서 "?" 연산자 앞에 이항 연산식이 나타날 경우 괄호로 구분한다.
[규칙] 증감 연산자는 수식에서 다른 연산자와 결합하여 사용하지 않는다.
[규칙] .(dot), ->(포인터) 연산자를 제외한 모든 이항 연산자 전후는 공백으로 구분한다.
[규칙] 3개 이상의 연산자를 사용하는 경우 괄호로 연산의 우선순위를 표현한다.
[규칙] 비트 연산자는 부호 있는 자료에 사용하지 않는다.

7. 문장에 관한 규칙
[규칙] switch~case 문장에서 case 문에 break 문이 없는 경우 주석을 작성한다.
[규칙] switch~case 문에서는 반드시 default 문을 작성하고 마지막 항목에 위치한다.
[규칙] goto 문을 사용하지 않는다.
[규칙] for 문을 제어하는 수식에 실수 값을 사용하지 않는다.
[규칙] for 문을 제어하는 수치 변수는 루프 내에서 변화되지 않아야 한다.
[규칙] 반복문 내부에서 반복 중단을 위한 break 문은 가능한 한 번만 사용하도록 한다.
[규칙] if~else if 문은 반드시 else 문으로 끝나도록 한다.

(P326~331)

주요 코딩 표준 부분의 타이틀만 인용하여 작성하였습니다.

책에는 각각의 규칙에 대한 상세한 내용이 있습니다.

책을 참고해주시기 바랍니다. (문제 시 삭제하겠습니다.) 

 

성공적인 프로젝트를 하고 싶은 분과 개발자, 엔지니어 분들에게 적극 추천하고 싶은 책입니다.

갑자기 프로젝트 관리자가 되어 개발자 여러 명과 함께 프로젝트를 하게 되면 막막할 것 같습니다.

 (멘붕으로 퇴사라는 단어가 머리 위로 떠오를 듯...)

 

심지어 프로젝트 관리를 제대로 못해 품질 논란과 책임 논란이 생기는 경우도 보았습니다.

 (100% 야근 각...)

미리 책 내용을 습득하여 실무적으로 대처하면 좋을 것 같습니다.

WBS, 요구사항 명세서, 품질활동 등 용어 조차 모르는 분들이라면 더욱더 추천~

 

 

짧은 글이지만 읽어주셔서 감사합니다.

 

 

책 추천 : ★★★★★

 

출처 : 정보통신산업진흥원, 비즈피어(주) 컨소시엄 지음, 『소프트웨어 품질관리 실무 가이드』, 2019.04.22, 프리렉