[소공 시험공부] System Dependability

내가 이 시스템을 사용하는 입장이라고 봤을 때 이 System에서 가장 중요한 건 바로 Dependability다. 

 

신뢰할 수 없는 시스템을 사용자가 애초에 거부할수도 있고, 경제적 손실로 이어질 수도 있고, 신체적 손상 등등 발생할 수 있는 문제가 많다.

 

어떤 것들이 Dependability 에 해당하죠?

• 가용성(Availability): 요청 시 서비스를 제공할 수 있는 시스템의 능력
  • 원할 때 시스템을 사용할 수 있을까?
• 신뢰성(Reliability): 지정된 대로 서비스를 제공할 수 있는 시스템의 능력
  • 원하는 대로 시스템이 작동하는가?
• 안전성(Safety): 치명적인 실패 없이 작동할 수 있는 시스템의 능력
  • 이 시스템이 안전한가?
  • ex) 자율주행 시스템
• 보안(Security): 의도적이거나 우발적인 침입으로부터 시스템을 보호할 수 있는 능력
• 복원력(Resilience): 손상된 사건으로부터 저항하고 회복할 수 있는 시스템의 능력
• 복구 가능성(Repairability): 실패 시 시스템을 복구할 수 있는 정도를 반영한다.
  • 실패가 발생했을 때 얼마나 쉽게 복구할 수 있는가?
• 유지보수성(Maintainability): 새로운 요구 사항에 맞게 시스템을 적응시킬 수 있는 정도를 반영한다.
• 오류 허용성(Error Tolerance): 사용자 입력 오류를 피하고 허용할 수 있는 정도를 반영한다.
  • 에러가 발생했을 때 적절히 처리하여 system failure가 발생하지 않게 해주는 부분

이런 Dependability는 보통 상호의존적인 경우가 많아요

• 가용성, 신뢰성 → 안전성
• ex) 자율 주행 시스템
  • Availability
    • 충돌 감지 시스템이 작동하지 않아, 자동으로 감속하는 기능이 작동하지 않음.
    • 자율 주행 시스템 자체가 죽어버리는 경우
  • Reliability
    • 시스템이 브레이크를 밟아야 하는데 Accelerator를 밟음

 

• 서비스 거부 공격(DDOS)은 시스템을 이용할 수 없게 만들려는 의도이다.
• 또한, 시스템이 바이러스에 감염되면 신뢰성이나 안전성을 신뢰할 수 없다.
• Security에 문제가 있어서 해킹을 당하는 경우
• 보안 → 신뢰성, 가용성, 안전성
• 신뢰성 속성들이 상호 의존적이라는 많은 다른 예들이 있다.
• 발표 예시) 핵(미사일) 시스템, 원자로 시스템, 결제 시스템, 병원 시스템, 시스템 펌웨어

무조건 Dependability가 높은게 좋은거는 아니에요

신뢰성이 올라갈수록 cost가 많이 드는데, 신뢰도를 포기하고 실패 비용을 지불하는게 더 효과적일 수가 있습니다

 

Dependability를 확보하기 위한 Process로는 어떤게 있나요?

• Holistic system design을 해야합니다(시스템 각 계층간 상호작용과 의존성이 있으므로)
• 규제
  • Regulation and compilance : 정부가 기업의 자유를 제한
  • Regulated system : 서비스 전에 외부 규제 기관의 승인을 받는다
  • Safety regulation : safety-critical 시스템 회사는 규정 준수를 보이는 safety-case를 제시해야 한다.
• 개발
  • Redundancy : 여러 버전을 유지하여, 백업이 가능하도록
  • Diversity : 동일 기능을 여러 방식으로 구현

프로세스들은 단일 접근 방식에 의존하면 안되고, 너무 Redundancy와 Diversity가 높으면 예상치 못한 오류가 더 많이 발생할 수 있다.

 

이런 프로세스들 조차도 Dependable 해야겠죠? 

Depndable Process를 위해서는

• Repeatable : 개인의 해석과 판단에 의존하지 않고 누가 참여했는지 관계 없이 반복되어야 합니다
• Explicitly defined : 생산과정에서 정의된 프로세스 모델을 따랐음을 보이는 데이터를 수집해야 합니다

 

Diversity, Redundancy 말고도 아래 내용도 봐두자

Dependable process의 구체적인 activity로는

• 요구사항 검토(Requirements review): 요구사항이 가능한 한 완전하고 일관성(complete and consistent) 있는지 확인.
• 요구사항 관리(Requirements management): 요구사항 변경이 통제되고 제안된 변경의 영향이 이해되도록 보장.
• 정형 명세(Formal specification): 소프트웨어의 수학적 모델을 생성하고 분석.
• 시스템 모델링(System modeling): 소프트웨어 설계가 명확히 문서화되어 그래픽 모델 세트로 요구사항과 이들 모델 간의 연결이 문서화됨.
• 설계 및 프로그램 검토(Design and program inspections): 시스템의 다양한 설명을 서로 다른 사람들이 검사하고 확인하는 활동.
• 정적 분석(Static analysis): 프로그램의 소스 코드에 대해 자동화된 검사를 수행하는 활동.
• 테스트 계획 및 관리(Test planning and management): 포괄적인 시스템 테스트 세트를 설계하는 활동.
  • 테스트 프로세스는 이러한 테스트가 시스템 요구사항을 충족하고 테스트 과정에서 올바르게 적용되었음을 입증하기 위해 신중하게 관리되어야 한다.

위와 같은 activity가 개발 Process에 녹아있어야 합니다!

 

 

입증하기 위한 문서가 필요하다고요? 애자일 방법이랑은 안맞는데요?

퓨어 에자일은 dependable system 에는 non-practical 해요. 하지만 에자일을 못쓰는 건 아니다.