Software Engineering – Quality management

Software quality management (QA팀에서 담당)

At the organizational level

• 높은 품질의 software를 도출할 수 있는 조직 차원에서의 절차와 표준의 framework을 설립
• 어떤 소프트웨어라도 일정 기준을 만족시켜야 한다는 회사 차원이 원칙

At the project level

• 계획된 절차를 따르는 지에 대한 specific quality process의 사용 여부와 checking 과정이 수반
• 프로젝트에 관한 Quality plan을 수립하고 달성하기 위한 목표로 설정한다.

Quality management activities

• 개발 과정에 독립적으로 확인 과정을 진행하며 객관적으로 관찰한다.
• 조직의 표준과 목표와 출시될 프로젝트가 상응하는지에 대하여 검토한다.
• QA팀은 개발팀과 독립적으로 존재하여 객관적인 입장에서 검토하며 개발 issue에 검토 과정이 영향을 받지 않는다.
  

Quality planning

• Quality plan은 제품에게서 기대하는 품질을 설정하고, 어떻게 평가되고 정의 될지에 대하여 설정하며, 평가 대상으로 달성되야할 가장 중요한 quality attributes를 설정한다.
• 특정 프로그램에 특화된 quality assessment process를 quality plan에서 수립해야 한다.
• 조직의 표준에 따라 계획되어야 하며, 새로운 표준이 생겼을 때 새롭게 정의해야 한다.

Quality plans

• 반드시 짧고 간결한 문서여야 한다.
• Product introduction → products plans → process descriptions → quality goals → risks and risk management

Scope of quality management

• 크고 복잡한 시스템에서 quality management는 필수적이다
  • Quality 문서는 과정에 대한 기록으로 사용되며 개발 팀이 바뀌어도 개발을 이어 나가게 할 수 있는 기반이 된다
• 작은 시스템에서는 문서가 작게 나오며 품질을 지키고자 하는 quality culture에 대해 집중한다.

Software quality

Quality의 뜻

• 제품이 specification에 만족해야 한다는 의미

소프트웨어 시스템에 대한 issue

• 고객이 원하는 품질(효율성, 신뢰성 등)과 개발자들이 설정한 품질(유지성, 재사용 가능성 등)의 사이에서 tension이 있으며, 고객들은 추상화된 단어나 불명확한 단어로 요구 사항을 기술하기 때문에 품질을 규정하는 것에 문제가 있을 수 있다.
• Software specification은 불완전하고 일관적이지 않은 경우가 많다.
  • Specification에 대한 정확한 부합보다는 fitness for purpose에 집중해야 한다

Software fitness for purpose

• Has the software been properly tested?
• Is the software sufficiently dependable to be put into use?
• Is the performance of the software acceptable for normal use?
• Is the software usable?
• Is the software well-structured and understandable?
• Have programming and documentation standards been followed in the development process?
  • 결과가 아닌 문서 작성 등 절차와 과정에 집착하는 폐단을 낳을 수 있다
  • 정량적인 것은 평가할 수 있지만 정성적인 부분에서는 평가하기 어렵다.

Non-functional characteristics

• 정성적인 부분을 평가하기 위해서 최대한 정량적으로 표현하여 객관화 하거나 충분히 검토해서 항목을 도출하여 평가를 진행해야 한다.
• Non-functional 특징을 만족하지 못한다면 제품을 쓰이지 않게 된다.
  

Quality conflicts

• 신뢰성을 키우면 성능이 낮아지는 등 모든 attributes에 대하여 최적화하기는 불가능하다.
  • 따라서 가장 중요하게 달성해야 하는 목표를 설정하고 달성하여야 한다.

Process and product quality

• 품질을 유지하기 위해서는 프로세스를 준수해야 한다.
• 목표 제품의 품질 특성을 최대한 도출하고 평가하도록 노력해야 한다.
• 프로세스와 제품의 품질 간에 충돌이 발생할 수 있다.
  • 개발 스케줄(프로세스)을 가속시킬수록 품질 평가 시간이 줄어들거나 품질이 저하된다.

Process-based quality (process evolving)

프로세스는 절대적인 것이 아닌 제품 개발 당시의 상황과 노하우가 담긴 것이다.
- 시장 상황, 새로운 기술 등에 따라 process도 개선할 수 있어야 한다.

Quality culture

• 모든 사람들이 높은 품질을 달성하기 위한 분위기, 문화가 형성되어야 하며 팀이 높은 품질을 달성하기 위해 책임감을 가져야 하며 품질 향상을 위하여 기여하고, 새로운 접근 방식도 가질 수 있어야 한다.

Software standards

• 표준이 제품 또는 프로세스에 대한 필요한 attributes를 규정한다.
• 표준은 국내, 국가 간, 조직 별, 프로젝트별로 표준을 가질 수 있다.(고객과 개발팀의 관계)

Importance of standards

• 이전의 사람들이 겪은 경험을 encapsulation하여 과거의 실수를 반복하는 것을 피한다.
• 특정 환경에서 quality가 무엇을 의미하는 지에 대한 틀/framework를 의미한다.
• 새로운 팀원이 참여하여도 표준을 이해하고 사용함으로써 연속성/지속 가능성을 제공한다.

Product standards and process standards

Product standards (양식을 정의한다)

• Quality management가 수행되었다는 것을 증명할 수 있는 문서가 나온다.
• 요구 사항 문서의 체계, 문서 표준의 체계와 같은 document standards를 포함한다.
• 개발 부분에서는 header나 object class의 정의 등에 대한 표준이 존재하며 프로그래밍 언어가 사용되야 하는 방식에 대한 coding standards가 존재한다.

Process standards

• 개발 과정 중에 따라야 하는 절차에 대한 정의를 포함한다.
• Specification에 대한 정의, design & validation 프로세스에 대한 정의와 프로세스 보조 도구, 프로세스 진행 도중 제작되야 할 문서에 대한 설명을 포함한다.
  

Problems with standards

• 개발자의 시선에서 너무 구시대적이거나 관계가 없어 보일 수 있다.
• 관료적인 형식을 채우기 위해 너무 많은 시간을 할애해야 할 수 있다.
• Software tools에 대해 지원되지 않는 상황이라면 관련 문서를 채우기 위해 쓸데없는 시간을 낭비하게 될 수 있다.

Standards development

• 개발에 참여하는 누구나 표준에 대하여 이해하고 있어야 한다.
• 표준은 주기적으로 검토되야 하며, 쉽게 구식으로 변할 수 있기 때문에 신뢰성을 보장하기 위하여 빠르게 수정될 수 있어야 한다.
• 표준의 정의 및 수정 등은 자동화된 도구를 사용하여야 한다.
  ISO 9001 standards framework
• 소프트웨어 품질 관리에 대한 국제적인 표준이다
• Quality management 시스템을 구현하는 기반으로 사용될 수 있다.
• 구체적인 성능과 기능에 대한 표준이 아닌 소프트웨어에 대한 품질 관리 프로세스/frame work의 여부를 검토한다.
  • 구체적인 성능과 기능에 대한 평가가 아닌 품질 관리 프로세스의 여부를 따지기 때문에 문서와 manual이 필요하며 소프트웨어 특성이 고려되지 않은 일반화된 프로세스와 표준에 대해 다룬다.
  • 소프트웨어의 고유한 특징과는 관계가 없다. 개발자 스스로 특화된 성능을 관리해야 한다.

ISO 9001 core process

ISO 9001 and quality management

ISO 9001 certification

• 품질 표준과 과정은 조직 품질 manual에 문서화되어야 한다.
• External body가 ISO 9000의 표준을 따른다면 인증을 받을 수 있으며 고객들은 이를 통해 신뢰성을 받을 수 있다.

Software quality and ISO9001

• ISO 9001의 절차를 따르면 인증을 받을 수 있지만, 고객의 요구사항과 상이할 수 있다.
• ISO 9001 표준은 소프트웨어 검증에 있어 불충분한 표준으로 작용할 수 있으며 여러 가지 상황의 매개 변수에 대한 테스트를 포함하지 않으므로 요구 사항과 다를 수 있다.
• 회사 자체적으로 가이드와 표준을 갖추는 것이 합리적이다.

Reviews and inspections

• 모든 프로세스, 시스템, 문서들을 검토하여 잠재적인 문제를 찾는 과정
• Review를 통과하면 다음 단계로 진행하는 singed off/승인을 부여한다.
• Code 위주로 검토하는 code review와 달리 quality review는 code, 명세서, test plans, standards 등에 대해서review한다.
  • 제품에 결함이 제거되었는지 inspection한다.
  • 진행 과정(제품과 프로세스)에 대해서 review한다
  • 품질(제품과 표준)에 대해서 review한다

Phases in the review process

Pre-review activities

• 계획과 준비 단계를 거친다

The review meeting

• Review meeting 중에는 전문적인 review team과 함께 문서와 프로그램에 대하여 천천히 review한다

Post-review activities

• Review meeting에서 발견된 문제와 issue에 대해서 전달 및 개선한다.
  

Distributed reviews

• 전담 review팀이 담당하거나 하지 않더라도 face-to-face meeting이 권장된다.
• Face-to-face가 불가능한 remote review 상황이라면 문서에 대하여 주석을 달 수 있는 공유 문서를 사용하여야 한다.

Program inspections

• 시스템의 결함을 발견하기 위하여 peer review를 진행하거나 pair-programming을 통하여 한 사람은 개발을, 한 사람은 검토를 번갈아 가며 진행하여 inspection을 진행한다.
• 시스템을 실행하기 전에 진행되며 따라서 구현 전에 사용된다.
• 구현 전에 눈으로 보면서 검토를 하기 때문에 효율적인 방법이다.

Inspection checklists

• Common errors에 대하여 check list를 만들며 inspection의 동력으로 작용할 수 있다.
• 프로그래밍 언어에 관련한 에러이거나 표준을 어기거나 가이드 라인을 어기는 등에 대한 check list를 만들어 type checking을 함으로써 효율적으로 작업할 수 있다.
  
  

Python의 제공 기능

Lint(린트)

• Visual studio code에서 오류에 밑줄을 긋는 것과 같이 소스 코드를 분석하여 프로그램 오류, 버그, 스타일 오류, 의심스러운 구조체에 표시를 달아놓기 위한 도구를 지칭한다.

Intellisense

• 미리 짜여진 코드를 자동으로 완성해주고 문법 오류를 확인함으로써 오류를 줄일 수 있다.

Code formatting

• Code의 형식을 잡아줌으로써 효율을 올릴 수 있다.

Debugging & testing

• 디버깅과 테스트를 통하여 코드의 신뢰성을 향상시킬 수 있다.

Refactoring

• 코드를 재조직해줌으로써 가이드 코드와의 형식에 맞출 수 있도록 해준다.

Quality management and agile development

• agile에서 품질 관리 단계는 비형식적인 단계이다.
• 팀원 모두가 품질 향상에 대해 노력하고 책임감을 가지는 quality culture에 기반한다.
• ISO 9001에 포함된 형식적인 절차에 대하여 거부감을 느낀다.

Shared good practice

Check before check-in

• 코드가 빌드 시스템에서 검토되기 전에 개발자들은 스스로의 코드를 코드 리뷰하여야 한다.

Never break the build

• 코드가 합쳐지기 전에 코드 리뷰를 하지 않아 빌드 과정에서 오류를 야기하지 않아야 한다.
• 반드시 빌드 전에 코드 리뷰를 통하여 예상되는 방식으로 동작할 수 있도록 하여야 한다.

Fix problems when you see them

• 본인이 짠 코드가 아니더라도 문제를 발견하였으면 즉시 수정하라.

In scrum

• 한 번의 sprint가 끝난 후 review 미팅을 통하여 품질 문제와 이슈들이 논의된다.

In Extreme programming

• Pair programming을 통하여 다른 팀원들에 의해 검사되고 검토된다.

Pair programming

• 한 사람은 코드를 작성하고 한 사람은 코드를 검토하는 과정을 번갈아 가며 진행하면서 구현과 검토를 동시에 하며 굉장히 효율적이다.
• Pair programming을 통하여 두 사람 모두 프로그램에 대해 세세하게 이해하고 있으므로 지속적인 개발이 가능하다.
• 이 과정을 통하여 얻을 수 있는 지식의 깊이는 inspection process를 통하여 얻을 수 없으며, 따라서 formal inspection에서 발견할 수 없는 버그도 발견할 수 있다.

Pair programming weaknesses

Mutual misunderstandings

• 2명 모두 같은 실수를 범할 수 있으며 이것은 오류를 강화시킨다.

Pair reputation (윤리적 문제)

• 진행 상황을 늦추기 싫어 의도적으로 에러를 묵인할 수 있다.

Working relations

• 가까운 동료 사이에 비판을 하기 힘들 수 있다.

Agile QM and large systems

• 외부 고객을 위해서 불필요할지라도 최소한의 문서 작성이 필요하다.
• 고객이 대기업이라면 그들만의 QM process가 있을 것이고 그것과 양립할 수 있는지에 대하여 검토할 것이다.
• 물리적으로 떨어져 있는 개발팀이나 서로 다른 회사 사이들에서는 정형화되어 있지 않은 커뮤니케이션은 오히려 비효율적이다.
• 지속적인 개발을 위하여, 새로운 팀을 위하여 문서가 필요하다.

Software measurement

• 정량적인 value를 전달해야 하며, 정성적인 부분도 정량적으로 수치화하여 전달하여야 한다.
  • 객관적인 검증을 가능하게 한다.
• 대표적인 표준이 매우 적기 때문에 스스로의 기준을 세워야 한다.

Software metric

• 소프트웨어나 소프트웨어 프로세스에 대해서 정량화할 수 있다.
• 제품의 특성을 예측하거나 프로세스를 제어하는 것에 사용된다.

Types of process metric

• 특정 작업에 소요되는 시간에 대해서 정량화하여 측정할 수 있다.
• 인력, 경비, 하드웨어 등과 같은 자원에 대해서도 정량화하여 측정할 수 있다.
• 제품에서 발생할 수 있는 이벤트도 정량화하여 측정할 수 있다.
  
  

Use of measurements

• System quality attributes에 value를 할당함으로써 정성적인 것을 정량적으로 변환할 수 있다.
• cyclomatic 복잡도 등을 수치를 할당함으로써 시스템의 품질/유지 가능성을 평가할 수 있다.
• 정량적인 값으로 수치화함으로써 시스템 요소들을 식별할 수 있다.
  • 복잡도가 높은 것은 이해하기 힘들게 만들며 오류 발생률을 높이기 때문에 이를 식별하게 한다.
  • 수치화할 수 없던 정성적인 요소들을 정량적인 값들로 매핑함으로써 평가할 수 있게 한다.

Metrics assumptions

• 우리가 측정할 수 있는 부분과 알고자 하는 부분에 대해서 관계가 존재한다.
• 우리는 내부적인 특징을 측정할 수 있지만 이를 통하여 외부적인 특징을 알 수 있다.
• 이들의 관계는 정형화되어 있으며, 검증되어 있다.
  

Problems with measurement in industry

• Software metrics에 대한 표준이 없다.
• 많은 회사들에서 소프트웨어 프로세스는 표준화되어 있지 않거나 빈약하게 정의되고 제어된다.
• 측정을 하는 것은 프로세스에 추가적인 오버헤드를 발생시킨다.
• 대부분의 소프트웨어 측정은 code-based metric와 plan-driven 프로세스에서 이루어지지만 점점 더 많은 소프트웨어가 COTS나 ERP에 의해 정의된다.

Empirical software engineering

• 개발자의 경험, 노하우 등이 측정과 metrics에 투영된다.
• 소프트웨어 공학의 방법과 기술에 대한 가설은 생성하고 검증하는 연구 분야로 활용된다.

Products metrics

• 제품의 품질에 대한 예측 척도로 사용되야 한다.
• 동적인 방법 : 프로그램이 실행되는 중에 평가 척도를 추출
  • 실행 시 나오는 숫자들을 확인한다
  • 응답 시간, 실패 횟수 등 비교적 쉽게 측정된다.
  • 효율성(더 적은 메모리, 통신 속도 등)과 신뢰성을 평가하는 데 사용된다.
• 정적인 방법 : 실행 전 코드를 읽는 등의 방법을 통하여 추출
  - 복잡도, 이해 가능성, 유지 가능성 등을 평가한다.
  - 논리적인 분석, 복잡도 등 간접적인 관계를 측정한다.
  

Fan -in/fan-out

• 함수별로 입력 매개변수와 출력 매개 변수가 얼마인지 측정하는 방법

코드 길이

• 특정 함수에 대해 특정 길이를 임계값으로 정할 수 있으며 코드가 길수록 복잡도가 높고 좋지 않다고 판단한다.

Software component analysis

• 평가 척도로 사용할 metrics의 효율성을 파악하기 위해 이전에 정의된 데이터를 통하여 평가할 수 있다.

Measurement ambiguity

• 측정 척도에 대해 이해도가 높아야 하며 잘 선택해야 한다.
• 측정 척도를 잘못 선택하면 데이터를 잘못 해석하거나 틀린 추론을 도출할 수 있다
  Ex ) 변화 요구를 측정 척도로 삼을 경우 요구가 많아지는 것에 대한 해석
• 소프트웨어를 잘못 만들어서 고객들의 변화 요구가 늘어난다.
• 소프트웨어를 잘 만들어서 사용하는 고객이 늘어난다.

Software analysis

• 소프트웨어를 운영하면서 쌓이는 데이터를 많이 모아 정보를 찾자 라는 의미
• 고객이 실시간으로 겪는 문제점, 에러 등에 대한 정보를 실시간으로 수집하자
• 오픈 소스 소프트웨어도 분석하여 정보를 공유하자

Analytics tool use

• 사용하기 쉬워야 하며, 간결한 출력을 가져야 하며, 다양한 정보를 제공해야 하며 사용자와 상호작용하며 정보를 수집하고 분석할 수 있어야 한다