[SoftwareV&V] 04. Software Process

[원문링크]

https://adorable-aspen-d23.notion.site/SoftwareV-V_04_Software-Process-057fce6dc87742d883638d5eff45a838

SoftwareV&V_04_Software Process

[2021 - 1학기 수강한 Software V&V 강의 정리본입니다.]

(Software Verification & Validation)

 

Test and Analysis Activities within a Software Process

: Test & Analysis 와 개발 프로세스는 함께 움직여야 한다! (개별적 NO!)

Learning Objectives

• Development Processs에서 Quality의 역할 이해하기
• Quality process 의 큰 그림 그리기
• quality process의 특징 'visibility, anticipation of activities, feedback' 이해하기

1. Software Quality and Process

1. Quality

• 소프트웨어가 본래 의도한대로 기능들이 얼마나 잘 작동하는지의 정도
• 개발의 끝에 추가되는 것이 아니라 project planning부터 꾸준히 열심히 해야한다.
• inter-dependent , 절대적X, 다차원적, constriants에 종속적

1. Testing == lifestyle

• test는 testing execution만 말하는 것이 아니라, 앞 단계에서 부터 지속적으로 일어나는 것이다.
• input, expected-output으로 Test case만듬
• software test와 analysis가 철저히 합쳐진 것이 software process의 특징이다.

1. Quality process

: 적절한 dependability(SW product quality)를 보장하고, project의 스케쥴, product의 usability등을 고려한다. (project planning 시 quality level을 정해서 레벨이 높으면 해야 될 것이 많다. quality process 할 것 많음)

• 목표 : 프로그램이 잘 작동하게 dependability를 "보장"해주기
• Framework
  • V&V Technique 고르기 (cost-effective하게)
  • other important goals(business/marketing) 과의 trade-off
  • early visibility 발전시키기ex) Quality activity가 가능하면 빨리 배치되어야 함
    • Design test case들 가능하면 빨리
    • Analysis technique를 실제 코드 생성 전에 실행
    ex) design 혹은 code에서 발견한 fault들은 진짜 reliability하지 않지만, 'Proxy'하게 또 빨리 fault를 찾을 수 있다는 점에서 의미가 있다.
  • → 현재 시점에서 지금처럼 하면 걔 퀄리티가 우리가 원하느 수준을 확보할 수 있을까?

2. V&V Plan (#48)

• V&V activity의 objective(목적), scope(범위)
• 가능한 문서와 아이템들
• 테스트 되어야 하는 items (target)
• 테스트 될 feature과 테스트 되지 않을 feature
• analysis and test activities
• 어떤 staff가 할 것인지
• constraints(제약조건)
• Pass and Fail 기준
• 스케쥴
• deliverables (output,결과물)
• hardware and software requirements
• risks and contingencies (위험성)

SQA가 하는 일

1. Development 계획 내려옴
2. product feature & Quality level 등 고려
3. 이미 존재하는 Quality process 중에서 select + Tailoring(수정)
4. 누가 뭘 할지 staff배정
5. 프로젝트 끝날 때까지 계속 care

3. Quality Goals

1. Product Quality

: Goals of SW Quality engineering

@ Internal qualities(개발자용)

• maintainability, flexibility, reparability, changeability

1. Process Qualitiy
2. @ External qualities(고객용)

• Usefulness:
• -usability,performance, security, portability, interoperability(고객노력없이도 잘 잘동되도록)
• Dependability:
  1. Correctness
  : 정해진 기준 (specification)에 따라 정확히 동작하는가
  1. Reliability
  : 유저가 SW를 얼마자 믿고 의지할 수 있는가
  • failure가 얼마나 자주 일어나는지
  • 유저에따라 상대적일 수 있다.
• -Correctness, reliability(고장X) , safety(안전) , robustness(어떻게든 동작)
• 1. Robustness
  : 요구 사항에 명시되어 있지 않은 예상치 못한 상황에서도 합리적으로 작동하는가
  1. Safe
  : undesirable 상황을 잘 대비했는지(preventing)
• 참고 : https://velog.io/@allocproc/소프트웨어-품질-mtk5coqesy

 

4. Analysis

1. Inspection technique (Review)

• 어떤 document에도 적용 가능
• 시간이 많이 소요되고, re-inspecting시에 비용이 비싸다.

1. Automatic static analysis

• static code analysis
• 사람X 기계적인 분석으로 cost-effective

1. Testing

• Test generation → 테스트는 코드로부터 독립적으로 생성된다.

5. SPI(software process improving) - 유지 보수

: improving the process

• 지속적인 fault를 확인하기
• 자주 발생하는 error Tracking하기
• Feedback

6. Organizational Factors

• 개발과 quality팀이 다른 경우가 많다.
• 각 팀은 다른 임무를 가지고 있다.
• Responsibility 배정하기
  1. Unit testing (개발 + 품질)
  2. Integration, system & acceptance testing (품질 + 개발)
  3. Inspection(감사) & walk-through(자세한 설명) (mixed teams)
  4. Regression testing (품질 + 유지보수팀)
  5. Process improvement(SPI) (전문가)

Summary

• V&V는 planned되고 monitored되어야 하는 복잡한 것이다.
• 좋은 quality process는 basic principle을 기반으로 한다.
• : visibility, early activities, feedback
• 목표
• : 실패 확률 줄이기, deliver전에 product dependability 평가하기, process 향상 시키기