[소프트웨어 공학] 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)
마지막으로 소프트웨어 품질은 요구사항에 얼마나 적합한가를 나타낸다.