[소프트웨어 공학] 2. Software Qualities

Software Development Process

1. Feasibility Study - 기술적인 관점에서 실현가능성을 확인한다.

2. Requirements Analysis & Specification - 요구사항을 정의한다.

3. Design 

4. Coding & Unit Testing

5. Integration & System testing

6. Delivery & Maintenance

Software Qualities - Definitions

The degree to which the attributes of software enable it to perform its intended end use. (DoD, 1985)

- 사용자의 요구를 제대로 수행하고 attributes of software 즉, 문서나 데이터 등이 제대로 정립되었는가?

The totality of features and characteristics of a product or a service that bear on its ability to satisfy specified or implied needs. (ISO, 1986)

- 소프트웨어가 고객의 요구를 제대로 만족시킬수 있는 능력이다.

Fitness for needs ( Kitchenham, 1986)

- 고객의 요구에 적합한가?

Why software quality is different from other types of quality?

software has no physical existence - 물리적으로 존재하는 것이 아니기 때문이다.

The lack of knowledge of client needs at the start - 요구에 대한 지식이 부족하다. (소프트웨어는 여러 분야에 활용된다.)

The change of client needs over time. - 고객의 요구가 변경된다.

The high expectation of customers. - 고객이 기대치가 높다.

Qualities Classification

External and Internal Qualities, Product and Process Qualities

External Quality - 사용자의 기준에서 (UI 나 시스템 성능 등)

Internal Quality - 개발자 기준에서 ( 모듈화나 가독성 등)

Product Quality - 소프트웨어 자체에서 Functionality, Usability, Efficiency, Reliability 등..

Process Quality - 소프트웨어 개발 절차에서 Effectiveness of methods, tools, Use of standards, Managements 등..

Representative Qualities

Correctness	기능 명세에 따라 잘 작동하면 Correct 하다고 할 수 있다.
Reliability	유저가 의존하게 될 때 신뢰성 있다고 한다. 상대적인 관점이다.   측정 방법은 MTTF(mean time to failure, 에러 횟수), MTBF(mean time between failure, 에러 발생 정도)
Robustness	요구사항 명세서에서 예측할 수 없었던 상황에서도 잘 동작하면 Robust 하다고 할 수 있다.
Performance	시간과 공간에 대해서 효과적으로 동작하는 것  측정 방법은 Monitoring , Analysis , Simulation 등이 있다.
User Friendliness	Ease to use. (유저가 사용하기 편하도록)
Verifiability	분석(수학적인 방법)이나 테스팅을 통하여 verified 받아야 한다.
Maintainability	Corrective(수정해야 하는 것), Adaptive (환경이 변화할때), Perfective( 소프트웨어 구조를 바꿀  때), Preventive (미리 대처하는 것) . 즉 Repairability and Evolvability 가 있어야 한다.  Repairability - Right modularization 등을 통해 에러를 최대한 빨리 고칠 수 있어야 한다.  Evolvability - 시스템이 계속 발전할 때 설계가 잘 되어있으면 쉬워진다.
Reusability	새로운 프로젝트에 기존에 있는 컴포넌트를 사용하는 것.
Portability	다른 환경에서도 동작하는 것. 플랫폼마다 모듈화를 하여 이룰 수 있음.
Understandability	제품 내부의 품질로 개발자가 원하는 것. (유지보수성을 위해)
Interoperability	다른 시스템과 협력할 수 있는 것.
Productivity	프로그래밍 언어와 관계 없이 요구 기능을 얼마만큼의 시간안에 해낼 수 있는가.  측정하는 방법: FP(function point) 또는 SLOC (software line of code)
Timeliness	제한된 시간안에 배포하는 것. (careful scheduling, accurate work estimation, clearly specified  milestones이 요구된다.) , 요구사항이 자주 변경될 수 있으므로 단계적(조금씩)으로 배포한다.
Visibility	문서화하여 모든 단계를 볼 수 있는 것. 팀장의 의사결정에도 필요하며, 프로젝트의 진척도 및 문제  점을 쉽게 파악할 수 있다.

Quality Requirements in Specific Apllication Areas

Information Systems	ex) banking systems, library-cataloging systems..  Data integrity, Security, Data availability, Transaction performance, User friendliness  정보시스템에서는 자료보존이나 보안 등이 중요하다.
Real-time Systems	ex) factory-monitoring systems, missile guidance systems...  Deadline, Priority, Respond time requirements, Safety  실시간 시스템에서는 정해진 시간안에 정확하게 반응해야 한다.
Distributed Systems	ex) middleware in client-server systems..  System availability, Code mobility  분산시스템에서는 작업할당 및 분할이 중요하다.
Embedded Systems	ex) Airplanes, robots, microwave ovens...  Reliability, Adaptability, Memory and performance efficiency

소프트웨어 품질이 중요한 이유.

소프트웨어 공학이라고 하는 것은 결국 소프트웨어 품질을 향상시키기 위해서 존재한다.

제품의 품질을 높인다는 것은 고객의 요구를 완벽하게 이루어내고 품질을 높여 수익을 증대시키기 때문이다.

소프트웨어 품질을 측정하는 방법의 한 예는 Mecabe's cyclomatic complexity 를 들 수 있다.

control flow graph를 이용하여 소프트웨어 복잡도를 수치화 한다.

V(G) = E- N+ 2*P 로 표현할 수 있다. ( E: Edge, N: Node, P: connected compotents)

마지막으로 소프트웨어 품질은 요구사항에 얼마나 적합한가를 나타낸다.