: Test & Analysis 와 개발 프로세스는 함께 움직여야 한다! (개별적 NO!)
: 적절한 dependability(SW product quality)를 보장하고, project의 스케쥴, product의 usability등을 고려한다. (project planning 시 quality level을 정해서 레벨이 높으면 해야 될 것이 많다. quality process 할 것 많음)
목표 : 프로그램이 잘 작동하게 dependability를 "보장"해주기
Framework
early visibility 발전시키기
→ 현재 시점에서 지금처럼 하면 걔 퀄리티가 우리가 원하느 수준을 확보할 수 있을까?
ex) Quality activity가 가능하면 빨리 배치되어야 함
ex) design 혹은 code에서 발견한 fault들은 진짜 reliability하지 않지만, 'Proxy'하게 또 빨리 fault를 찾을 수 있다는 점에서 의미가 있다.
: Goals of SW Quality engineering
@ Internal qualities(개발자용)
Process Qualitiy
@ External qualities(고객용)
Usefulness:
-usability,performance, security, portability, interoperability(고객노력없이도 잘 잘동되도록)
Dependability:
-Correctness, reliability(고장X) , safety(안전) , robustness(어떻게든 동작)
: 정해진 기준 (specification)에 따라 정확히 동작하는가
: 유저가 SW를 얼마자 믿고 의지할 수 있는가
: 요구 사항에 명시되어 있지 않은 예상치 못한 상황에서도 합리적으로 작동하는가
: undesirable 상황을 잘 대비했는지(preventing)
참고 : https://velog.io/@allocproc/소프트웨어-품질-mtk5coqesy
: improving the process
개발과 quality팀이 다른 경우가 많다.
각 팀은 다른 임무를 가지고 있다.
Responsibility 배정하기
Unit testing (개발 + 품질)
Integration, system & acceptance testing (품질 + 개발)
Inspection(감사) & walk-through(자세한 설명) (mixed teams)
Regression testing (품질 + 유지보수팀)
Process improvement(SPI) (전문가)
V&V는 planned되고 monitored되어야 하는 복잡한 것이다.
좋은 quality process는 basic principle을 기반으로 한다.
: visibility, early activities, feedback
목표
: 실패 확률 줄이기, deliver전에 product dependability 평가하기, process 향상 시키기