[소프트웨어공학] 24장 Quality Management

-> 앞에서 다룬 개발을 통해 소프트웨어가 도달해야할 양적 질적 수준에 도착하였는가 판단하는 것 -> QA팀(개발이 잘 되었는지 판다하는 그룹)

 

주요주제

• Software quality -> 소프트웨어 퀄리티 정의
• Software standards -> 소프트웨어 품질 관리 표준 적립
• Reviews and inspections -> 품질관리에서 코드를 리뷰하는 정적관리, 실행 시에 코드가 잘 동작하는지 보는 다이나믹 분석이 있음
• Quality management and agile development -> 에이자일의 경우 품질관리가 어떻게 이루어지는지 확인
• Software measurement -> 정량적으로 소프트웨어의 품질이 어떤지 측정하는 방법론

 

Software quality management

-> 소프트웨어 마다 지켜져야 할 항목과 레벨이 존재함

-> 이 단원에서 우리는 소프트웨어 품질을 유지관리하기 위한 프로세스 절차나 규정이 어떠할지 이야기함.(이러한 품질이 잘 지켜졌는지 판단이 필요)

 

>>3가지 주요 관심사

-회사 조직적 -> 어떤 소프트웨어가 되던 우리 회사가 개발하는 소프트웨어에 대해서 이러한 체계와 표준과 방침을 가지고 소프트웨어 품질을 유지합니다. -> 이러한 회사차원의 방침이 있어야함.

-직접적으로 개발을 진행할 프로젝트적으로 진행해야할 업무 2가지

-> 위 사람들이 정의한 절차와 표준을 잘 지키고 있는지 확인하는 것

-> 프로세스와 표준을 지키면서 우리 프로젝트가 달성해야할 품질을 달성하는 것

 

Quality management activities

-> 정의되어 있는 규정, 프로세스, 표준을 따르는지 평가

-> 대규모의 프로젝트를 진행하는 회사와 같은 곳에서는 품질을 관리하는 부서가 따로 독립적으로 존재함.(객관적인 관점을 유지하기 위함)

 

Quality management and software development

개발이 끝나고 Quality management팀으로 오게 되면 개발된 소프트웨어를 가지고 프로세스는 제대로 존재했는지 당초 이 프로젝트가 목표로 설정한 것을 이루어나가고 있는지 평가함.

-> 획일화된 내용은 없음 (에이자일에서도 유연하게 사용됨.)

 

Quality planning

품질 계획을 한다는 것 -> 우리가 만들고자하는 제품에 퀄리티를 정의함 -> 퀄리티가 정의된 것이 제대로된 절차에 의해 수행되었는지 확인 -> 프로젝트 별로 고유에 달성해야하는 퀄리티에 대한 항목들이 존재하는데 이것을 정의하고 측정하고 관리하고 하는 작업을 함.

품질 계획 -> 앞서 정의한 프로세스와 표준을 기반으로 프로젝트에 특화된 퀄리티를 측정하고 관리하고 유지보수하며 제대로 조절하는 절차이다.

-> 회사 차원의 표준이 존재해야함

-> top-down방식을 하다가 에이자일로 방식을 바꿨다며 그에 따라 회사차원에서 적용해야할 표준들을 새롭게 정의해야한다.

 

Quality plans 표준 가이드라인(문서화 작업)

-Product introduction(이 제품은 무엇인지)

-Product plans(이 제품은 어떠한 계획으로 만들어질 것인지)

-Process descriptions(퀄리티를 어떠한 프로세스와 표준에 따라 진행을 할 것인지)

-Quality goals(퀄리티의 고유의 목표는 무엇인지)

-Risks and risk management(목표를 달성함에 있어 위험요소는 무엇이 있고 어떻게 대처할지)

>>개발팀 외에 많은 팀들이 많이 붙고 있음 -> 너무 길어질 우려가 있음 -> 따라서 퀄리티 계획은 너무 많은 것을 담아내려하지 말고 1,2시간 설명만으로 이해가 가능할 정도의 레벨에서의 프로세스, 목표, 관리를 설정하는 것이 효과적임.

-> 그렇지 않으면 사람들이 무시해 버릴 수 있음

 

Scope of quality management

-large, complex systems. -> 복수의 많은 회사들이 들어갔을 경우 어느 정도 plan-based 기법으로 큰 틀에서 정해져야함.(문서화되고 체계화된 것들이 정해져야함.)

-For smaller systems - quality management needs less documentation and should focus on establishing a quality culture. -> 작은 소프트웨어라면 문서도 작아야하고 품질을 관리할 별도의 팀이 없다면 본인들이 스스로 확인하는 문화가 있어야함.

-Techniques have to evolve when agile development is used.

 

 

 

Software quality(이 소프트웨어가 지켜야할 것들은 이런 것이라고 규정하는 것)

-> 소프트웨어 product가 있다면 우리가 정한바가 달성되었는지 확인하는 것

-> 실제로 이런 것을 규정하고 표준으로 정한 것을 만족하기란 쉽지 않음.

>>고객 품질 요구사항(효율성, 신뢰성 등)과 개발자 품질 요구사항(유지보수성, 재사용성 등) 사이에 긴장감이 있습니다. -> 이렇게 추상적인 말들을 많이 사용함. -> 이러한 추상적인 단어들이 어떻게 하면 구체적으로 바뀔 수 있는지 생각하는 것이 소프트웨어 계획을 할 때 가장 고심하는 것임. -> 이러한 단어들이 누구나 읽었을 때 같은 의미로 받아드리게 하는 것이 쉽지 않음.

>>소프트웨어 사양은 대개 불완전하고 일관성이 없는 경우가 많습니다. -> 어느 정도는 안고 가야하는 부분임.

>>써져있는 문구를 만족시키는 것보다 완성된 것을 모두가 만족하고 인정할 수 있는 것을 추구하는 것이 좋다.(정량적으로 나와 있는 것은 수치적으로 만족하면 되고 그렇지 않다면 소프트웨어에 대한 요구사항을 썼고 고객님과 열심히 대화를 나누고 있기 때문에 이러한 것들을 기반으로 만족됨을 판단한다.)

-> 수치적으로 나왔는 것이 아니라면 앞서 정한 목표들에 도달했는지 만족할만한 결과인지를 판단하여 소프트웨어 품질이 맞춰졌다라고 생각할 수 있다.

 

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?

예를 들어서 깃허브와 같은 곳에서 레포지터리를 만들 때 반드시 라이센스와 디렉토리 구조에 대해 설명하는 텍스트파일(Readme)이 있어야한다. / 디렉토리 이름을 정할 때 소스코드는 소스 밑에 넣어두고 소스코드가 아닌 것은 리소스 파일은 res, 데이터는 dat에 넣어야한다. -> 이렇게 만들어져 사용되는 것들을 경험적으로 정의해 나감.

-Have programming and documentation standards been followed in the development process? -> 소프트웨어에서 만족해야할 파라미터를 정의하는 것도 중요하지만 회사가 정의한 절차를 지켜서 그 과정에서 문서가 나왔는지를 따지는 쪽으로 가게됨.

>>과정에 본질을 묵시하고 실행된 절차에만 초점을 두는 문제가 발생할 수 있음.

>>위와 같이 추상적인 단어들이 많이 사용됨.

>>최선을 다해서 대부분의 개발자와 관리자가 합의한 것들을 잘 준수하는지, 본질에 맞는 결과물이 나오고 있는 것인지 따지는 것이 품질관리이다.

>>모두가 선한 의지를 가지고 소프트웨어가 본질에 맞춰 개발되고 있는지 판단하는 것이 필요함.

 

 

Non-functional characteristics(정량적이지 않고 추상적인 단어가 쓰인 부분이 여기서 많이 발생함.)

-Non-functional한 부분 역시 객관화 규정화하여 목표에 도달할 수 있게 노력함

-정량적인 부분은 수치에 맞게 도달하면 되고 정성적인 부분역시 목표에 도달하게 노력하는 이유는 그에 맞지 않다면 사용하지 않을 수 있기 때문이다.

-하지만 정량적인 부분 역시 중요하다/ 느리거나 믿을 수 없다면 사용할 수 없기 때문이다.

>>소프트웨어를 열심히 개발을 하는 것도 중요하지만 많은 사람들이 잘 사용할 수 있는 소프트웨어를 만드는 것이 중요하기 때문이다.

 

>Software quality attributes(소프트웨어 품질에 판단에 정성적인 표현)

안전한지, 이해가능한지, 적응할 수 있는지, 효율적인지, 사용할 사람들이 잘 접근할 수 있는지 등 -> 이렇게 추상적인 지표들이 존재하고 이렇다 하더라도 최대한 정량적으로 뽑아내고 도달하려는 노력이 필요하다.

 

 

Quality conflicts

-> 여러 가지 퀄리티를 모두 만족시키는 것은 어렵다

예를 들어 암호화되어 있다면 암호화를 통해 부화가 많아져 실질적으로 도달했던 성능에 비해 떨어질 수밖에 없다.

-> 전사적 차원에선 위에 언급한 목표들을 정하고 프로젝트 차원에서 구체화하고 계획을 관리하고 도달하려고 하지만 실질적으로 프로젝트에서 적용하려고 하려면 프로젝트에 맞는 것을 도출해야 한다.(꼭 달성해야하는 것을 선정한다.)

 

Process and product quality

-> 소프트웨어의 퀄리티를 지키기 위해서는 퀄리티를 지키기 위한 프로세스를 준수하는 것이 중요하다. 그리고 준수하는 행위 속에서 우리가 목표로하는 프로젝트의 특성화되어 있는 퀄리티와 관련 있는 속성들을 최대한 도출하고 이것을 달성하려고 노력해야한다.

->주어진 제품 퀄리티 속성을 도출하는 것도 어렵고 회사에서 제시한 일반론적인 퀄리티를 우리 프로젝트에 맞춰서 도출하는 행위 역시 어려움.

-> 소프트웨어를 개발하는 프로세스와 제품의 품질을 추구하는 프로세스 역시 충돌이 일어날 수 있다. -> 소프트웨어에서 문제가 발생하고 이것에 대해 대처하다보니 시간을 너무 많이 사용해 버림 -> 그래서 우리는 소프트웨어에 대한 프로세스를 가속화함(deadline을 맞추기 위함) -> 소프트웨어 프로세스 상 개발에서 문제가 발생한다면 소프트웨어의 품질을 관리하는 과정은 2순위로 밀릴 수가 있다. -> 프로젝트를 계획하고 관리하는 것, 제품의 퀄리티를 보장하고 관리하는 것이 충돌을 일으킨 경우에는 또다시 문제를 야기할 수 있다. -> 결국은 누군가가 양보하거나 더 많은 일을 하는 경우가 발생할 수밖에 없다.

 

Process-based quality(process evolving) -> 일반적인 품질관리에 대한 프로세스 예시-> 절대로 어겨서는 안 되는 법과 같은 것이 아닌 시대가 변화고 트랜드가 변하고, 기술이 변함에 따라 그런 것들 역시 반영된 회사만의 노하우라고 생각할 수 있음.

-> 프로세스를 정의함 -> 이에 따라 제품을 만들고 이에 따라 제품이 퀄리티를 보장하고 있는지를 확인하고 -> 퀄리티가 보장이 되어있다면 여기서 우리가 있었던 행위들을 프로세스에 개선하는 행위들이 일어날 수 있음 or 퀄리티가 보장이 안됐다면 고민을 함(우리 프로세스에 문제가 있는지 -> 프로세스를 고칠 수 있음 -> 프로세스가 표준을 개선하는데 반영이 될 수 있음)

>>개발자로서 본인의 일을 잘하고 좀 더 좋은 프로세스를 개발하길 원한다면 주어진 프로세스와 표준들은 선배들이 쌓은 노하우이기 때문에 본인의 의견을 추가할 수 있음(악의적이지 않아야함)

 

Quality culture -> 결국에 가장 중요한건 위와 같은 행위들이 문화화 되어야한다.

-> 에이자일에서 명시했듯이 자발적인 스스로 알아서 할 수 있는 개발자들을 신뢰하고 신뢰할 수 있는 사람들로 팀을 구성하는 것이 좋다. -> 이러한 문화를 형성하기 위해서 회사 역시 지속적으로 교육을 할 것이다.

-> 주어진 일만 수행하고 나머지들은 나몰라 하는 사원은 좋지 않다. -> 본인이 정말 열심히 개발을 하고 스스로 의견을 제시할 수 있는 문화가 정말 중요하다.

 

Software standards -> 소프트웨어의 퀄리티를 관리하기 위한 표준(법규와 같은 것 – 지켜야 하는 것)

-> 프로세스에 대해서 규정이 만들어지는 것

-> 회사 전체가 따르는 규정일 수도 있고 새로운 것을 만들어서 기존의 규정이 없다면 새로 규정을 만들 수도 있다.

-> 우리 회사가 납품하는 회사라면 우리나라에서 소프트웨어를 납품하는 기업들 간에 우리 회사에 있는 것보다 더 신뢰할 수 있는 품질 규정을 따라 달라고 고객이 요청했다면 우리나라 차원에서 만들어진 것을 따라서 해야 한다.

-> 회사와 고객의 국적이 다르거나 부품들이 다국적으로 만들어진 것이라면 회사 규정이 아닌 밖으로 규정되고 공인된 소프트웨어 품질관리를 따를 필요가 있음.

 

Importance of standards(규정의 중요성)

-개발자들의 노하우가 스며들어 있는 규정을 만들면 후에 사람들이 개발함에 있어 실수를 줄일 수 있게 함.

-체계화된 framework이기 때문에 이러한 체계 속에서 본인이 본인의 프로젝트에 맞는 것을 좀 더 구체화한 후 품질을 만족시킬 수 있음.

-지속가능해야한다. -> 새로운 사람들이 들어온다면 그것들을 이해하고 따르고 개선될 것들이 있다면 수정하고 쌓아간다 -> 이런 것들이 쌓이면 쌓일수록 회사에서 만들어지는 소프트웨어들은 조금 더 견고하며 안전성을 가지고 단시간에 만들 수 있어진다.

 

Product and process standards

>>Product standards – 품질관리가 되었다 라는 문서가 나오는 것(문서의 체계들이 나오는 것) -> 당신이 작성하고자 하는 개발상의 이 문서는 어떠한 형태를 담고 있어야하는지 명시해둔 것(ex. 앞서 이야기한 요구사항에서 발생하는 문서들의 체계 목차, 형태, 반드시 들어가야할 것, 옵션으로 들어가야 하는 것, 문서 템플릿이 만들어져있는 것들도 있음), 개발 단계에서는 헤더파일, 리소스파일 등을 만들 때 파일명은 어떤 식으로 만들 것인지 규정하는 것, 클래스 함수들의 네이밍의 형태 역시 규정할 수 있음 -> 각각의 가이드라인이 존재할 수 있음, 양식을 정리한다고 생각할 수 있음

>>Process standards – 절차를 규정하는 것, 행위를 할 때 꼭 거쳐야할 절차 같은 것들을 규정함. -> 명세서를 작성하시오, 디자인을 하시오, 검증을 하시오

->수작업으로 하지 말고 자동화된 툴을 사용한다. -> 프로젝트 목적에 맞춰 이러한 것을 쓰시오 와같이 규정할 수도 있다. -> 절차와 소프트웨어 도구들이 이에 들어간다.

 

Product and process standards (examples, 앞쪽에 있었던 것의 예시)

Product standards

–디자인 리뷰를 한다고 했을 때 그 양식, 언제 누가 참여했고 어떤 프로젝트인데 어떤 팀이 참여했으며 누가 어떤 코멘트를 주었는지 등을 양식화하는 것

-요구사항 문서 양식

-소스코드 레벨에서 클래스에 메서드가 있다면 메서드는 반드시 정의되기 이전에 규정해야하는 것을 정하는 등의 표준

-프로그래밍 언어별 스타일 (언어별 확장자등을 규정)

-프로젝트 계획을 한다면 그런 것들에 대한 양식

-변화 요청이 들어왔을 때의 양식

>>구체적인 소스파일이나 문서에 대한 것을 정의함

 

Process standards

-디자인 리뷰활동을 하며 누가 어느 단계에서 해야 하는지 등을 규정

-시스템 빌드 어떻게 해야 하는지

-버전에 관한 릴리즈

-프로젝트 계획을 승인한다고 하면 누가 어떤 부분을 봐야 되고 기타 등등 행동

-변화를 조절하는 프로세스

-테스트과정을 정의하고 실현하는 레코드

>>행위에 관한 표준을 정의함

 

프로젝트의 본질을 이해하지 못했을 때 문제가 발생할 수 있음

>Problems with standards

-개발자 입장에서 표준이나 규정이 너무 멀어짐 -> 품질 관리하는 팀이 개발 환경에 대한 이해가 없으면 더 더욱이 그러한 것들을 오래된 것이라고 느낄 수 있음.

-더 더욱이 양식이 강화되면 양식을 만드는 것에 귀찮음을 느낌.

>>개발자 팀과 품질관리팀 사이에 이해관계가 좋지 않다면 문제가 발생 할 수 있음

 

Standards development

-> 품질 관리하는 사람은 왜 관리하는지를 본질적으로 이해하고 개발자의 도움이 되면서 목표를 달성할 수 있어야 함.

-> 개발팀은 퀄리티를 만족하는 것 궁극적으로 소프트웨어가 만들어지는 목표이니 최대한 품질관리팀과 상호작용을 하면서 의미 있는 일을 해야 함.

>>고정된 법규라 못 바꾸는 것이 아님 -> 누구나 이해를 해야 하고 경험이기 때문에 시대에 맞춰 개발자들의 변화에 맞춰, 기술의 변화에 맞춰서 개발 방법론의 변화에 맞춰서 주기적으로 표준과 프로세스를 보고 업데이트를 하는 작업이 필요하다 -> 더불어 수작업이 아닌 자동화된 툴을 사용하여 알아서 스스로 이루어지게 하는 것이 중요함.

 

ISO 9001 standards framework(국제적 소프트웨어 품질관리 표준, 국제 표준)

ex. 구글에서 규정한 것들 중 -> 언어별 지켜야할 규정들이 명시화되어있다.

-> c++의 output 파라미터는 리턴 값으로 이루어져 있어야한다.

>>원칙이 명시화되어 있음 -> 지켜지지 않으면 소스코드레벨에서 거부해버린다.

>>다양하고 많은 규정들이 명시화되어있음.

>>소프트웨어를 개발하는 회사가 소프트웨어 품질을 관리하는 절차가 있는지 없는지를 평가함. -> 우리 회사가 소프트웨어 개발을 진행할 때 품질관리 표준을 가지고 있는지 확인함.

>>프로세스와 표준이 있는지 없는지를 확인을 하기만 함 -> 만드는 것은 회사에서 하는 것임.

>>회사가 품질에 대한 노력을 기울이는지 확인을 하는 것임

>>일반적인 것을 이야기하고 -> 구체화하는 것은 회사의 몫임.

>ISO 9001 core processes(26page)

-> 여기서 묻는 것은 프로세스가 존재하는지

-소프트웨어를 개발하는 측면에서 비즈니스 측면에서 어떻게 만들어지는지

-테스트 개발, 디자인을 하는 측면에서 어떠한 과정이 있어야하는지 제시해줌

-> 개발 외에 서포트해주는 조직이 있는지 -> 어떠한 프로세스를 거치고 있는지 확인을 하고 명시되어 있는 과정을 따르는지 확인함

-> 실제 수행이 되고 있는 프로그램의 고유적인 측면하고는 무관함 -> 우리 회사가 소프트웨어를 개발할 때 품질 관리를 위해서 어떤 절차가 있고 규정이 있고, 표준이 있는지를 검사해서 인증을 줌

 

ISO 9001 and quality management -> 제시하는 권장사항이 있음

-> 회사 별로 구체화하는 과정이 필요함 -> 고유한 것을 정함

-> 전사적인 것이 정해지고 프로젝트별로 사용되는 것은 변경되어 적용될 수 있음

>>절차를 거치고 있는지 그러한 절차를 거치고 있으면 신뢰할 수 있다고 판단함

 

ISO 9001 certification(확인을 해주는 것)

>>본인들이 원하는 것을 모두 만족했다면 인증을 해주는 것

>>고객들이 회사에게 요구할 수 있음(인증을 받아오라)

>>절차와 프로세스가 있는 것이지 -> 프로젝트가 무조건적으로 옮은 결과를 만들어낸다고 보장하는 것이 아님 -> 우리가 원하는 프로그램에 대한 것들을 명시하는 것은 그러한 과정 속에서 명확히 정의하는 것이 필요함.

>>우리 회사에서 소프트웨어를 만들어 사용을 한다면 회사 자체적으로 필요한 노하우를 쌓아가는 것이 좋다.

 

 

Reviews and inspections

-> 테스트 시 코드리뷰보다 조금 더 큰 의미의 리뷰임 -> 코드리뷰는 inspection과 유사함

 

Review(코드리뷰보다 규모를 크게 봐서 프로세스를 포함함)

-> 본다. -> 개발과정에서 소스코드, 문서들이 나옴 + 프로세스, 절차들을 잘 지켜보는 것 -> 문제가 있는 것을 찾아가는 것 -> 문제를 찾고 개선하는 과정을 반복하며 문제가 모두 해결되면 다음단계로 넘어갈 수 있게 승인함.

->테스트 시 소프트웨어 문제가 있는 부분을 포함하고 제품과 프로세스의 진도, 이것을 위해서 체계적으로 거쳐야하는 과정을 잘 거치고 있는가?

-> 프로세스, 퀄리티, 표준을 잘 지키고 있는지 확인함.

 

Quality reviews

-> 코드를 포함해서 디자인과 관련된 문서들 기타 사항서에 대한 문서들(요구사항 정리 때 했던 것), 테스트케이스에 대비해서 제대로 시나리오가 나오고 문서들이 나왔는지 그와 관련된 프로세스와 표준들이 준수되고 있는지?

>>이러한 것들이 잘 이루어지고 있는지 확인하고 문제가 있으면 보안하고 제대로 된 결과문들이 나올 수 있게 함

-> 절차를 어떻게 이어갈 것인지

- 리뷰를 보기 전(리뷰를 위한 준비과정)

- 리뷰를 보는 중(리뷰미팅 진행, 별도의 리뷰 팀이 있다면 객관적인 입장에서 리뷰를 진행할 수 있음)

- 리뷰를 마친 후(도출된 문제점이나 이슈사항을 전달하고 개선하라고 함)

>>위 과정들을 반복적으로 진행함

 

software review process

-> 계획을 세움/그룹이 모여 어떻게 할지 준비함 -> 각각 개별적으로 준비물을 산출함 -> 리뷰팀 전담 하에 리뷰미팅을 진행함 -> 에러 도출/개선작업 진행 -> 에러가 모두 해결 될 때까지 반복적으로 수행 -> 에러를 모두 해결했다면 리뷰를 마쳤음을 다음 단계에 전달함

 

Distributed reviews

-> 얼굴을 직면해서 미팅을 진행하는 것을 권장함.

-> 그것이 어렵다면 비대면 방식으로 진행이 될 텐데 최대한 직면하는 방식과 유사하게 진행하도록 권장함

 

Program inspections -> 코드리뷰와 유사

-> 개발자들이 상호 크로스하며 코드리뷰를 진행함

-> pair programming을 진행 -> 한 사람은 개발하고 한 사람은 디자인하고 다시 뒤집어서 진행함

-> 소스코드를 실행하기 전 단계인 코드레벨에서 보는 과정 -> 우리가 조금 더 시야를 넓일 수 있음. -> 좋은 소스코드를 눈으로 읽어라!

 

Inspection checklists -> 체크리스트가 있으면 좋음

-> 일반적으로 프로그램에서 발생할 수 있는 흔한 에러들은 체크리스트로 만들어서 확인함.

-> 좀 더 나아가서 특정 언어에서 발생할 수 있는 흔한 에러들을 체크함 -> 파이썬에서 인덴트를 발생하게 하는 경우가 흔히 발생함

-> 지난 시간과 연관시키면 코딩 스타일 가이드를 어긴 것들을 체크리스트로 확인함 -> 변수의 이름 규칙, 디렉토리 체계 등

>>시간을 조금 더 시간을 효율적으로 사용할 수 있다.

->type checking으로 코드리뷰 단계에 오기 전에 미리미리 확인될 수 있게 함.

 

inspection checklist 예시

흔하게 발생할 수 있는 오류

>>Data faults

– 변수를 사용하기 전 반드시 초기 값을 설정할 것

변수 같이 이름을 가지고 있는 상수를 사용할 것

정해진 사이즈의 배열을 사용한다면 사이즈를 넘어가지 않게 사용해라

제한된 메모리를 사용했을 때 오버플로우가 발생하지 않게 해라

>>Control faults

- 루프같은 것들을 확인하는 것

>>Input/output faults

- 함수에 대한 입출력 파라미터에 관한 것

제대로 된 입력, 출력 파라미터를 사용하였는가?

exception handling

>>Interface faults

>>Storage management faults

- c++와 같은 프로그래밍 언어를 가지고 임베디드 프로그램을 구현할 때 가장 중시하는 체크리스트 -> 동적 메모리 할당을 할 때 -> 링크드 리스트와 같은 것들이 제대로 구현 되었는지, 할당이 제대로 되었는지, 사용한 메모리는 반드시 해제해라

>>Exception management faults

- 예외처리가 제대로 되어있는지

>>자동화된 도구를 사용을 해라

-> 비주얼 코드(NO. 오픈소스 프로그램)를 사용해야하는 이유 – 한 줄 한 줄 실행하는 인라인 트레이싱, 변수가 어떻게 바뀌었는지를 소스코드를 사용하여 확인이 가능함 -> 분석기능(lint 기능 – 실행하지 않아도 빨간줄 처리를 해서 미리 확인을 가능하게 해줌, 최초에 c언어에 적용됨, intellisense – 자동완성 시켜주는 것, 코드 포맷 잡아주는 기능 등등 -> 좋은 기능들을 많이 들어가 있음, 디버깅과 테스트를 통해 신뢰성을 높일 수도 있음, 심지어 refactoring 기능(가이드라인)도 있음 이 같은 것들이 제공됨.) -> 이러한 자동화된 도구들이 많음, 무료 제공이 됨.

 

 

Quality management and agile development -> 에이자일일 경우에는 어떻게 하나?

-> 문서기반 작업들이 형식적으로 정해져 있지 않음 -> 대부분 개발자의 역량, 회사가 소프트웨어를 개발할 때 어떻게 하라고 문화화하는 것이 중요하다.

-> 에이자일 기법과 plan-based 기법은 현 시대 개발자들에게 가장 중요한 기법들이다.

ISO 9001을 좋아하지 않음.

 

Shared good practice

-> 에이자일 기법에서는 개발자 각각이 본인 소프트웨어를 책임지고 퀄리티를 올린다라는 원칙이 있음

-> check-in 전 단계에서 반드시 코드리뷰를 진행함.(스스로도 하고 팀 단위로도 진행함, 지속적으로 함)

-> Never break the build – 통합하는 과정에서 자신이 진행하는 부분의 오류로 인해 망가지는 일이 있어서는 안 된다.

-> Fix problems when you see them – 본인이 짠 소스코드가 아닌 곳에서 에러를 발견했다면 개발자에게 알려서 수정하게 하지 말고 본인이 직접 손을 대서 수정을 진행해라

>>굉장히 active한 활동을 요구함

Reviews and agile methods

-> 리뷰프로세스는 에이자일 기법 안에 있다고 볼 수 있음 -> 그것이 결국은 개발자의 역량 더불어 문화적으로 존재하는 inspection이다.

-> 스크럼의 경우에는 리뷰미팅을 통해서 이러한 에러 사항들을 반드시 해결하고 XP인 경우에도 리뷰미팅이나 pair programming을 진행함.

>>남의 코드 또는 자신의 코드를 보아라

 

Pair programming

-> 에러를 줄이기 위한 테스트 기법

-> 2명이 똑같은 소스코드를 동시에 나란히 앉아서 짜는 것(한명이 타이핑하면 한명은 그것이 제대로 타이핑되었는지 확인하고 시간이 지나고 서로의 역할을 바꿔서 진행해보는 기법)

-> 상당히 효과가 좋다고 검증된 기법임.

 

Pair programming weaknesses

-> Mutual misunderstandings - 두 사람 모두 동시에 실수를 하는 경우

-> Pair reputation – 두 사람이 암묵적으로 손을 잡아서 눈을 감아버리거나 넘어가는 것(투명성 있게 진행해야함)

-> Working relationships – 본인이 짠 코드에 대해서 누군가 의견을 제시한다면 그것을 지적으로 받아들이지 말 것(긍정적으로 받아들여야 한다)

 

Agile QM(quality management) and large systems

-> 에이자일의 quality management나 큰 규모의 시스템에서 최소한의 문서는 발생할 수 있다.

-> 고객님 혹은 대규모 시스템 관리를 위해서 어쩔 수 없이 문서를 만들어야함(에이자일과 plan-based가 명백하게 구분되어 사용되는 것은 아님)

>>사고를 유연하게 해서 각각에 있는 장점들을 충분히 이해하고 이것들을 직간접적으로 경험한 후 둘을 혼합하여 나의 과제에 맞게 적용시키는 것이 중요하다.(열린 태도를 가져야함)

 

 

Software measurement -> 우리가 달성하고자 하는 이 프로젝트의 정성, 정량적인 지표를 정하는 것 -> 또한 그것을 추적 관리하는 것을 어떻게 할 것인지를 이야기함.

-> 수치를 다루는 것임

-> 정량적인 부분이라면 수치 자체에 의미를 둠

-> 정성적인 부분이라면 정성적인 부분을 정량적인 부분으로 체계화하는 과정이 중요함.

>>더불어 제대로 진행되고 있는지 비교나 검증함

>>표준이 정해져 있는 것도 규칙이 있는 것이 아님 본인 스스로가 프로젝트를 이해하고 정성적인 부분에서 최대한 의미가 있을 법한 정량적인 지표를 매핑해가는 과정을 고민이 필요함

 

Software metric -> 어떠한 항목들을 추출할지

-> 정성적인 부분에 대해서도 숫자들을 매핑해서 관리하는 체계를 만듦

-> 제품과 프로세스 자체에 대해서도 검증을 진행할 수 있음

-> 제품 자체에 대해서 개량화된 지표를 발굴함으로서 관리를 하려고 함

-> 프로세스에 대해서도 제대로 진행되고 있는지 알 수 있는 개량화된 수치들을 통해서 추적하고 관리하려함.

 

Types of process metric -> 계획을 세울 때 사람이 언제부터 언제까지 어떤 하드웨어 리소스를 사용할지 이야기함

-> 시간에 대해서도 측정을 진행함 – 예측과의 차이를 분석함(리소스 투입에 용이함)

-> 리소스 – 사람, 경비, 소프트웨어 자원에 대한 것도 얼마가 쓰이고 있는지 추적을 해간다면 앞으로 나올 것들에 대해서 예측이 가능함.

-> 이벤트의 수를 셈 – 코드 검증을 하면서 발생하는 문제들에 대해서도 기록을 남김(버그, 수정, 프로그램의 크기 등의 수치를 기록함)

>>프로그램에서 발생할 수 있는 수치들을 기록하고 항목화하고 로그함 -> 이러한 정보를 가지고 앞으로 더 잘 나아갈 수 있다고 생각함

>>일을 하는 시간, 자원, 특정 이벤트가 발생하는 것을 프로세스의 측면에서 저장하고 관리하고 예측하는데 사용할 수 있음

 

Predictor and control measurements

-> 프로세스에 관한 것을 개량화하여 이후에 우리가 관리하는 것에 활용이 가능하다.

-> 소프트웨어 제품 자체에 대한 항목들을 추출하여 개량화하여 앞으로에 반영할 수 있다.

 

Use of measurements -> 우리가 측정한 것들을 어떻게 사용할지

-> 정성적인 것들을 어떻게 개량할 것인지

cyclomatic complexity – 소프트웨어 부분에서 함수가 잘 짜여 있는지 복잡도가 높은지 낮은지를 판단하는 기준(그래프의 복잡도) -> 우리의 소프트웨어가 얼마나 복잡한 것인지 숫자를 매핑할 수 있음 -> 복잡성이 높아질수록 유지보수가 어렵다고 이야기 할 수 있다.

>>소프트웨어 상으로 수치화 할 수 있는 부분들을 최대한 수치화하는 것 -> 정성적인 부분에 매칭을 함 -> 이를 통해 좋은지 나쁜지를 판단함

-> 복잡성이 높다는 것은 오류발생이 높아 신뢰도가 떨어질 수 있고 읽기가 복잡할 수 있다.

>>수치화 할 수 없었던 정성적인 부분들과 수치화되어있는 개량적 부분들을 매칭하여 직간접적으로 정성적 부분이 좋은지 나쁜지 개선할 부분을 찾아감.

 

Metrics assumptions -> 수치화하여 도출을 함

-> 이렇게 수치화된 것들의 상관관계를 따져 논리적인 접근이 가능함

>>프로그램의 정성적인 부분과 개량한 것들의 매칭 예시 (54page)

-> 유전의 법칙이 너무 많이 내려간다면 – 재사용성이 높음을 말함.

-> 에러메시지가 많이 발생하는 것 – 신뢰성과 매칭됨.

>>최대한 논리적으로(정량적으로) 퀄리티를 유지 개선하려는 노력을 하고 있다고 할 수 있음

 

Problems with measurement in industry

-> 측정하는 것에 표준이 존재하지는 않음

-> 에이자일에서 이전의 것들을 무시하는 경향이 있어 좀 더 문제시 되고 있다.

-> 이러한 것들을 수치화하는 것에 추가적인 일이 증가한다고 볼 수 있음

>>측정 자체가 필요한지 안한지도 개발하는 회사에서 판단할 필요가 있음

>>경험적인 부분이 큼 -> 효율성, 재사용성, 유지보수 용의에 대한 부분을 경험해보는 것이 좋음

 

Product metrics

-> 제품의 퀄리티에 대한 접근 방식

>동적인 접근방식 – 측정할 수 있는 숫자들을 실행되는 상태에서 측정하는 것(실행 시 나오는 수치들) -> 더 작은 메모리, 더 작은 통신 속도, 오류없이 진행되는 신뢰성

-> 측정이 용이하다. -> 요청이 왔을 때 처리되는 시간

 

정적인 접근방식 – 소스코드 그 자체 레벨에서 볼 수 있는 것(소스코드를 읽고 고민하는 것)

-> 복잡도, 읽고 이해하는 것이 용이한지, 유지보수가 용이한지

-> 사람이 숫자를 세기보다는 논리적으로 판단해 보는 것

예시)

Fan-in/Fan-out(숫자를 세는 것 -> 함수 별로 숫자를 셈)

Length of code(코드의 길이를 세는 것 – 프로그램이 긴지 짧은지, 일반적으로 긴 것이 복잡하고 에러발생이 커진다)

Cyclomatic complexity(복잡도 – 복잡할 수 록 에러발생이 많아짐)

Length of identifiers(변수의 이름도 너무 짧거나 길면 문제가 있을 수 있음)

Depth of conditional nesting(조건문 안에 조건문이 들어가는 것이 읽는 것이 불편할 수 있다.)

Fog index(소프트웨어 안에 들어가 있는 워드의 수를 세서 인덱스를 만듦)

 

CK object-oriented metrics suite -> 객체 지향으로 만들어진 소프트웨어를 평가할 때 사용되는 지표(수치화)

Weighted methods per class (WMC) -> (클래스 안에 메서드가 얼마나 많이 존재하는가)

Depth of inheritance tree (DIT) -> (유전의 법칙이 얼마나 깊은지)

Number of children (NOC) -> (베이스 클래스로부터 얼마나 많은 서브클래스들이 만들어지는지)

Coupling between object classes (CBO) -> (클래스에서 서로를 부르는게 많아질수록 밀결합도가 높아짐)

Response for a class (RFC) -> (메소드를 한번 호출에 의하여 얼마나 많은 메서드들이 연거푸 발생해야하는지)

Lack of cohesion in methods (LCOM) -> (하나의 메서드에 대해서 얼마나 많은 스테이트 들이 연결되어 있는지)

>>이런 것들 중에 체계화 된 부분이 중요하다 -> 본인 스스로가 찾아가는 것이 중요함

 

Software component analysis -> 소프트웨어의 퀄리티를 측정했을 때 이것이 좋은 건지 않좋은 것인지 판다하는 것

-> 이전에 개발된 소프트웨어들에 대해 측정해보고 비교해 볼 수 있다.

-> 적용을 해봤는데 최근에 올수록 추치가 좋아진다면 소프트웨어의 퀄리티가 좋아지고 있다고 판다할 수 있다 -> 혹은 좋지 않다면 소프트웨어를 제대로 개발하고 있는지 퀄리티 측정이 잘 이루어진 것인지 판단해볼 필요가 있다.

>>이러한 측정들을 통해 개선을 진행할 수 있다.

 

Measurement ambiguity -> 정성적, 정량적 측정에 대한 이해가 있어야한다.

-> 제대로 된 프로그래머를 찾기가 어렵다.(스스로 자발적으로 하는 프로그래머)

-> 측정을 통해 개선작업이 이루어졌고 이후에

베타테스트에 들어가서 사용자에 의해 변화를 끊임없이 적용을 해도 계속해서 수정요청이 들어 온다면 소프트웨어를 잘 못 만들었거나 / 소프트웨어를 너무 잘 만들어서 사용자가 많아져 수정사항이 많아질 수 있다.

>>왜 그럴까에 대한 질문을 지속적으로 하고 사용자에 대한 이해가 필요하다.

 

 

Software analytics -> 자동화된 툴을 통해 얻어진 정보들을 빅데이터를 통해 분석하는 것

-> 정보들을 대량으로 모아서 빅데이터를 만드는 것

-> 실시간으로 사용자들이 겪는 문제점을 수집하고 오픈소스 소프트웨어를 분석하고 그에 대한 데이터들을 분석함 -> 이러한 것들을 퀄리티를 높이는데 사용함

 

Analytics tool use -> 분석 툴들을 만듦

사용이 쉬워야함

정보가 간결해야함

다양한 정보를 제공

사용자와 상호작용해서 원하는 정보를 얻을 수 있어야함.

>>이러한 툴들을 사용함

>>아직은 미숙하지만 이용할 가치가 있다고 생각함 -> 회사차원에서 관리가 어려울 수도 있음.

 

Key point

> 소프트웨어 품질 관리는 소프트웨어의 결함 개수가 적고, 소프트웨어의 유지관리성, 신뢰성, 휴대성 등의 요구 기준에 도달하는지 확인하는 것과 관련이 있습니다. 소프트웨어 표준은 '최선의 관행'을 식별하기 때문에 품질 보증에 중요하다. 소프트웨어를 개발할 때, 표준은 양질의 소프트웨어를 구축하기 위한 탄탄한 기반을 제공한다.

> 소프트웨어 공정 결과물의 검토는 품질 기준이 준수되고 있는지 점검하는 인력으로 구성되어 있습니다. 리뷰는 품질을 평가하기 위해 가장 널리 사용되는 기법이다.

>프로그램 점검 또는 동료 검토 시 작은 팀이 조직적으로 코드를 확인한다. 그들은 코드를 자세히 읽고 가능한 오류와 누락을 찾는다. 탐지된 문제는 코드 검토 회의에서 논의됩니다.

> 민첩한 품질 관리는 개발팀이 소프트웨어 품질 개선을 위해 협력하는 품질 문화 정착에 의존합니다.

> 소프트웨어 측정은 소프트웨어 및 소프트웨어 프로세스에 대한 정량적 데이터를 수집하는 데 사용할 수 있습니다.

>수집된 소프트웨어 측정기준의 값을 이용하여 제품 및 공정품질을 추론할 수 있습니다.

>제품 품질 지표는 품질 문제가 발생할 수 있는 비정상적인 구성 요소를 강조할 때 특히 유용합니다. 그런 다음 이러한 구성 요소를 더 자세히 분석해야 합니다.

> 소프트웨어 분석은 프로젝트 매니저와 개발자에게 통찰력을 제공할 수 있는 관계를 찾기 위해 대량의 소프트웨어 제품 및 프로세스 데이터를 자동으로 분석하는 것입니다.