2022. 6. 14. 23:36ㆍ강의 내용 정리/소프트웨어 공학
Quality Management
정성적/정량적으로 소프트웨어가 도달해야하는 수준에 대한 품질 관리
- 대부분의 소프트웨어가 기능적으로 만족되었다하더라도 QA팀에서 품질이 보장된다고 도장을 찍어야지 이를 배포할 수 있다.
0. 개요
1) Software quality management
- 평가 지표가 있고, 이를 달성했는지 확인한다.
- 소프트웨어마다 평가 항목과 레벨이 정해진다. 일반적으로 고려해야하는 소프트웨어의 퀄리티 등을 수시로 체크하고 관리한다.
2) Three principal concerns
(1) At the organizational
- 어떤 소프트웨어가 되던, 우리 회사가 만드는 소프트웨어는 어떤 체계와 방침을 가지고 소프트웨어를 유지하는지 명시한다.
- 체계화된 경우에는 이에 대한 품질 규약 등이 있다.
- 이를 전담하는 팀이 주로 있을 것이다.
(2) At the project level
- 새로운 프로젝트가 시작되면 결국 새로 시작하는 프로젝트들이 프로세스와 기준에 따라 이를 시작한다.
- 위에서 정의한 절차와 규약을 잘 지키는지 확인해야한다.
(3) At the project level
- 우리 프로젝트에 특성화되어있는 품질을 달성하는 것이 이뤄져야한다.
3) Quality management activites
- 객관성을 유지하기 위해 plan based나 대기업의 경우 퀄리티를 관리하는 과정이 개발 절차에 독립적으로 존재한다.
- 개발 팀이 스스로 개발하며 시각이 편향되는 것을 막기위해 객관적으로 바라보고 평가하기 위해서 이를 따로 둔다.
- 개발팀과 독립적으로 존재하는 프로세스와 규약이 있고 이를 따르는지 고려해 정성/정량적인 목표를 달성하는지를 체크한다. Agile은 소프트웨어 개발팀이 퀄리티까지 만족시키거나 독립적으로 놔둘 수도 있다.
Quality management and software development
- 프로젝트가 시작하기 전에 자체적인 기준이나 절차가 있어야하고, 프로젝트가 시작되면 이를 어떻게 설정할 것인지 플랜을 잡는다. 개발 팀은 매번 development마다 이를 평가한다.
4) Quality planning
(1) Quality planning
- 우리가 만들고자하는 결과물에 대한 퀄리티를 정의하고, 퀄리티를 제대로된 절차에 의해 달성하고 있는지 확인한다. 이후 프로젝트마다 고유의 달성해야하는 항목이 있으니 이를 측정하고 관리해야한다.
- 퀄리티 플랜은 회사에서 정의한 프로세스, 기준을 기반으로 특정 프로세스에 특화된 퀄리티를 측정하고 관리하는 과정이 된다.
- 전사차원에서의 프로세스와 기준이 있어야하고, 기준이 없어거나 새로운 개발 방식을 도입하면 새로운 기준이 있어야한다.
(2) Quality plans
- 개발팀 외에 많은 사람들이 함께하는데, 퀄리티 플랜에 관한 문서를 만들 때는 핵심 키워드를 중심으로 짧게 작성하는 것이 중요하다.
(3) Scope of quality management
- 많은 부서들이 들어갈 경우 plan based approach가 큰 틀에서 정해져야한다. 이에 따라 문서화되고 체계화괴뎜 거시적인 것들이 정해져야한다.
- Smaller system에서는 문서화도 작게 해야하고, 직접 개발하는 소프트웨어에 대한 퀄리티를 지키고자하는 문화가 있어야한다.
1. Software quality
1) Software quality
(1) Software quality란?
- 소프트웨어가 지켜야하는 것에 대한 프로세스와 기준을 정의한다. 이후 이것이 지켜졌는지 확인해야한다.
- 정성/정량적인 것을 규정화하고 이를 지키는지 확인하는 것이 쉽지 않다. 정량화할 수 있는 부분은 정량화해야하지만 쉽지 않은 부분도 있다. 고객과 개발자 모두 추상적인 단어를 많이 사용한다. 이를 정량화하는 것이 중요한 부분이고, 누구나 읽었을 때 동일하게 받아들일 수 있도록하는 것이 중요하다. incomplete하고 inconsistent한 부분은 존재할수밖에 없다. 퀄리티를 체크하는 것을 목표지향적으로 여기는 것이 중요하고 이를 지키고자 노력하는 것이 중요하다. 반드시 달성해야하는 것이 아닌 경우에는 서로 합의한 수준에 도달한다면 퀄리티를 지켰다고도 할 수 있다.
(2) Software fitness for purpose
- 적절하게 테스트 되었는지, 이해할만한가 등등
- 회사차원에서 understandable한 것을 정의한다. 경험에 따라 이를 합의하고 정의한다.
- 추상적인 정의들이기에 프로세스를 정의하고 이를 준수하는 가에 더 집착하게 된다. 회사가 정의한 것이 있고 이를 위해 해야하는 일이 있고 이에 대한 문서가 있으니, 추상적인 것을 확인하기 위해 이를 따진다. 하지만 결과적으로 본질이 무엇인지 파악하고 결과에만 집중하는 것이 아니라 합의할만한 퀄리티 수준을 만드는 것이 중요하다.
(3) Non-functional characteristics
- 추상적인 부분이 많이 발생한다. 이를 객관화하고 규정화하는 것이 중요하다. 본질적으로 소프트웨어 퀄리티를 지키고자 하는 것이 중요하다. 느리거나 믿을 수 없다면 사용하지 않기에 이를 위해 노력해야한다.정성적인 부분도 충분히 검토해서 항목을 도출하고 이를 만족시킬 수 있어야한다.
(4) Software quality attributes
- 추상적인 내용이지만 도달해야할 퀄리티들이다. 우리 프로젝트 내에서 구체적인 항목으로 뽑아내고 이를 도달하려는 노력을 중간중간 점검하면서 해야한다.
(5) Quality conflicts
- 신뢰성이 극대화되어야하는 소프트웨어가 성능까지 좋기는 어렵다. ex) 암호화를 한다면 이를 위한 자원을 소모하기에 구현하고자하는 성능의 훼손은 존재한다.
- 전사적 차원에서 퀄리티 속성을 지키기 위해서 노력하라고 하지만 우리 프로젝트 내에서 따로 이를 고려해 중요한 퀄리티 속성을 고려해서 이를 사용해야한다.
2) Process and product quality
- 퀄리티를 지키기 위해 프로세스를 준수하고, 프로젝트에 특성화되어있는 퀄리티 어트리뷰트를 최대한 달성하고자 노력해야한다. 어렵지만 이 와중에 이를 위해 도출하려는 노력이 있어야한다.
- 주어진 프로덕트에 관련된 속성을 도출하는 것도 어렵고, 일반론적인 퀄리티를 프로젝트에 맞춰서 개발하는 것도 어렵다. 프로세스와 프로덕트의 품질과도 충돌이 발생할 수 있다. 소프트웨어 리스크에 대응하니 시간이 많이 걸린다. 이에 따라 프로세스를 가속화한다. 이때 퀄리티 체크는 2순위로 빠질 수 있다.
Process-based quality (process evolving)
- 절대 어겨서는 안되는 룰이 아닌 이는 결국 노하우가 들어간 프로세스와 기준이 된다.
- 프로세스를 정의하는 것으로 시작한다.
- 퀄리티가 보장되지 않는 경우에는 프로세스를 개선한다. 이때 본인들의 노하우를 넣을수도 있다.
Quality culture
- 퀄리티를 관리하는 매니저는 퀄리티관련 문화를 만들어야한다. 개발자 스스로 책임감을 가지고, quality 팀에 존중하고, 기여하도록 한다.
2. Software standards
1) Software standards
(1) Software standards
- 소프트웨어의 퀄리티를 관리하기위한 기준으로 지켜야하는 규정이다.
- 소프트웨어 프로덕트나 이를 만드는 프로세스에 대한 규정을 만든다. 이는 국제적/국가적/조직적 규정이 되거나, 작게는 프로젝트만의 규정이 될 수도 있다.
(2) Importance of standards
- best practice: 개발자들의 노하우가 들어가있는 규정을 만들면 이후 사람은 시행착오가 줄어든다. 일종의 체계화된 것으로 본인의 프로젝트에 맞는 것을 구체화한 뒤, 시행착오를 줄인다.
- 위의 과정을 이해하고, 꾸준히 체계화된 프로세스를 지속가능해야한다.
2) Product and process standards
(1) Product standards
- 퀄리티 관리를 증명하기 위한 문서가 나온다. 문서의 체계가 나와서 문서가 어떤 내용을 담고 있어야하는지 얘기한다. 목차, 형식, 옵션으로 들어가야할 것들에 대해 얘기한다. 문서의 템플릿이 존재해 이를 채워넣는 것으로 시작한다. 개발에서는 소스코드, 헤더파일, 리소스 파일을 만드는 부분에 대해서도 규정한다. ex) 들여쓰기를 탭이 아닌 space 네번을 누른다. / 메소드의 이름을 사전에 정의한다.
- 사람이 읽는 문서의 형태, 체계나 언어별 메소드 등을 정의한다. 즉, 양식을 정의한다.
(2) Process standards
- 절차를 정의한다. 명세서를 쓰거나 디자인, V&V를 하라고 얘기하는 등을 하라고 한다.
- 절차와 소프트웨어 도구가 이에 해당한다.
표 예시
- 왼쪽은 소스파일이나 문서에 대해 정의한다. 오른쪽은 행위에 대해 정의한다.
3) Problems with standards
(1) Standard의 문제점
- 본질을 이해하지 못하면 문제가 발생할 수 있다. 결국 개발자 입장에서 기준이나 규정의 거리가 멀어진다. 이를 왜 하는지 이해가 안될 수 있다. 점점 양식이 강화되면 불만을 가질 수 있다. 개발팀이 이에 대한 필요성을 느끼지 못할 수 있다.
(2) Standards development
- 왜 퀄리티를 관리하는지를 본질적으로 이해하고 개발자에 도움이 되며 목표를 달성해야하고, 개발자는 퀄리티를 만족시키는 것이 중요하다는 것을 이해하고 의미있는 일을 해야한다.
- 고정된 법규가 아닌 누구나 이를 바꿀 수 있고, 시대에 맞춰 바뀌어야한다는 것을 인지해야한다.
- 자동화된 소프트웨어를 만들면서 위의 과정이 알아서 스스로 이뤄지게하고, 개발자는 순수하게 좋은 소프트웨어를 짜기 위해서 이에 포커싱하도록 집중해야한다.
4) ISO 9001 standards framework
소프트웨어의 품질 관리와 관련된 국제적인 표준
(1) 개요
- ISO 9001은 소프트웨어인 경우에 CPU의 성능과 같은 것들을 따지는 것이 아닌, 소프트웨어 개발하는 회사와 팀이 소프트웨어 품질관리하는 절차와 표준이 있는지 없는지를 따진다. 절차와 표준을 만들어가는 것은 개발하는 회사의 책임이다. 절차와 표준이 소프트웨어를 정확히 체크하는지를 판단하는 것은 다른 얘기이다.
- ISO 9001과 같은 국제적인 단체도 우리 회사가 충분히 퀄리티에 고민하고 있다는 것을 동의하는 목적으로 인증을 받는 것이다.
- 절차와 표준도 일반적인 것을 얘기하고, 회사는 이를 구체화한다. 자체 문서와 매뉴얼을 통해 ISO 9001에서 권장하는 절차와 표준에 부합하는 결과물을 만들도록 어떤 식으로 하는지 정의한다.
(2) ISA 9001 core processes
- 다음과 같은 프로세스가 있는지 확인한다. 각 단계별로 어떤 절차와 어떤 문서를 만들고 어디에서 이를 관장하는지 제시한다.
- 개발 외적의 지원하는 조직이 있는지, 그 조직이 소프트웨어를 만들 때 어떤 프로세스를 거치고 이러한 결과물을 만드는지 예시를 보여주고 이를 따른다면 ISO 9001 인증을 해준다. 따라서 실제 수행되고 있는 소프트웨어 자체의 고유적인 특징과는 상관없다. 어떤 것을 하던지 품질관리를 하기 위해 어떤 절차과 표준이 있는지, 문서를 만드는지 등등을 하는지를 검사한다.
(3) ISO 9001 and quality management
- 자체적으로 어떻게 할지 메뉴얼을 정한다. 문서화 작업을 통해 ISO 9001의 템플릿으로부터 우리의 소프트웨어에 맞게 이를 정한다. 우리 프로젝트에 맞게 조금씩 조정될 수 있다.
- 다시 요약하자면 ISO 9001은 절차와 표준이 있는지, 이를 제대로 수행하고 있는지를 확인하는 것이다. 이를 준수한 소프트웨어는 신뢰할 수 있다고 판단한다.
(4) ISO 9001 certification
- 위의 내용을 준수하면 Certification 인증을 한다. 고객은 개발사가 ISO 9001 인증을 받는다면 적어도 품질관리에 대한 노력을 한다는 것을 알 수 있다. 하지만 무조건적으로 정성/정량적인 품질이 보장된다는 것은 아니다.
(5) Software quality and ISO 9001
- 내가 주문한 소프트웨어에 100% 동일하게 적용되지 않기에 정성/정량적인 항목을 제대로 도출하지 못한다면 절차와 표준을 따라서 ISO 인증은 받을 수 있지만 실제 품질이 좋지 않을수도 있다. 따라서 정량적/정성적인 지표를 잘 도출하는 것이 중요하다.
cf) Google Style Guids
- 프로그래밍 언어별로 사용하는 방법에 대한 가이드
- 구글 내에서 각 언어별로 어떤 것을 사용할 때 반드시 지켜야하는 규칙으로 이를 지키지 않으면 컴파일을 하지 못한다.
- 기본적인 기능을 구현할 수 있다면 가고 싶은 회사의 코딩 가이드라인을 읽어보는 것도 좋다.
- server based로 코딩을 하는 것에 관심이 있다면 Software Engineering at Google을 읽어보는 것도 좋다.
3. Reviews and inspections
1) Reviews
소스코드를 보는 것은 퀄리티를 높이는 방법 중에 하나이다.
(1) Reviews
- 테스트에서 얘기한 코드 리뷰는 inspection에 가깝고, 해당 챕터에서 Reviews는 조금 더 큰 개념이다.
- 품질 관리에서 리뷰는 프로세스도 포함한다.
- 개발 과정에서 수많은 소스코드나 문서, 프로세스를 지켜보고 문제가 있을만한 부분을 찾고, 개선하는 식으로 진행한다. 이후 이상이 없다고 판단되면 approve해서 다음 단계로 넘어간다.
- 문제가 있는 부분을 확인하는 것도 포함하고, 프로세스의 진도나 체계적으로 거쳐야할 단계를 거치는지 등 확인한다.
(2) Quality Reviews
- 품질 리뷰는 코드를 포함해서 디자인 관련된 문서나 표준, 사양, 절차, 테스트 케이스를 대비한 시나리오, 프로세스와 표준 등등을 모두 포함한다.
(3) Phases in the review process
(3-1) Pre-review activities
(3-2) The review meeting
- 리뷰 팀이 별도로 있으면 객관적인 시각으로 리뷰를 할 수 있다고 본다.
(3-3) Post-review activities
- 문제점이나 이슈가 있으면 이를 전달한다.
[ The software review process ]
(4) Distributed reviews
- face to face에 맞춰 리뷰를 하도록 권장한다.
2) Inspections
(1) Program inspections
- 개발자들이 상호로 리뷰를 하거나, 한 사람이 개발하고, 한 사람은 리뷰하는 식으로 진행하기도 한다.
- 구현 이전에 소스레벨에서 이를 확인한다.
- 눈으로 보고 코드를 확인하는 것은 매우 중요하다.
(2) Inspection checklists
- 어떤 프로그램에서든지 발생하는 흔한 에러에 대한 체크리스트를 만들어서 루틴적으로 한다.
- 특정한 언어와 관련되어 자주 발생하는 에러도 확인한다.
- 조금 더 나아가서 코딩 스타일 가이드를 지키는지도 확인한다.
- 이러한 것들이 미리 걸러지면 더 효율적으로 집중할 수 있다. 따라서 코드리뷰 이전에 미리미리 이뤄지면 더 좋다.
An inspection checklist
- C++과 같은 프로그래밍 언어를 가지고 프로그래밍을 짤 때 동적 메모리 할당을 하는데 메모리에 직접 액세스하기에 이를 잘 사용해야한다. linked list가 제대로 구현되었는지, 제대로 짜여졌는지 등을 확인해야한다.
- 사용한 메모리도 반드시 해제해야한다.
cf) 우리가 무의식적으로 가장 많이 사용하는 Inspections
- VS 코드에서 파이썬 익스텐션을 사용하면 코드를 분석하는 lint라는 기능을 사용한다. 이는 프로그램 실행 시 문법이 잘못되면 프로그램을 실행하지 않더라도 빨간색이 쳐지면서 문법이 잘못되었다고 알린다.
- 린트란 소스 코드를 분석하여 프로그램의 오류, 버그, 스타일 오류, 의심스러운 형태의 오류를 알려주는 도구이다.
- 파이썬 플러그인은 린트를 비롯해 디버깅, 코드 포맷팅, 리팩토리 등의 기능을 제공한다. 이에 따라 매우 편리하게 이를 체크할 수 있다.
4. Quality management and agile development
1) Quality management and agile development
- 품질관리는 informal하다고 판단하고, 이를 위한 절차를 정하기보단 품질을 관리하기 위한 개발자의 역량이나 문화를 더 강조한다.
- agile은 ISO 9001과 같은 표준을 좋아하진 않는다.
(1) Shared good practice
- Check before check-in: 빌드를 하기 위해 내가 만든 코드를 함께 리뷰를 해야한다.
- Never break the build: 여러 사람이 만든 소프트웨어를 합칠 때 integration이나 빌드를 중단하면 안된다.
- Fix problems when you see them: 본인이 짠 소스코드가 아닌 것에서 에러를 발견하는 경우에는 본인이 직접 에러를 수정한다.
2) Reviews and agile methods
- Scrum은 review meeting을 하고, Extreme Programming도 pair programming을 해서 이를 하도록 강조한다.
(1) Pair programming
- 두명이 같은 소스코드를 동시에 함께 짠다. 한명이 타이핑하면 다른 사람이 제대로 쓰여졌는지 이를 확인한다.
- 상당히 효과가 좋다고 검증된 방법이다.
(2) Pair programming weaknesses
- Mutual misunderstandings: 두 사람이 모두 실패하는 경우
- Pair reputation: 에러를 발견하더라도 둘이 합의해서 넘어간다.
- Working relationships: 상대방에게 얘기하면 지적하는 것처럼 느껴질까봐 얘기하지 않는다.
3) Agile QM and large systems
- Agile 접근을 사용하면 최소한의 문서를 신경쓰지 않는다면 거의 불가능할 것이다.
- Agile을 해서 소프트웨어를 개발하고자 하지만 large system인 경우에는 고객을 위해 문서를 만들 필요가 있다.
5.Software measurement
우리가 만들 소프트웨어를 어떻게 정성/정량적인 지표로 관리할 것인지
1) Software measurement
- 정량적이라면 숫자가 의미가 있고, 정성적인 부분은 최대한 정량적인 부분으로 찾고자 해서 소프트웨어 개발을 제대로 하고 있는지 비교/검증한다.
- 표준이 없기에 본인 스스로가 본인의 프로젝트에 대해 잘 이해하고 최대한 의미가 있을 법한 정량적 지표를 매핑해가는 고민의 과정이 필요하다.
(2) Software metric
- 지표를 추출해 평가에 쓰고자 한다. 정성적인 지표는 정량적인 숫자로 매핑해서 이를 판단한다.
- 프로덕트/프로세스 모두에 검증할 수 있다.
- 소프트웨어 프로덕트 자체에 대해 측정하는 방법과 프로세스 측면에서 제대로 하기 위한 활동을 체크하기 위한 방법이 모두 존재해 이를 뒤에서 확인할 것이다.
- 프로세스에 대한 부분도 제대로 하고 있는지 계량화된 수치를 통해 추적, 관리하고자 한다.
2) Process metric
(1) Types of process metric
- plan based인 경우에는 시간을 측정해서 반복적인 플래닝에서 조절하거나 인력을 투입할 때 용이하다. 또한 자원 소요가 얼마나되는지 추적한다면 앞으로 진행될 사항에 대해 예측할 수 있다. 또한 코드 검사에서 발견한 에러, 버그리포트, 프로그램의 크기 등등 발생하는 이벤트에 대해 측정할수도 있다.
[ Predictor and control measurements ]
(2) Use of measurements
- 유지관리가 용이한가?와 같은 정성적인 부분을 어떻게 계량할 것인지가 중요하다.
- cyclomatic complexity: 소프트웨어 분야에서 함수가 제대로 짜여져있는지 판단하는 기준이다. 프로그램은 함수나 메소드 내에 조건문이나 반복 등이 들어가는데 얼만큼 들어가는지가 계산될 수 있다. 이때 얼만큼의 복잡도를 가지는 지 등을 판단할 때 사용된다.
- 복잡한게 많아지면 유지보수 하기 어렵지 않을까? 하고 생각해 수치화할 수 있는 부분은 수치화한다. 이와 같이 정성적인 부분을 수치화해서 이를 판단하고자 한다.
- Complexity가 높다는 것은 읽기 어려울수도 있다. 이에따라 오류가 발생할 가능성, 버그가 발생할 가능성 등이 높아질 수 있다. 수치화할 수 없던 정성적인 부분과 수치화한 계량부분을 통해 개선할 부분을 찾는다.
(3) Metrics assumptions
- 상관관계를 따지면서 합리적인 접근을 할 수 있다.
- 정성적인 부분을 정량적인 부분과 매칭을 하지만 사실 반드시 맞다고 하기는 어렵다.
- 유전의 법칙을 너무 많이 사용하는 경우에는 유지보수가 어렵다.
- 프로그램 라인 사이즈가 얼마나 기냐, 에러 메세지가 얼마나 많이 발생하냐, 문서의 길이 등등을 각각 정성적인 속성과 매칭시켰다.
(4) Problems with measurement in industry
- 어떤 측정 지표를 사용할 것이며 그것을 어떻게 정량적인 지표와 연결할 것인가가 중요하지만 이는 표준이 없다.
- 대부분의 회사들은 소프트웨어 프로세스의 표준화가 약하다.
- 추가적인 일이 발생할수도 있다.
- 위와 같은 내용들 때문에 측정하는 것에 대한 문제점이 있다.
(5) Empirical software engineering
- 품질 관리에서 소프트웨어 관리로 오면 agile에서 얘기하는 개발자 노하우나 지식 등이 투영되어야한다.
- 프로그래밍을 많이 짜보고 얼마나 효율적으로 돌릴 수 있는지 등을 경험하는 것이 중요하다.
3) Product metrics
(1) Product metrics
- 정량화되어있는 지표를 사용한다.
- 동적인 접근 방식과 정적인 접근 방식이 있다.
- 동적 접근 방식: 측정할 수 있는 숫자를 실행되고 있는 상태에서 추출하는 방식으로 프로그램이 실행될 때 나오는 숫자를 확인한다. 효율적으로 돌아가는지, 작은 메모리, 적은 반응속도, 빠른 통신 속도 등등이 된다.
- 정적 접근 방식: 소스코드를 보고 실행하기 전 단계에서 이를 확인한다. 소스코드를 읽고 이해하는 방식이다. 복잡도나 읽고 이해할 수 있는지, 유지보수에 용이한지 등을 판단할 때 유용하다.
(2) Dynamic metrics
- 측정 코드를 소스에 넣을 수 있어서 요청이 왔을 때 응답하는 시간, 실패가 얼마나 나오는지 직접 확인할 수 잇다.
(3) Static metrics
- 사람이 논리적으로 분석할 수 있는 것들인 브랜치문, 조건문의 깊이, 코드를 쉽게 이해할 수 있는지 등이나 함수를 얼마나 잘 쪼개고, 클래스를 잘 만들었는지 등을 판단할 때 유용하다.
- 숫자로 계량할 수 있는 것은 Fan-in/Fan-out이 있다. 함수를 호출하는 것은 Fan-in, 함수 내에서 다른 함수를 호출하는 것은 Fan-out이다.
- 코드의 길이를 센다. 긴 것은 일반적으로는 더 복잡하고 에러 발생의 여지가 크다고 본다.
- 함수 그래프가 얼마나 복잡한지, 변수의 이름에 대한 길이, 조건문 내에 조건문이 얼만큼 들어가는지, 소프트웨어 안에 있는 글자의 숫자를 세서 인덱스를 만드는 것도 이를 판단할 때 유용하다.
(4) CK object-oriented metrics suite
- 객체지향 언어로 만든 소프트웨어를 평가할 때 쓰는 기법으로 이를 활용해 소프트웨어 프로덕트의 퀄리티를 계량화한다.
- WMC: 클래스 내에 메소드가 얼마나 존재하는지, 너무 많거나 너무 적으면 문제가 될 수 있다.
- DIT: 유전의 법칙에 의해 서브 클래스가 얼마나 깊게 만들어지는지
- NOC: 베이스 클래스로부터 얼마나 많은 개수의 자식 클래스가 만들어지는지 확인한다.
- CBO: 클래스가 클래스를 서로 부를 수록 밀결합도가 높아진다.
- RFC: 하나의 클래스의 메소드가 호출됐을 때 한번 호출에 의해 얼마나 많은 메소드들이 호출되나.
- LCOM: 메소드를 통해 내부 데이터에 접근할 때 하나의 메소드에 대해 얼마나 많은 state가 연결되어있는지
- 이런 것들을 중에 어느정도 체계적인 부분이 있기에 이를 이해하고 학습하는 것이 중요하다.
4) Software component analysis
- 정성/정량적인 지표를 통해 퀄리티를 제어하는데, 이것이 좋은지, 나쁜지를 판단하는데 힌트를 줄 수 있다.
- 우리 회사가 소프트웨어를 많이 작성했는데, 레포지토리에 이것들이 있으면 옛날 소프트웨어를 측정해볼 수 있다. 현재 가지고 있는 지표들을 가지고 이전 소프트웨어에 적용을 해봤더니 최근에 만들어진 소프트웨어일수록 수치가 의미적으로 좋게 나온다거나 점점 나빠진다면 소프트웨어의 퀄리티가 어떻게 변화하고 있는 지를 확인할 수 있다.
[ The process of product measurement ]
5) Measurement ambiguity
- measurement를 잘 정의해야한다. 과거의 소프트웨어부터 체크를 할 것이기에 이를 잘못 정의한다면 실제 소프트웨어의 성능이 좋아지더라도 이를 좋지 못한다고 판단할 수 있다.
- 정성적인 부분을 정량적인 부분으로 매핑할 때 상관관계나 지표나 소프트웨어에 대한 이해가 필요하다. 이에 따라 사람이 중요해진다.
예시)
사용자들이 변경을 요청하는 횟수를 기준으로 메트릭을 결정했다. 베타테스트에서 변경 요청하는 횟수를 확인해보니 계속 늘어나는 것을 확인할 수 있다. 이때 변경 요청의 횟수는 다음과 같은 이유로 늘어난다.
- 요청사항을 반영해서 고칠수록 소프트웨어의 문제가 더 많이 생겨서 요청횟수가 늘어난다.
- 요청사항을 반영해서 고칠수록 소프트웨어의 성능이 늘어나 사용자가 늘어 요청횟수가 늘어난다.
-> 이에 따라 이러한 점들은 단편적으로 해석할수는 없고, 다각적이며 의미있는 해석이 필요하다.
6) Software analytics
- 퀄리티 관리에서 마지막으로 얘기하고자하는 것은 자동화된 툴과 대량의 데이터를 모으고 이를 분석한다.
- 결국 소프트웨어를 실행하고 자동으로 운영하면서 얻어지는 데이터를 대량으로 모아서 의미를 찾는 것이다.
- 소프트웨어가 실행되다가 죽으면 이를 개발사에 보낸다. 이를 통해 실시간으로 문제점을 확인하고 수집할 수 있다. 이러한 툴은 많이 사용한다.
- 오픈소스 소프트웨어를 분석하고 공유하여 품질 제어에 사용하고자 한다.
(1) Analytics tool use
- 쓰기 쉬워야하며, 원하는 형태로 꾸밀 수 있어야한다.
- 대량의 데이터를 자동으로 모을 수 있어야한다.
- 퀄리티를 관리하고 끌어모으는 데에 이를 활용해서 사용할 수 있다.
- 하지만 데이터를 수집하고 관리하는데에는 회사에서 부담이 될 수도 있다.
Key points
- 소프트웨어의 품질을 관리하는 방법: review와 inspection
- Agile은 어떻게 해야하는지, ISO 9001은 일반화된 프로세스를 제안하고, 우리 소프트웨어에 대한 품질 관리는 메트릭을 정량화해서 평가한다.
- 메트릭스는 프로세스, 프로덕트에 대해 정할 수 있다.
- 데이터를 자동으로 수집, 분석하여 품질 관리를 할 수 있을 것이라고 얘기한다.
'강의 내용 정리 > 소프트웨어 공학' 카테고리의 다른 글
| 소프트웨어 공학 (15), Configuration Management (0) | 2022.06.15 |
|---|---|
| 소프트웨어 공학 (13), Project planning (0) | 2022.06.14 |
| 소프트웨어 공학 (12), Project Management (0) | 2022.06.10 |
| 소프트웨어 공학 (11), Software Evolution (0) | 2022.05.26 |
| 소프트웨어 공학 (10), Software Testing (0) | 2022.05.18 |