L21L22-Quality management (Ch24)

Topics covered 다루는 주제

• Software quality 소프트웨어 품질

• Software standards 소프트웨어 표준

• Reviews and inspections 리뷰 및 검사

• Quality management and agile development 품질 관리 및 애자일 개발

• Software measurement 소프트웨어 측정

Software quality management 소프트웨어 품질 관리

• Concerned with ensuring that the required level of quality is achieved in a software product. 소프트웨어 제품에서 요구되는 수준의 품질이 달성되도록 보장하는 것을 목표로 한다.

• QM principal concerns: 품질 관리의 주요 관심사:

  • At the organizational level,조직 차원에서

    • quality management is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software. 품질 관리는 고품질 소프트웨어를 개발하기 위한 조직 프로세스 및 표준의 틀을 수립하는 데 초점을 맞춘다.

  • At the project level, 프로젝트 차원에서,

    • quality management involves the application of specific quality processes and checking that these planned processes have been followed. 품질 관리는 특정 품질 프로세스의 적용과, 계획된 프로세스가 준수되고 있는지를 확인한다.

    • quality management is also concerned with establishing a quality plan for a project. The quality plan should set out the quality goals for the project and define what processes and standards are to be used. 또한 품질 관리는 프로젝트의 품질 계획 수립을 포함한다. 품질 계획은 품질 목표를 명시하고, 사용할 프로세스와 표준을 정의해야 한다.

Quality management and software development 품질 관리와 소프트웨어 개발

• 둘은 뗄 수 없는 개념이다.

• 코드리뷰, 테스트 없이 릴리즈 하면 버그가 많아진다.

• 따라서 개발 프로세스의 품질, 결과물의 품질을 고려해야 한다.

Quality planning 품질 계획

• A quality plan sets out the desired product qualities and how these are assessed and defines the most significant quality attributes. 품질 계획은 원하는 제품 품질과 이를 평가하는 방법, 그리고 가장 중요한 품질 속성을 정의한다.

• The quality plan should define the quality assessment process. 품질 계획은 품질 평가 프로세스를 정의해야 한다.

• It should set out which organisational standards should be applied and, where necessary, define new standards to be used. 조직 표준을 명시하고, 필요한 경우 새로운 표준을 정의해야 한다.

Quality plans 품질 계획

• Quality plan structure 품질 계획의 구성

  • Product introduction: A description of the product, its intended market, and the quality expectation.제품 소개: 제품 설명, 대상 시장, 품질 기대치

  • Product plans: The critical release dates and responsibilities. Plans for distribution and product servicing 제품 계획: 중요한 릴리스 일정과 담당자, 배포 및 서비스 계획

  • Process descriptions: The development process and service processes and standards 프로세스 설명: 개발 및 서비스 프로세스와 표준

  • Quality goals: The quality goals and plans including an identification and justification of critical product quality attributes. 품질 목표: 중요한 품질 속성의 정의와 근거를 포함한 목표 및 계획

  • Risks and risk management: The key risks that might affect product quality and the required actions for addressing the risks. 위험 및 위험 관리: 제품 품질에 영향을 미칠 주요 위험과 이를 해결하기 위한 조치

• Quality plans should be short, succinct documents 품질 계획은 간결하고 명료한 문서여야 한다.

  • If they are too long, no-one will read them. 너무 길면 아무도 읽지 않기 때문이다.

[2] Software quality 소프트웨어 품질

Software quality 소프트웨어 품질

• Quality, simplistically, means that a product should meet its specification. 품질은 단순히 제품이 명세를 충족해야 함을 의미한다.

• This is problematical for software systems 하지만 소프트웨어 시스템에서는 문제가 발생한다.

  • There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.); 고객의 품질 요구사항(효율성, 신뢰성 등)과 개발자의 품질 요구사항(유지보수성, 재사용성 등) 간의 긴장이 존재한다.

  • Some quality requirements are difficult to specify in an unambiguous way; 일부 품질 요구사항은 명확하게 명세하기 어렵다.

  • Software specifications are usually incomplete and often inconsistent.소프트웨어 명세는 불완전하거나 일관되지 않은 경우가 많다.

• The assessment of software quality is subjective! 소프 트웨어 품질 평가는 주관적이다!

• The QM team should decide the acceptable level of quality to be achieved! 품질 관리팀이 달성해야 할 수용 가능한 품질 수준을 결정해야 한다!

Software is fit for its intended purpose? (Example questions) 소프트웨어가 의도한 목적에 적합한가? (예시 질문)

• 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? 개발 과정에서 프로그래밍 및 문서 표준이 지켜졌는가?

Software quality attributes 소프트웨어 품질 속성

• 신뢰성

• 성능

• 유지보수성

• 이해가능성

• 이식성

Quality conflicts 품질 충돌

• It is not possible for any system to be optimized for all of these attributes – for example, improving robustness may lead to loss of performance. 모든 품질 속성을 최적화하는 것은 불가능하다. 예: 견고성을 향상하면 성능이 저하될 수 있다.

• Therefore, the quality plan should define the most important quality attributes for the software that is being developed. 따라서 품질 계획은 개발 중인 소프트웨어의 가장 중요한 품질 속성을 정의해야 한다.

• The plan should also include a definition of the quality assessment process, an agreed way of assessing whether some quality, such as maintainability or robustness, is present in the product. 또한 유지보수성, 견고성 등 품질이 제품에 존재하는지 평가하는 프로세스를 정의해야 한다.

Process and product quality (process affects product!) 프로세스와 제품 품질 (프로세스가 제품에 영향!)

• The quality of a developed product is influenced by the quality of the production process. 개발된 제품의 품질은 개발 프로세스의 품질에 영향을 받는다.

• Some 'product quality' attributes are hard to assess. 일부 제품 품질 속성은 평가하기 어렵다.

• However, there is a very complex and poorly understood relationship between software processes and product quality. 하지만 소프트웨어 프로세스와 제품 품질 간의 관계는 복잡하고 명확히 이해되지 않는 경우가 많다.

• The application of individual skills and experience (process factors) is particularly important in software development; 소프트웨어 개발에서 개인의 기술과 경험(프로세스 요인)이 특히 중요하다.

• External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality. 애플리케이션의 참신함, 개발 일정 단축 등 외부 요인이 제품 품질을 저해할 수 있다.

Process-based quality (Traditional S/W QM) 프로세스 기반 품질 (전통적 소프트웨어 품질 관리)

• Like manufacturing systems 제조 시스템과 유사

• Reliability and maintainability? 신뢰성 및 유지보수성?

Quality culture 품질 문화

• Quality managers should aim to develop a ‘quality culture’ where everyone responsible for software development is committed to achieving a high level of product quality. 품질 관리자는 소프트웨어 개발자 모두가 높은 수준의 품질 달성에 전념하도록 ‘품질 문화’를 형성해야 한다.

• They should encourage teams to take responsibility for the quality of their work and to develop new approaches to quality improvement. 팀이 자신의 작업 품질에 책임을 지고, 새로운 품질 개선 방안을 개발하도록 독려해야 한다.

• They should support people who are interested in the intangible aspects of quality and encourage professional behavior in all team members. 품질의 무형적 측면에 관심 있는 사람을 지원하고, 모든 팀원이 전문성을 갖추도록 격려해야 한다.

[3] Software standards 소프트웨어 표준

Software standards 소프트웨어 표준

• Standards define the required attributes of a product or process. They play an important role in quality management. 표준은 제품이나 프로세스에서 요구되는 속성을 정의한다. 이는 품질 관리에서 중요한 역할을 한다.

  • 코드 스타일, 문서 형태 등

• Standards may be international, national, organizational or project standards. 표준은 국제적, 국가적, 조직적, 프로젝트 단위로 나눌 수 있다.

https://users.encs.concordia.ca/\\\\~eceweb/capstone/Software/index.htm (예시 링크)

Importance of standards 표준의 중요성

• Encapsulation of best practice: avoids repetition of past mistakes. 모범 사례를 캡슐화: 과거의 실수를 반복하지 않도록 한다.

• They are a framework for defining what quality means in a particular setting i.e. that organization’s view of quality. 특정 환경에서 품질이란 무엇인가를 정의하는 틀이다. 즉, 그 조직의 품질 관점이다.

• They provide continuity: new staff can understand the organisation by understanding the standards that are used.
  연속성을 보장한다: 신규 직원은 표준을 통해 조직을 이해할 수 있다.

Product and process standards 제품 및 프로세스 표준

• Product standards제품 표준

  • Apply to the software product being developed. They include document standards, such as the structure of requirements documents, documentation standards, such as a standard comment header for an object class definition, and coding standards, which define how a programming language should be used. 개발 중인 소프트웨어 제품에 적용된다. 요구사항 문서 구조, 객체 클래스 주석 헤더 등의 문서 표준과, 프로그래밍 언어 사용 방식을 정의하는 코딩 표준이 포함된다.

  • 산출물이 어떤 형태여야 하는지

• Process standards프로세스 표준

  • These define the processes that should be followed during software development. Process standards may include definitions of specification, design and validation processes, process support tools and a description of the documents that should be written during these processes. 소프트웨어 개발 중 따라야 할 프로세스를 정의한다. 명세, 설계, 검증 프로세스 정의와, 프로세스 지원 도구 및 작성해야 할 문서 설명 등이 포함된다.

Product and process standards 제품 및 프로세스 표준 예시

Problems with standards 표준의 문제점

• 너무 형식적이거나 문서 중심적

• 표준이 많거나 외우기 어려움

• 일괄 적용하려 하다보니 비효율적인

• 자율성을 제한해서 거부이이 됌.

Standards development to convince engineers 개발자 설득을 위한 표준 개발

• Involve software engineers in the selection of product standards. Engineers should understand the rationale underlying a standard. Thus, the engineers are more likely to be committed to these standards. 엔지니어가 제품 표준 선정에 참여하도록 하고, 표준의 배경을 이해하도록 한다. 이를 통해 표준 준수 의지가 높아진다.

• Review and modify standards regularly to reflect changing technologies. 기술 변화에 따라 표준을 정기적으로 검토 및 수정한다.

• Detailed standards should have specialized tool support. 상세 표준에는 전문화된 도구 지원이 필요하다.

ISO 9001 standards framework ISO 9001 표준 프레임워크

• An international set of standards that can be used as a basis for developing quality management systems (QMS). 품질 관리 시스템(QMS) 개발의 기초가 되는 국제 표준 집합이다.

• ISO 9001, the most general of these standards, applies to organizations that design, develop and maintain products, including software. ISO 9001은 소프트웨어를 포함한 제품 설계, 개발, 유지보수 조직에 적용된다.

• The ISO 9001 standard is a framework for developing software standards. ISO 9001은 소프트웨어 표준을 개발하는 틀을 제공한다.

  • It sets out general quality principles, describes quality processes in general and lays out the organizational standards and procedures that should be defined. These should be documented in an organizational quality manual. 일반적인 품질 원칙을 명시하고, 품질 프로세스를 설명하며, 조직 표준과 절차를 정의한다. 이는 조직 품질 매뉴얼로 문서화되어야 한다.

ISO 9001 core processes ISO 9001 핵심 프로세스

• 품질 목표 설정

• 고객 요구사항 수집

• 설계 및 활동

• 외부, 내부

Relationship between ISO 9001 and quality management ISO 9001과 품질 관리의 관계

ISO 9001 certification ISO 9001 인증

• Quality standards and procedures should be documented in an organisational quality manual. 품질 표준과 절차는 조직 품질 매뉴얼에 문서화되어야 한다.

• An external body may certify that an organisation’s quality manual conforms to ISO 9000 standards. 외부 기관이 조직의 품질 매뉴얼이 ISO 9000 표준에 부합함을 인증할 수 있다.

• Some customers require suppliers to be ISO 9000 certified although the need for flexibility here is increasingly recognised.일부 고객은 ISO 9000 인증을 요구하지만, 유연성의 필요성도 점차 인정되고 있다.

• Do ISO 9001 companies lead to the high-quality software products? ISO 9001 인증 기업이 정말로 고품질 소프트웨어를 생산할까?

Software quality and ISO 9001 소프트웨어 품질과 ISO 9001

• The ISO 9001 certification is inadequate (author's view) because it just defines quality to be the conformance to standards. ISO 9001 인증은 표준 준수만을 품질로 정의하기 때문에 불충분하다 (저자 의견).

• It takes no account of quality as experienced by users of the software. 사용자가 실제로 경험하는 품질을 고려하지 않는다.

  • For example, a company could define test coverage standards specifying that all methods in objects must be called at least once. 예: 모든 메서드가 최소 한 번 호출되도록 테스트 범위 표준을 정의할 수 있다.

  • Unfortunately, this standard can be met by incomplete software testing that does not include tests with different method parameters. So long as the defined testing procedures are followed and test records maintained, the company could be ISO 9001 certified. 그러나 이 표준은 서로 다른 매개변수 테스트 없이도 충족될 수 있다. 정해진 테스트 절차와 기록만 있으면 ISO 9001 인증을 받을 수 있다.

• 품질 시스템 설계에 도움 되지만, 실사용자까지는 가지 않는다.

[4] Reviews and inspections [4] 리뷰 및 검사

Reviews and inspections 리뷰 및 검사

• A group examines part or all of a process or system and its documentation to find potential problems. 팀이 프로세스나 시스템의 일부 혹은 전체와 그 문서를 검토하여 잠재적 문제를 발견한다.

• Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. 리뷰에서 소프트웨어나 문서가 ‘서명 승인’될 수 있으며, 이는 다음 개발 단계로의 진행을 관리자가 승인했음을 의미한다.

• There are different types of review with different objectives 리뷰 유형은 목적에 따라 다양하다.

  • Inspections for defect removal (product); 결함 제거를 위한 검사(제품);

  • Reviews for progress assessment (product and process); 진행 상황 평가를 위한 리뷰(제품 및 프로세스);

  • Quality reviews (product and standards). 품질 검토(제품 및 표준).

Quality reviews 품질 리뷰

• Several people carefully examine the software and its associated documentation, looking for potential problems and non-conformance with standards. 여러 명이 소프트웨어와 관련 문서를 꼼꼼히 검토하며, 잠재적 문제와 표준 불일치를 찾는다.

• Code, designs, specifications, test plans, standards, etc. can all be reviewed. 코드, 설계, 명세서, 테스트 계획, 표준 등 모두 리뷰 대상이다.

• Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. 소프트웨어나 문서가 ‘서명 승인’되면, 다음 개발 단계로의 진행이 관리자로부터 승인되었음을 나타낸다.

Phases in the review process 리뷰 프로세스 단계

• Pre-review activities 사전 검토 활동

  • Pre-review activities are concerned with review planning and review preparation 검토 계획 및 검토 준비를 다룬다.

• The review meeting 리뷰 회의

  • During the review meeting, an author of the document or program being reviewed should ‘walk through’ the document with the review team. (relatively short-two hours at most) 리뷰 회의 중, 문서 또는 프로그램 작성자가 리뷰 팀에게 내용을 직접 설명한다. (보통 2시간 이내)

• Post-review activities 사후 검토 활동

  • These address the problems and issues that have been raised during the review meeting. 회의 중 제기된 문제 및 이슈를 다룬다.

The software review process 소프트웨어 리뷰 프로세스

Distributed reviews 분산 리뷰

• The processes suggested for reviews assume that the review team has a face-to-face meeting to discuss the software or documents that they are reviewing. 리뷰 프로세스는 리뷰 팀이 대면 회의를 통해 소프트웨어나 문서를 논의한다고 가정한다.

• However, project teams are now often distributed, sometimes across countries or continents, so it is impractical for team members to meet face to face. 하지만 오늘날 프로젝트 팀은 여러 나라나 대륙에 분산되어 있어, 대면 회의가 어렵다.

• Remote reviewing can be supported using shared documents where each review team member can annotate the document with their comments. 원격 리뷰는 공유 문서를 사용해 각 팀원이 주석을 추가하는 방식으로 지원된다.

Program inspections 프로그램 검사

• These are peer reviews where engineers examine the source of a system with the aim of discovering anomalies and defects. 동료 검토로, 엔지니어들이 시스템 소스를 검토해 이상과 결함을 찾는다.

• Inspections do not require execution of a system so may be used before implementation. 검사는 시스템 실행 없이 진행되며, 구현 전에도 수행할 수 있다.

• They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.). 요구사항, 설계, 구성 데이터, 테스트 데이터 등 모든 형태의 시스템 표현에 적용될 수 있다.

• They have been shown to be an effective technique for discovering program errors. 프로그램 오류를 찾는 데 효과적인 기법으로 입증되었다.

Inspection checklists 검사 체크리스트

• Checklist of common errors should be used to drive the inspection. 흔한 오류를 정리한 체크리스트를 사용해 검사를 진행해야 한다.

• Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language. 오류 체크리스트는 프로그래밍 언어에 따라 달라지며, 해당 언어에서 발생하기 쉬운 오류를 반영한다.

• In general, the 'weaker' the type checking, the larger the checklist. 일반적으로 타입 검사가 약할수록 체크리스트는 길어진다.

  • Examples: Initialisation, Constant naming, loop termination, array bounds, etc. 예: 초기화, 상수 명명, 반복문 종료, 배열 경계 등

An inspection checklist (a) 검사 체크리스트 (예시)

[5] Quality management and agile development 품질 관리와 애자일 개발

Quality management and agile development 품질 관리와 애자일 개발

• Quality management in agile development is informal rather than document-based. 애자일 개발에서 품질 관리는 문서 기반보다는 비형식적이다.

• It relies on establishing a quality culture, where all team members feel responsible for software quality and take actions to ensure that quality is maintained. 모든 팀원이 소프트웨어 품질에 책임감을 느끼고 품질 유지를 위한 조치를 취하는 품질 문화를 구축하는 데 의존한다.-> 팀원 모두가 품질 관리자처럼 행동한다.

• The agile community is fundamentally opposed to what it sees as the bureaucratic overheads of standards-based approaches and quality processes as embodied in ISO 9001. 애자일 커뮤니티는 ISO 9001 같은 표준 기반 접근과 품질 프로세스를 관료적이라고 보고 근본적으로 반대한다.

Shared good practice 공유되는 좋은 실천 관행

• Check before check-in체크인 전에 확인

  • Programmers are responsible for organizing their own code reviews with other team members before the code is checked in to the build system. 프로그래머는 빌드 시스템에 코드를 체크인하기 전에 다른 팀원과코드 리뷰를 주도해야 한다.

• Never break the build빌드를 깨뜨리지 않는다

  • Team members should not check in code that causes the system to fail. Developers have to test their code changes against the whole system and be confident that these work as expected. 팀원은 시스템 실패를 초래하는 코드를 체크인해서는 안 된다. 개발자는 변경 사항을 전체 시스템에서 테스트하고, 예상대로 동작함을 확신해야 한다.

• Fix problems when you see them발견하면 바로 고친다

  • If a programmer discovers problems or obscurities in code developed by someone else, they can fix these directly rather than referring them back to the original developer.
    다른 사람이 개발한 코드의 문제나 모호점을 발견하면, 원 작성자에게 되돌리기보다는 직접 수정할 수 있다.

Reviews and agile methods 리뷰와 애자일 방법

• The review process in agile software development is usually informal. 애자일 개발에서 리뷰 프로세스는 보통 비형식적이다.

• In Scrum, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed. 스크럼에서는 각 이터레이션 완료 후 스프린트 리뷰 회의를 통해 품질 문제를 논의한다.

• In Extreme Programming, pair programming ensures that code is constantly being examined and reviewed by another team member. 익스트림 프로그래밍에서는 페어 프로그래밍을 통해 코드가 항상 다른 팀원의 검토를 받도록 한다.

Pair programming 페어 프로그래밍

• This is an approach where 2 people are responsible for code development and work together to achieve this. 두 사람이 함께 코드 개발을 담당하고 공동으로 작업하는 접근 방식이다.

• Code developed by an individual is therefore constantly being examined and reviewed by another team member. 개인이 개발한 코드는 항상 다른 팀원의 검토를 받는다.

• Pair programming leads to a deep knowledge of a program, as both programmers have to understand the program in detail to continue development. 두 사람이 모두 프로그램을 상세히 이해해야 개발이 가능하므로, 깊은 프로그램 이해도를 갖게 된다.

• This depth of knowledge is difficult to achieve in inspection processes and pair programming can find bugs that would not be discovered in formal inspections. 이러한 깊이는 형식적 검토로는 얻기 어렵고, 페어 프로그래밍을 통해 공식 검사로는 발견되지 않을 버그를 찾을 수 있다.

Pair programming weaknesses 페어 프로그래밍의 약점

• Mutual misunderstandings상호 오해

  • Both members of a pair may make the same mistake in understanding the system requirements. Discussions may reinforce these errors. 두 사람이 시스템 요구사항을 잘못 이해하고, 논의를 통해 그 오해가 강화될 수 있다.

• Pair reputation페어의 명성

  • Pairs may be reluctant to look for errors because they do not want to slow down the progress of the project. 프로젝트 진행을 늦추고 싶지 않아 오류를 찾으려 하지 않을 수 있다.

• Working relationships협력 관계

  • The pair’s ability to discover defects is likely to be compromised by their close working relationship that often leads to reluctance to criticize work partners. 협력 관계가 가까워지면 서로의 작업을 비판하는 것을 주저하게 되어, 결함 발견 능력이 저하될 수 있다.

Agile QM and large systems 애자일 품질 관리와 대규모 시스템

• When a large system is being developed for an external customer, agile approaches to quality management with minimal documentation may be impractical.
  대규모 시스템을 외부 고객을 위해 개발할 때, 문서가 거의 없는 애자일 품질 관리는 비현실적일 수 있다.

  • If the customer is a large company, it may have its own quality management processes and may expect the software development company to report on progress in a way that is compatible with them. 대형 고객사의 경우 자체 품질 관리 프로세스를 갖추고, 이에 맞는 방식으로 개발사의 진행 상황 보고를 기대한다.

  • Where there are several geographically distributed teams involved in development, perhaps from different companies, then informal communications may be impractical. 여러 지역, 다른 회사 팀들이 참여할 경우, 비공식 커뮤니케이션은 어려워질 수 있다.

  • For long-lifetime systems, the team involved in development will change. Without documentation, new team members may find it impossible to understand development. 장수명 시스템에서는 개발팀이 바뀌며, 문서가 없으면 신규 인원이 시스템을 이해하기 어렵다.

[6] Software measurement 소프트웨어 측정

Software measurement 소프트웨어 측정

• Software measurement is concerned with deriving a numeric value for a software quality attribute (i.e., complexity and reliability) of a software product or process. 소프트웨어 측정은 소프트웨어 제품이나 프로세스의 품질 속성(예: 복잡도, 신뢰성)을 수치로 산출하는 데 초점을 맞춘다.

  • This can conclude about the quality of software or 이는 소프트웨어 품질에 대한 결론을 내리거나

  • assess the effectiveness of processes, tools, and methods. 프로세스, 도구, 방법의 효과를 평가할 수 있다.

• Although some companies have introduced measurement programmes, most organisations still don’t make systematic use of software measurement. 일부 기업은 측정 프로그램을 도입했지만, 대부분의 조직은 아직 체계적으로 활용하지 않는다.

• There are few established standards in this area. 이 분야에 확립된 표준은 거의 없다.

Software metric 소프트웨어 메트릭

• Any type of measurement which relates to a software system, process or related documentation 소프트웨어 시스템, 프로세스 또는 문서와 관련된 모든 유형의 측정값

  • Lines of code in a program, the Fog index (readability), number of person-days required to develop a component. 예: 프로그램 코드 라인 수, Fog 지수(가독성), 컴포넌트 개발 소요 인원일 수 등

• Allow the software and the software process to be quantified. 소프트웨어와 프로세스를 정량화할 수 있다.

• Product metrics vs. Process metrics제품 메트릭 vs. 프로세스 메트릭

  • May be used to predict product attributes or to control the software process. 제품 속성 예측이나 소프트웨어 프로세스 통제에 활용할 수 있다.

  • Product metrics can be used for general predictions or to identify anomalous components. (e.g., effort estimation, defect prediction, risk prediction, etc.) 제품 메트릭은 일반 예측이나 이상 컴포넌트 식별(예: 작업량 추정, 결함 예측, 위험 예측 등)에 쓰인다.

Types of process metric 프로세스 메트릭 유형

• The time taken for a particular process to be completed특정 프로세스 완료까지 걸린 시간

  • This can be the total time devoted to the process, calendar time, the time spent on the process by particular engineers, and so on. 예: 프로세스 전체 소요 시간, 캘린더 상 시간, 특정 엔지니어가 투입한 시간 등

• The resources required for a particular process특정 프로세스에 필요한 자원

  • Resources might include total effort in person-days, travel costs or computer resources. 예: 총 인력 투입일, 출장 비용, 컴퓨터 자원 등

• The number of occurrences of a particular event특정 이벤트 발생 횟수

  • Examples: number of defects discovered during code inspection, number of requirements changes, number of bug reports, average lines of code modified, etc. 예: 코드 검사 중 발견된 결함 수, 요구사항 변경 요청 수, 버그 보고 수, 수정된 평균 코드 라인 수 등

Example metrics: http://lifove.github.io/mim/https://www.slideshare.net/s-mueller/using-biometrics-to-predict-code-quality-online/18 (예시 링크)

Predictor and control measurements 예측 및 통제 측정값

Use of measurements (metrics) 측정값(메트릭)의 활용

• To assign a value to system quality attributes 시스템 품질 속성에 값을 부여

  • By measuring the characteristics of system components, such as their cyclomatic complexity, and then aggregating these measurements, you can assess system quality attributes, such as maintainability. 예: 컴포넌트의 사이클로매틱 복잡도 등을 측정·집계하여 유지보수성 같은 품질 속성을 평가할 수 있다.

• To identify the system components whose quality is sub-standard or defective 품질이 낮거나 결함 있는 컴포넌트 식별

  • Measurements can identify individual components with characteristics that deviate from the norm. For example, you can measure components to discover those with the highest complexity. These are most likely to contain bugs because the complexity makes them harder to understand. 표준에서 벗어난 컴포넌트를 식별할 수 있다. 예: 복잡도가 가장 높은 컴포넌트를 찾아 버그 가능성이 높은지 확인

External vs. internal software attributes 외부 vs. 내부 소프트웨어 속성

• External attributes: How developers and users experience the software? 외부 속성: 개발자와 사용자가 소프트웨어를 어떻게 경험하는지?

  • e.g., maintainability, understandability, usability, etc. 예: 유지보수성, 이해 가능성, 사용성 등

  • Not objective 객관적이지 않음

• Internal attributes: Objective attributes from products 내부 속성: 제품으로부터 도출되는 객관적 속성

  • e.g., size and complexity of products. 예: 클래스 수, 제품의 크기, 복잡도 등

Relationships between internal and external software 내부 및 외부 소프트웨어 속성 간 관계

Problems with measurement in industry 산업 현장의 소프트웨어 측정 문제

• It is impossible to quantify the return on investment of introducing an organizational metrics program. 조직의 메트릭 프로그램 도입에 대한 투자 수익률을 정량화하기는 불가능하다.

• There are no standards for software metrics or standardized processes for measurement and analysis. 소프트웨어 메트릭이나 측정/분석을 위한 표준화된 프로세스가 없다.

• In many companies, software processes are not standardized and are poorly defined and controlled. 많은 회사에서 소프트웨어 프로세스가 표준화되어 있지 않고, 정의나 통제가 미흡하다.

• Most work on software measurement has focused on code-based metrics and plan-driven development processes. However, more and more software is now developed by configuring ERP systems or COTS. 소프트웨어 측정은 주로 코드 기반 메트릭과 계획 주도형 개발 프로세스에 초점을 맞췄다. 그러나 현재는 ERP 시스템이나 COTS 구성으로 개발되는 소프트웨어가 많아졌다.

• Introducing measurement adds additional overhead to processes. 측정 도입은 프로세스에 추가적인 오버헤드를 발생시킨다.

Empirical software engineering 경험적 소프트웨어 공학

• Software measurement and metrics are the basis of empirical software engineering. 소프트웨어 측정과 메트릭은 경험적 소프트웨어 공학의 기초이다.

• This is a research area in which experiments on software systems and the collection of data about real projects has been used to form and validate hypotheses about software engineering methods and techniques. 실제 프로젝트 데이터를 수집·분석하여 소프트웨어 공학 기법과 방법론에 대한 가설을 세우고 검증하는 연구 분야이다.

• Research on empirical software engineering, this has not had a significant impact on software engineering practice. 경험적 소프트웨어 공학 연구는 소프트웨어 개발 실무에 큰 영향을 미치지 못했다.

• It is difficult to relate generic research to an individual project that is different from the research study. 일반적인 연구 결과를 개별 프로젝트에 적용하기는 어렵다.

Product metrics 제품 메트릭

• A quality metric should be a predictor of product quality. 품질 메트릭은 제품 품질을 예측할 수 있어야 한다.

• Classes of product metric 제품 메트릭의 분류

  • Dynamic metrics which are collected by measurements made of a program in execution; 실행 중인 프로그램에서 수집되는 동적 메트릭

  • Static metrics which are collected by measurements made of the system representations; 시스템 표현에서 수집되는 정적 메트릭

  • Dynamic metrics help assess efficiency and reliability 동적 메트릭은 효율성 및 신뢰성 평가에 도움된다.

  • Static metrics help assess complexity, understandability and maintainability. 정적 메트릭은 복잡성, 이해도, 유지보수성 평가에 도움된다.

Some tools: https://www.monperrus.net/martin/java-metrics (예시 도구)

Dynamic and static metrics 동적 메트릭과 정적 메트릭

• Dynamic metrics are closely related to software quality attributes 동적 메트릭은 소프트웨어 품질 속성과 밀접히 연관된다.

  • It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute). 시스템 응답 시간(성능)이나 실패 횟수(신뢰성)를 측정하는 것은 비교적 쉽다.

• Static metrics have an indirect relationship with quality attributes 정적 메트릭은 품질 속성과 간접적으로 관련된다.

  • You need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability. 메트릭과 복잡성·이해도·유지보수성 같은 속성 간의 관계를 추론해야 한다.

Static software product metrics 정적 소프트웨어 제품 메트릭

Example: cyclomatic metric 예: 사이클로매틱 복잡도

• V(G) = #edge - #node + 2 사이클로매틱 복잡도 계산식

The CK object-oriented metrics suite CK 객체지향 메트릭

Software component analysis 소프트웨어 컴포넌트 분석

• System component can be analyzed separately using a range of metrics. 시스템 컴포넌트를 다양한 메트릭으로 개별 분석할 수 있다.

• The values of these metrics may then compared for different components and, perhaps, with historical measurement data collected on previous projects. >> Change metrics (process metrics) 컴포넌트별 측정값을 비교하거나, 이전 프로젝트의 측정 데이터와 비교할 수 있다. (변경 메트릭: 프로세스 메트릭)

• Anomalous measurements, which deviate significantly from the norm, may imply that there are problems with the quality of these components.기준에서 크게 벗어난 이상 측정값은 해당 컴포넌트의 품질 문제를 암시할 수 있다.

The process of product measurement 제품 측정 프로세스

Measurement ambiguity 측정의 모호성

• When you collect quantitative data about software and software processes, you have to analyze that data to understand its meaning. 소프트웨어 및 프로세스 데이터를 수집하면, 의미를 파악하기 위해 분석해야 한다.

• It is easy to misinterpret data and to make inferences that are incorrect. 데이터를 오해하거나 잘못된 추론을 하기가 쉽다.

• You cannot simply look at the data on its own. You must also consider the context where the data is collected. 데이터만 보지 말고, 데이터가 수집된 맥락도 고려해야 한다.

Measurement surprises 측정의 의외성

• Reducing the number of faults in a program leads to an increased number of help desk calls 프로그램 결함을 줄이면 헬프데스크 문의가 늘어날 수 있다.

  • The program is now thought of as more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase;프로그램이 더 신뢰할 수 있다고 인식되면서 사용자층이 다양해지고 문의 총량은 늘어날 수 있다.

  • A more reliable system is used in a different way from a system where users work around the faults. This leads to more help desk calls. 더 신뢰성 있는 시스템은 기존 결함을 우회하던 방식과 달라져 헬프데스크 문의가 증가할 수 있다.

Software analytics 소프트웨어 분석

• Software analytics is analytics on software data for managers and software engineers with the aim of empowering software development individuals and teams to gain and share insight from their data to make better decisions.소프트웨어 분석은 관리자가 데이터를 기반으로 통찰을 얻고 팀이 더 나은 결정을 내리도록 돕기 위한 소프트웨어 데이터 분석이다.

• Mining Software repositories소프트웨어 저장소 마이닝

Software analytics enablers소프트웨어 분석 활성화 요인

• The automated collection of user data by software product companies when their product is used.소프트웨어 제품 회사가 자사 제품이 사용될 때 사용자 데이터를 자동으로 수집하는 것.

  • If the software fails, information about the failure and the state of the system can be sent over the Internet from the user’s computer to servers run by the product developer.소프트웨어가 실패할 경우, 실패 정보와 시스템 상태가 사용자 컴퓨터에서 제품 개발자의 서버로 인터넷을 통해 전송될 수 있다.

• The use of open source software available on platforms such as Sourceforge and GitHub and open source repositories of software engineering data.Sourceforge, GitHub 같은 플랫폼과 소프트웨어 공학 데이터를 담은 오픈 소스 저장소에서 제공되는 오픈 소스 소프트웨어의 활용.

  • The source code of open source software is available for automated analysis and this can sometimes be linked with data in the open source repository.오픈 소스 소프트웨어의 소스 코드는 자동 분석에 사용할 수 있으며, 때로는 오픈 소스 저장소의 데이터와 연결될 수 있다.

Analytics tool use분석 도구의 사용

• Tools should be easy to use as managers are unlikely to have experience with analysis.관리자들은 분석 경험이 없을 가능성이 높기 때문에 도구는 사용하기 쉬워야 한다.

• Tools should run quickly and produce concise outputs rather than large volumes of information.도구는 빠르게 실행되어야 하며, 방대한 정보보다는 간결한 결과를 출력해야 한다.

• Tools should make many measurements using as many parameters as possible. It is impossible to predict in advance what insights might emerge.도구는 가능한 많은 파라미터를 활용하여 다양한 측정을 해야 한다. 어떤 인사이트가 나올지는 미리 예측할 수 없다.

• Tools should be interactive and allow managers and developers to explore the analyses.도구는 상호작용형이어야 하며, 관리자와 개발자가 분석을 탐색할 수 있도록 해야 한다.

Status of software analytics소프트웨어 분석의 현황

• Software analytics is still immature and it is too early to say what effect it will have.소프트웨어 분석은 아직 미성숙하며, 어떤 영향을 줄지는 말하기 이르다.

• Not only are there general problems of ‘big data’ processing, our knowledge depends on collected data from large companies.'빅데이터' 처리의 일반적인 문제뿐 아니라, 현재의 지식은 대기업에서 수집한 데이터에 의존한다.

  • This is primarily from software products and it is unclear if the tools and techniques that are appropriate for products can also be used with custom software.이는 주로 소프트웨어 제품에서 비롯된 것으로, 제품에 적합한 도구와 기법이 맞춤형 소프트웨어에도 적용될 수 있을지는 불분명하다.

• Small companies are unlikely to invest in the data collection systems that are required for automated analysis so may not be able to use software analytics.소규모 기업들은 자동 분석을 위한 데이터 수집 시스템에 투자하지 않을 가능성이 높아 소프트웨어 분석을 사용하지 못할 수 있다.

Key points핵심 요점

• Software quality management is concerned with ensuring that software has a low number of defects and that it reaches the required standards of maintainability, reliability, portability etc. Software standards are important for quality assurance as they represent an identification of ‘best practice’. When developing software, standards provide a solid foundation for building good quality software.소프트웨어 품질 관리는 결함이 적고 유지보수성, 신뢰성, 이식성 등의 요구 기준을 만족하는 소프트웨어를 보장하는 데 초점을 둔다. 소프트웨어 표준은 ‘모범 사례’를 나타내므로 품질 보증에 중요하다. 소프트웨어를 개발할 때 표준은 고품질 소프트웨어를 구축하기 위한 탄탄한 기반을 제공한다.

• Reviews of the software process deliverables involve a team of people who check that quality standards are being followed. Reviews are the most widely used technique for assessing quality.소프트웨어 프로세스 산출물의 리뷰는 품질 기준이 지켜지고 있는지를 확인하기 위해 팀이 함께 점검하는 과정이다. 리뷰는 품질 평가를 위한 가장 널리 사용되는 기법이다.

• In a program inspection or peer review, a small team systematically checks the code. They read the code in detail and look for possible errors and omissions. The problems detected are discussed at a code review meeting.프로그램 점검 또는 동료 검토에서는 소규모 팀이 체계적으로 코드를 확인한다. 팀은 코드를 자세히 읽고 오류나 누락을 찾아낸다. 발견된 문제는 코드 리뷰 회의에서 논의된다.

• Agile quality management relies on establishing a quality culture where the development team works together to improve software quality.애자일 품질 관리는 개발 팀이 협력하여 소프트웨어 품질을 개선하는 품질 문화를 형성하는 데 기반을 둔다.

• Software measurement can be used to gather quantitative data about software and the software process.소프트웨어 측정은 소프트웨어 및 소프트웨어 프로세스에 대한 정량적 데이터를 수집하는 데 사용될 수 있다.

• You may be able to use the values of the software metrics that are collected to make inferences about product and process quality.수집된 소프트웨어 메트릭 값을 활용하여 제품과 프로세스의 품질에 대해 추론할 수 있다.

• Product quality metrics are particularly useful for highlighting anomalous components that may have quality problems. These components should then be analyzed in more detail.제품 품질 메트릭은 품질 문제가 있을 수 있는 이상 구성 요소를 식별하는 데 특히 유용하다. 이러한 구성 요소는 더 자세히 분석되어야 한다.

• Software analytics is the automated analysis of large volumes of software product and process data to discover relationships that may provide insights for project managers and developers.소프트웨어 분석은 대규모 소프트웨어 제품 및 프로세스 데이터를 자동으로 분석하여 프로젝트 관리자와 개발자에게 인사이트를 제공할 수 있는 관계를 발견하는 것이다.