Brute force Study

Software Reuse를 왜 하나요?

더 나은 SW를 빠르고 저렴하게 달성하기 위해서 하는 것.

System부터 Application, component, Object and function 까지 모두 가능

Benefits of software reuse (외워야 하나..?)

Software Reuse의 문제점은 뭐가 있을까요?

• 컴포넌트를 재사용 가능하게 만들기 위해 비용이 많이 든다
• 요구사항에 일치하는 reusable component를 찾고 이해하는데 cost가 필요하다
• 소스 코드가 없으면 유지보수 비용이 높아지고, 소유한 컴포넌트서비스가 아니라서 만드는 사람들이 뭔가 바꾸는 것에 대한 컨트롤이 불가능함
• 일부 SW tool이 재사용 지원을 안할 수 있따
• 일부 엔지니어들이 컴포넌트를 본인이 다시 작성하는 것을 선호함

Reuse planning factor : Reuse할 때 어떤 것들을 고려해야 하나요?

• 개발 일정
• expected software lifetime
• 개발팀의 background, skill, experience
• The Criticality of the SW and it's NFR
  • critical SW의 경우 NFR을 지켜야 해서 reuse가 어려울 수 있음
• The application domain(병원용, 은행용... 이런식으로 사용하려는 domain에 맞춰진 제품들이 존재함)
• The execution platform : 어떤 OS? 웹?앱?

Framework란?

소프트웨어 아티팩트의 통합 세트, application family를 위한 재사용 가능한 아키텍처를 제공해준다 (유사한 형태의 다양한 것들을 만들 수 있는 재사용 가능 아키텍처)

Application Architecure란?

시스템과 Component 중간정도. 뻔한 것은 concrete class로 구현, 아닌 것들은 Abstract class나 Interface로 제공한다

대표적으로 WAF가 있다.(동적 웹사이트 구축 지원, MVC, Security, Dynamic web page, db support, session 관리, User interaction)

Extending Framework

generic한 프레임워크를 확장해서 기본 아키텍쳐 틀에 맞게 채워 넣으면 작동하게 만든다.

Inversion of Control in Framework

Event loop가 떠있는 call-back 구조라, Control이 반대로 뒤집어 져있다

Software Product Line(중요!! 정의 보고 Software Product Line 적을 수 있어야 함)

특정 Context에서 사용하기 위해 적응되고 구성될 수 있는 일반적인 기능을 가진 응용 프로그램. generic + specific context

요구사항을 반영해서 전문화된다. Adaption은 다음과 같다.

• 구성 요소 및 시스템 구성(Component and System configuration)
  • ex) 언어(한국어, 영어)를 바꾸는 것
• 시스템에 새로운 구성 요소 추가(Adding new components to the system)
  • ex) 특수 기능을 더해주는 것
• 기존 구성 요소 라이브러리에서 선택(Selecting from a library of existing components)
• 새로운 요구 사항을 충족하기 위해 구성 요소 수정(Modifying components to meet new requirements)
  • --> customize를 해주는 것

Software Product Line의 Base System(외우기!!!)

• Core Components
• Configurable application components
• Specialized application components

Application Framework vs Product Line

공통 : 공통된 특성은 유지한다

AF : reusable한 architecture 제공, 객체 지향 기능에 의존하는 경향. 기술적 지원 제공에 중점

Product Line : 빌드할 때 공통된 부분은 그대로 두고 Special한 것만 추가. 도메인 플랫폼 정보 포함. 일반적으로 동일한 조직이 소유한 application family로 구성된다.

Product line의 아키텍처

configurable한 부분이 A또는 B를 선택하도록 해야 한다(조립식이라고 보면 될듯). 서브시스템을 분리하고 이를 수정할 수 있도록 한다. entity와 Description을 분리하고, 상위레벨에서는 description을 통해 엔티티에 접근한다

Product Line Specialization(PPEF)

Platform / Environment / Functional / Process Specialization

Product Instance 개발 (과정 외우기)!!

• 이해관계자 요구사항 도출 (Elicit stakeholder requirements)
• 가장 적합한 시스템 인스턴스 선택 (Choose closest-fit system instance)
• 요구사항 재협상 (Renegotiate requirements)
• 기존 시스템 적응 (Adapt existing system)
• 새 시스템 인스턴스 제공 (Deliver new system instance)

Application System Reuse란?

코드 수정 없이 개별적인 사용자에 맞춰서 설정만 조금 조정하여 사용하는 것. 휴대폰 언어 바꾸기 이런 것들

built-in configuration 메커니즘을 사용한다. 사용자의 관점으로 보는듯

Application System Reuse 장점은?

빠른 개발, 시스템 적합성 판단이 쉬움. dependability 확보. 개발 리스크 줄어듬. 유지보수 신경X(vendor가 해줌)

Application System Reuse 문제점은?

Configuration 범위를 넘어서면 Requirement를 조정해야 함

COTS 시스템 선택이 문서화 부족으로 어려울 수 있다

사용하려는 환경에 맞춰진 전문성이 부족할 수 있다COTS 벤더가 시스템 지원, evolution을 제어한다.

Application System의 종류에는 Configurable Application System, Integrated application system이 있다.

Configurable Application System이란?

공통된 경우가 많은 general Application. 어떤 특정 종류의 비즈니스 프로세스를 지원해줌 잠재적 사용자 범위에 필요한 기능을 제공대표적 예시가 ERP 시스템. 일반적인 비즈니스 프로세스를 지원해줌

Integrated Application System이란?

시스템을 통합해서 모은 하나의 Application이 원하는 기능을 제공X --> Application System 자체를 통합해 거대한 시스템 만든다

Integrated Application System의 디자인 기준?

• 적합한 기능성을 제공하는지
• 데이터는 어떻게 교환되는지? (포맷에 따라 변환 필요)
• 제품의 어떤 기능이 실제로 사용되는가?(70%, 80%)

Integrated Application System 구현?

인터페이스를 통해 Application System에 접근을 하는데, 일부 application은 서비스 인터페이스를 제공해주기도 하고, 아니면 통합하는 사람이 직접 구현해야 한다. 이 경우 Application Wrapping이 필요하다. Service wrapper를 만들어서 Service 할 수 있는 새로운 컴포넌트를 붙이는 형태로 확장한다

Integrated Application System 문제점?

기능/성능 제어 부족(비효과적), 상호 운용성 문제(호환이 잘 안되서 통합이 어려움), 시스템 Evolution에 대한 제어를 vendor가 하고, vendor가 지원을 오랫동안 안할 수 있음

RESTful webservice란?

클라이언트에서 서버로 resource representation을 전달하는 아키텍쳐 스타일이다. 과거 SOAP/WSDL에서 이 스타일로 서비스 호출을 한다.

Resource Operation / Access (반드시 Operation을 외우자)

Resource는 RESTful 아키텍쳐의 기본 component고, 여러가지 format으로 표현된다

CREATE(POST) / READ(GET) / UPDATE(PUT) / DELETE(DELETE)

URL을 통해서 엑세스하고, URL 쿼리를 사용할 수 있다.

RESTful 단점

• 서비스가 복잡한 인터페이스를 가지고 단순한 자원이 아닐 때, 이 RESTful 서비스를 설계하는 것은 어려울 수 있습니다.
• RESTful 인터페이스 설명에 대한 표준이 없어서 서비스 사용자가 인터페이스를 이해하기 위해 비공식 문서에 의존해야 합니다.
• RESTful 서비스를 사용할 때, 서비스의 품질과 신뢰성을 관리하기 위한 자체 인프라를 구현해야 합니다.
  •  

지금까지 Dependability 중 Availability, Reliability를 다뤘으니 이제 Safety를 다룰 차례이다.

Safety란?

시스템이 비정상/정상이든 작동하면서 인간에게 상해나 사망을 초래하지 않고, 시스템 환경에 손상을 주지 않는 속성을 말한다

availability와 Reliability를 만족한다고 해서 Safety 한게 아니다. 명세와 부합하는지는 관련이 없다.

Unsafe 하다는 건 어떤건가요?

시스템에서 오랫동안 감지되지 않다가 드물게 결함이 나탈수도 있고, 명세에 오류가 있을수도 있고, 하드웨어 고장일수도, Context-sensitive 명령일수도... 요런 것들이다

중요한 용어 암기하기

safety-critical system : 시스템 작동이 항상 안전해야 하는 시스템

Hazard가 존재한다면 Hazard의 심각성과 확률이 존재한다. 여기서 Accident(사고)로 이어질 확률이 Risk 이고, Accident 발생 시 손실을 측정한게 Damage가 된다.

Hazard를 어떻게 다뤄야 하나요? (iaas)

• 위험 요소 식별 (Hazard identification)
• 위험 요소 평가 (Hazard assessment)
  • Severity와 Probability를 추정한다
  • 가능성 높거나 심각한 것을 배제
• 위험 요소 분석 (Hazard analysis) : 근본 원인을 발견하는 것이 목표
  • 귀납적으로(system failure -> 위험을 평가)
  • 연역적으로(hazard로부터 -> 원인 추론)
• 안전 요구 사항 명세 (Safety requirements specification)

리스크를 줄이는 방법?

중요!! 이 부분을 암기하자. 언제 어떤 전략을 사용할지(ADL)

• 위험 회피(Hazard avoidance)
  • 시스템이 일부 유형의 위험이 발생할 수 없도록 설계됩니다.
  • ex) hazard 확률이 낮고, severity가 높은 경우?
• 위험 감지 및 제거(Hazard detection and removal)
  • 시스템이 사고로 이어지기 전에 위험을 감지하고 제거하도록 설계됩니다.
  • hazard 확률이 높지만 Severity가 높지 않은 경우
• 피해 제한(Damage limitation)
  • 시스템에는 사고로 인한 피해를 최소화하는 보호 기능이 포함됩니다.
  • hazard 확률이 높고 Severity도 높은 경우

Safety Engineering Process에는 어떤 것들이 있나요?(FMS)

요것도 외우기

• Formal verification : 수학적으로 명세를 세부적으로 정의. 명세 오류 및 누락, 프로그램 설계오류 발견에 효과적
• Model Checking : FSM으로 가능한 모든 경로 체크, 테스트하기 어려운 동시성 시스템 검증에 유용
• Static program analysis : 텍스트 구문분석. 프로그램이 해줌. Inspection의 보조 수단

들어가기 앞서 먼저 용어를 좀 알아보자

System fault (버그가 존재함) -> Human mistake(버그를 발생시킴) -> System error(예상치 못한 결과가 나타남) -> System failure(Crash report 같은 결과 등장. system error의 결과)

fault가 반드시 error를 발생시키는 것은 아니고(오류 발생 전에 수정하거나 아에 오류 있는 코드가 실행 안될수도), error가 반드시 failure를 초래하는 것도 아니다(예외 처리를 잘 해주거나, 보호 메커니즘)

이러한 Fault를 관리하고 다루는 방법은 아래와 같다(a, d, t로 외우면 될 듯)

• 결함 회피(Fault avoidance):
  • 시스템은 human mistake를 방지하고 System fault를 최소화하도록 개발됩니다.
  • 개발 프로세스는 System fault가 배포 전에 감지되고 수정되도록 조직됩니다.
  • Dev 단계라고 보면 될 듯
• 결함 감지(Falut detection):
  • 검증 및 검증 기술은 배포 전에 System fault를 발견하고 제거하는 데 사용됩니다.
  • Releasing test 단계라고 보면 될 듯
• 결함 허용(Fault tolerance):
  • 시스템은 전달된 Software falut이 System failure을 초래하지 않도록 설계됩니다.

Reliability : 특정 환경에서 주어진 목적을 위해 지정된 시간 동안 시스템이 고장 없이 작동할 확률(예상하는 대로 작동하는지)

Availability : 시스템이 운영 가능하고 요청된 서비스를 제공할 수 있는 확률(원할 때 이용할 수 있는지)

본격적인 내용으로 들어가보자

시스템에 따라 Reliability가 필요한 정도가 다르다. 

"정도"를 다루기 위해서, 우리는 아래에서 Reliability와 Availability를 정량적으로 표현할 것이다.

Perception of Reliability and Availability

개발팀에서 Reliability를 Specification과 관련해서 Formal 하게 정의했다고 치자. 개발팀에서는 명세를 만족했다고 하지만, 명세가 불완전해서 사용자 Perception에서는 fail이라고 받아들일 수 있다. (사용자가 개발팀이 가지고 있는 명세를 읽는건 아니니...)

(즉. Reliability에 대한 formal definition은 user perception을 반영하지 않는다)

Availability는 어떨까? 보통 Availability를 표현할 때 서비스를 제공할 수 있는 시간의 비율로 표현하는데, 이게 함정이 있다.

서비스 중단으로 인한 영향을 받는 사용자의 수(낮 vs 새벽) 과, 중단의 길이를 고려하지 않는다. 즉. 사용자가 인식하는 정도를 완전하게 반영하지 못한다.

또한 Defection을 제거한다 하더라도, 그만큼 사용자가 인식하는 Reliability가 올라가는 것도 아니다. 사용자가 이미 적응해서 신뢰할 수 있는 영역이라고 볼 수도 있는거고, Defection 자체가 거의 발생하지 않았을수도 있다.

그러면 어떻게 Reliability를 다뤄야 하나요?

이때 등장하는 개념이 System reliability requirement다. 신뢰성을 어떻게 다루고 측정하고 명시할 지를 다룬다. 기능적 / 비기능적으로 나눌 수 있다.

이런 requirement를 어떻게 정의할 수 있을까? 정량적으로 명시한다.

reliability는 측정 가능하니까... 허용되는 실패 횟수라던지, 사용 가능 시간 등을 명시할 수 있다.

Reliability metrics

System reliability의 측정 단위 이다. 운영 실패 횟수를 세고, 이를 시스템에 가해지는 요구와 운영된 시간에 관련지어 측정한다.

아래 내용을 외워서, 어떤 상황이 주어졌을 때 어떤 메트릭스를 사용해야 하는지 판단하자

요구 시 실패 확률 (Probability of failure on demand, POFOD)

• 이는 서비스 요청 시 시스템이 실패할 확률입니다.
  • 서비스 요청이 간헐적이고 비교적 드문 경우에 유용합니다(Useful when demans for service are intermittent and relatively infrequent)
  • ex) 100번 중 10번의 실패가 발생하면 10%
• 서비스가 가끔 요구되며, 서비스가 제공되지 않으면 심각한 결과를 초래하는 보호 시스템에 적합합니다.
• 예외 관리 구성요소(exception management component)를 포함하는 많은 안전-중요 시스템(safety-critical systems)에 관련이 있습니다.
  • 화학 공장의 비상 정지 시스템.

실패 발생률 (Rate of occurrence of failures, ROCOF)

• 시스템에서 실패가 발생하는 비율을 반영합니다.
• ROCOF 0.002는 1000 운영 시간 단위당 2번의 실패가 발생할 가능성이 있음을 의미합니다. 예: 1000 시간 운영당 2번의 실패.(time unit이 1 hour라면)
•  단시간에 유사한 요청을 많이 처리해야 하는 시스템에 관련이 있습니다.(Relevant for systems where the system has to process a large number of similar request in a shor time)
  • 신용카드 처리 시스템, 항공사 예약 시스템.
• ROCOF의 역수(Reciprocal of ROCOF)는 평균 고장 간격 (Mean time to Failure, MTTF)입니다.
  • MTTF : 얼마나 Failure 없이 오랫동안 서비스 할 수 있는지를 나타낸다 
  • 긴 트랜잭션이 있는 시스템에 관련이 있으며, 예를 들어 CAD 시스템과 같이 처리 시간이 오래 걸리는 시스템에 적합합니다.
  • MTTF는 예상 트랜잭션 길이보다 길어야 합니다.

가용성 (Availability, AVAIL)

• 시스템이 사용 가능한 시간의 비율을 측정합니다.
• 수리 및 재시작 시간을 고려합니다.
  • ex) 카카오톡 업데이트로 인해 장애가 발생하여, 서비스 복구가 6시간이 걸렸다. 
    • 24시간 기준 availability는 75%, 365일 기준이라면 availability가 매우 높아짐 -->기준에 따라 달라진다
• 가용성 0.998은 1000 시간 단위 중 998 시간 동안 소프트웨어가 사용 가능함을 의미합니다.
•  비정지, 지속적으로 실행되는 시스템에 관련이 있습니다.(Relevant for non-stop, continuously running systems).
  • 전화 교환 시스템, 철도 신호 시스템.

Non-functional reliability requirement

System reliablity, availability에 필요한 명세를 reliability metrics를 사용하여 명시한다

아래 내용도 외우자

• 다양한 유형의 실패(different types of failure)에 대한 availability과 reliability requirements을 명시하십시오.
  • 심각한 결과를 초래하지 않는 실패보다 고비용 실패 확률이 낮아야 합니다
• 다양한 유형의 시스템 서비스(different types of system service)에 대한 availability과 reliability requirements을 명시하십시오.
  • 중요한 시스템 서비스는 가장 높은 신뢰성을 가져야 하지만, 덜 중요한 서비스에서는 더 많은 실패를 용인할 수 있습니다.
• 높은 수준의 신뢰성이 정말로 필요한지(whether a high level of reliability is really required) 고려하십시오.
  • 다른 메커니즘을 사용하여 신뢰할 수 있는 시스템 서비스를 제공할 수 있습니다.

참고)

예시: 은행의 온라인 뱅킹 시스템

1. 다양한 유형의 실패에 대한 요구사항:
   • 고비용 실패: 은행 계좌의 잘못된 거래 처리로 인한 데이터 손실. 이러한 실패의 확률은 매우 낮아야 합니다.
   • 저비용 실패: 사용자 인터페이스의 사소한 오류. 심각한 결과를 초래하지 않으므로, 조금 더 높은 실패 확률을 허용할 수 있습니다.
2. 다양한 유형의 시스템 서비스에 대한 요구사항:
   • 중요한 서비스: 금융 거래 처리 서비스. 이 서비스는 가장 높은 신뢰성을 가져야 합니다.
   • 덜 중요한 서비스: 고객 피드백 수집 서비스. 더 많은 실패를 허용할 수 있습니다.
3. 높은 수준의 신뢰성 필요성 고려:
   • 대안적 메커니즘: 중요한 서비스의 신뢰성을 높이기 위해 데이터 백업 및 복구 시스템을 사용할 수 있습니다.

이러한 요구사항을 명시하기 위해 신뢰성 메트릭스를 사용할 수 있습니다:

• POFOD (Probability of Failure on Demand): 예를 들어, 금융 거래 처리 서비스의 POFOD는 0.001 이하로 설정될 수 있습니다.
• ROCOF (Rate of Occurrence of Failures): 고객 피드백 수집 서비스의 ROCOF는 매달 5회 이하로 설정될 수 있습니다.
• AVAIL (Availability): 금융 거래 처리 서비스의 가용성은 99.99% 이상으로 설정될 수 있습니다.

Functional reliability requirement

시스템과 SW의 기능을 정의하고, fault를 avoid, detect, tolerance 하여 system failure로 이어지지 않도록 한다. HW 고장, 운영 오류도 다룰 수 있다. 요기 아래 내용도 외우자 (CRRP)

cf) metric : verifiable NFR로 정의

• 잘못된 데이터가 failure로 이어지기 전에 이를 detect 체크를 확인하는 요구사항 (Checking requirements).
• failure 발생 후 시스템이 복구될 수 있도록 돕는 복구 요구사항 (Recovery requirements).
  • ex) 널포인터 Exception : 구글 플레이 스토어 crash 발생 원인 1위
• 시스템에 포함될 중복 기능을 명시하는 중복 요구사항 (Redundancy requirements).
  • Redundancy와 Diversity를 잘 준비해야 한다(비용은 많이 듬).
• 사용할 개발 프로세스를 명시하는 프로세스 요구사항 (Process requirements).
  • 이 시점에서는 이러한 것들이 준비되어야 한다.

결국에는 Failure로 이어지지 않는게 중요하고, Depandable Programming을 통해 이를 실천해야한다

Fault avoidance / Fault detect / Fault tolerance 를 실천하고

가시성 제한, 입력 유효성 검사, 예외 핸들러, 오류발생 높은 것 사용 최소화, 재시작 기능 제공, 배열 경계검사, 타임아웃 포함, 실제 값을 나타내는 상수에 이름지정 등 ...

내가 이 시스템을 사용하는 입장이라고 봤을 때 이 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 해요. 하지만 에자일을 못쓰는 건 아니다.

비즈니스 환경이 변하고, 컴퓨터 장비 스펙도 오르고, 신뢰성 향상을 위해서는 소프트웨어의 변화는 필요하다

Software 시스템 자체로서 중요한 비즈니스 자산이고, 이 가치를 유지하기 위해서는 반드시 change, update가 필요하다.

대부분 예산을 새로운 것들을 개발하는게 아니라, SW 변경과 진화에 사용하게 된다.

그래서 대부분 소프트웨어는 개발(development), 진화(evolution), 서비스(servicing), 퇴출(retirement) 과정을 거치게 된다

이 중 development와 evolution 단계에서는 명세(specification), 구현(implementation), 운영(operation), 검증(validation) 단계가 반복된다.

Program understanding : 소프트웨어 변경이 필요하다면, 영향을 분석하고

출시 계획(release planning)과 변경 구현(change implementation)을 반복하다

시스템 출시(system release)를 하게된다

사실 여기까지는 그렇게 중요한 내용은 아니다.이제부터가 중요한 내용이니 집중!!!

Software Evolution이 꼭 필요한 시스템들이 있다. Legacy System이 대표적이다.

Legacy System 이 뭔가요?

새로운 시스템에 사용되지 않는 언어와 기술에 의존하는 오래된 시스템이다. 소프트웨어 시스템부터 하드웨어, 라이브러리, 비즈니스 프로세스 등등 Range가 굉장히 넓은 System이다.

• System hardware : 더 이상 사용할 수 없는 하드웨어용으로 만들어져있는 시스템이다
• Support Software : 거의 사용하지 않고, 지원하지 않는 소프트웨어에 의존하는 시스템이다
• Application software : 비즈니스 서비스를 제공하는 Application System은 다수의 Application으로 구성되어 있다.
• Application data : 데이터가 일관성이 없거나, 중복되거나, 다른DB에 보관될 수도 있다
• Business process : 비즈니스 목표를 달성하기 위해 사용되는 프로세스로, 레거시 시스템 중심으로 설계되어 시스템이 제공하는 기능에 의해 제한될 수 있다.
• Business polices and rules(비즈니스 정책 및 규칙): 비즈니스를 수행하는 방법과 비즈니스에 대한 제약 사항에 대한 정의입니다.

요런 것들을 다 포괄한다고 보면 된다

Legacy system 을 그냥 뜯어 고치면 되는거 아닌가요?

보통 변경하기에 비용이 많이 들고,

일관되지 않은 프로그래밍 스타일, 사용되지 않는 프로그래밍 언어로 작성되어 있거나, 불충분한 시스템 문서화, 시스템 구조의 저하, 프로그램 최적화, 데이터 오류, 중복, 불일치 등의 문제가 존재합니다. risky하고 expensive해서 Legacy system change가 어려워요

여기서 부터는 진짜 중요하기 때문에 외워요!

그러면 이 Legacy system 을 어떻게 관리해야하죠?

처음에 말했든 System evolution 을 반드시 해야하기 때문에, 시스템을 평가해서 적절한 전략을 선택해야 한다.

Legacy system evolution Strategy?

• 시스템을 완전히 폐기(Scrap)하고 비즈니스 프로세스를 수정하여 더 이상 필요하지 않게 함.
• 시스템을 계속 유지(maintaining)함.
• 시스템을 재공학(re-engineering)하여 유지 관리성(maintainability)을 향상시킴.
• 새 시스템으로 교체(Replace)함

Legacy System 평가는 어떻게 하나요?

System quality와 business value를 기준으로 평가하면 됩니다

• 낮은 품질(low quality), 낮은 비즈니스 가치(low business value)
  • 이러한 시스템은 폐기되어야 합니다.
  • 좋은 점이 없는데 굳이 가지고 갈 필요가 없죠?
• 낮은 품질, 높은 비즈니스 가치(high business value)
  • 중요한 비즈니스 기여 --> 폐기는 못하겠다. 그런데 유지 관리 비용이 많이 든다
  • 적합한 시스템이 있을 경우 재공학(re-engineered)하거나 교체해야 합니다.
• 높은 품질(high quality), 낮은 비즈니스 가치(Low-business value)
  • COTS로 교체하거나 완전히 폐기하거나 유지 관리합니다.
  • 비즈니스 가치가 낮기 때문에 폐기를 고려할 수 있고, 품질이 높아서 유지관리도 고려할 수 있다
  • quality가 높기 때문에 재공학을 할 필요는 없고, 굳이 교체를 한다면 COTS로 하자
• 높은 품질(high quality), 높은 비즈니스 가치(High business value)
  • 정상적인 시스템 유지 관리를 사용하여 계속 운영합니다.
  • 아직은 좀 더 지켜봐도 괜찮다

Business value 는 어떻게 평가하나요?

• The use of the system(시스템 사용)
  • 시스템이 가끔이나 소수의 사람들에 의해서만 사용된다면, 비즈니스 가치가 낮을 수 있습니다.
• The business processes that are supported(지원되는 비즈니스 프로세스)
  • 시스템이 비효율적인 비즈니스 프로세스를 강제한다면 비즈니스 가치가 낮을 수 있습니다.
• 시스템 의존성(system dependability)
  • 시스템이 믿을 수 없고 그 문제가 비즈니스 고객에게 직접적인 영향을 미친다면 비즈니스 가치가 낮습니다.
• 시스템 출력(system outputs)
  • 비즈니스가 시스템 출력에 의존한다면, 시스템은 높은 비즈니스 가치를 가집니다.
  • Output이 많을 수록 분석 등에서 용이해서 비즈니스 가치가 높음
  • 이 시스템이 우리에게 출력하고 있는게 무엇인가?

얼마나 많은 사람이 쓰는지, 사용할 수 있는 비즈니스 프로세스가 제한되지는 않는지, 믿을만 한지, Output이 많은지를 고려하자

System quality는 어떻게 평가하나요?

• 비즈니스 프로세스 평가(business process assessment)
  • 비즈니스 프로세스가 비즈니스의 현재 목표를 얼마나 잘 지원하는지?
  • 불필요한 것 때문에 비즈니스 프로세스가 방해받지 않아야 함
• 환경 평가(environment assessment)
  • 시스템 환경이 얼마나 효과적이며 유지 관리하는 데 얼마나 비용이 드는지?
  • ex) 티켓팅 시스템의 서버
• 응용 프로그램 평가(application assessment)
  • 응용 소프트웨어 시스템의 품질은 어떠한가?
  • 우리가 작성한 코드 자체가 얼마나 깔끔한가? 외부 라이브러리는 어떻게 사용하고 있는가? 보안은?...

비즈니스 프로세스와 잘 맞는지, 시스템이 돌아가는 환경은 괜찮은지?(32비트만 지원한다던지 이러면 곤란), application quality(코드 구조라던지, 보안이라던지, 전반적으로 개발을 잘 해왔는지) 요런 것들을 고려하자

평가 기준을 통해서 전략을 선택했으면, 이제 직접 전략을 실천해야 겠죠?

System maintenance 를 한다는 것은 어떤 것을 한다는 거죠?

이미 개발되서 사용되는 시스템을 수정하는 것! 시스템 주요 구조는 그대로 나두고, 소소한 변경만 한다.

시스템에 존재하는 component를 수정하거나, 새로운 component를 추가하면 된다. 다음과 같은 유형으로 분류할 수 있다.

• Fault repair : 버그 및 취약점 수정
• environmental adaption : 초기 구현과 다른 환경에서 작동하도록 시스템을 바꿔버린다
• Functionallity addition and modification : 새로운 요구사항에 맞게 기능을 추가 / 수정한다.

이런 maintenance 는 새롭게 development하는 것보다 당연히 비용이 훨씬 많이 들고, 노후화 될 수록 구조가 복잡해서 비용이 많이든다

Software Reengineering 을 한다는 것은 어떤 것을 한다는 거죠?

기능은 변경하지 않고 레거시 시스템 일부/전체를 재구조화하는 것이다.

Source code translation, Reverse engineering, Program 모듈화, Data reengineering이 포함될 수 있어요

Reengineering을 하면 좋은 점은 뭘까요?

• 유지관리가 용이해집니다. 그래서 하위 시스템의 유지관리가 자주 필요한 큰 시스템에 적용될 수 있어요!
• 새로운 SW를 개발하는 것보다 Risk가 감소합니다
• 새로 개발하는 것보다는 비용이 적어요

Refactoring 과 혼동하지 말자

Refactoring은 프로그램 개선을 통해 변화에 따른 퇴화를 늦추는 과정으로,

프로그램 개발 및 진화 과정 전반에 걸친 예방적 차원의 개선 과정이에요. 프로그램 기능을 추가하고 이런게 아닙니다

Reengineering은 시스템이 유지 보수 되어서 오랜 시간 지난 후, 유지보수 비용이 증가해서 갈아 엎는 겁니다.

결국에는 코드를 잘 작성해야 maintability도 올라가겠죠?

그래서 다음과 같은 코드는 피하는게 좋아요(여기는 그냥 참고만 하면 될 듯)

• 중복 코드(Duplicate code, 일명 코드 클론(Code Clones)): 
  • 프로그램의 다양한 장소에서 동일하거나 매우 유사한 코드가 포함될 수 있습니다. 이는 제거되고 필요에 따라 호출되는 단일 메소드나 함수로 구현될 수 있습니다.
  • Code Clones : 중복된 코드가 문제가 되는 경우가 많음 (버그가 복사된다던지 등등)
  • 비슷한 코드가 여러 군데에 흩어져 있는 상황을 예로 들 수 있다.
    • 위의 경우 하나의 함수로 만들어 주는 방식 등으로 해결할 수 있다.
• 긴 메소드(Long methods)
  • 메소드가 너무 길면, 여러 개의 더 짧은 메소드로 재설계될 수 있습니다.
  • 메서드 하나가 엄청나게 긴 경우(modularity가 낮음) 메서드 하나를 private 메서드로 분리할 수 있다.
    • private 메서드에 비해 public 메서드는 더 신경 써줘야 한다.
• 스위치 문(Switch (case) statements)
  • 이들은 종종 중복을 포함하며, 스위치 문은 값의 유형에 따라 달라집니다. 
  • switch 문은 프로그램 전반에 scattered 되어 있을 수 있다. 객체 지향 언어에서는 동일한 기능을 달성하기 위해 다형성을 사용할 수 있습니다.
  • 언제 if-else를 쓰고 Switch를 쓸 건지, 아니면 다른 방식으로 처리할 건지

• 데이터 뭉치(Data clumping)
  • 동일한 데이터 항목 그룹(필드, 메소드의 매개변수)이 프로그램의 여러 곳에서 반복됩니다. 
  • 이들은 종종 모든 데이터를 캡슐화하는 객체로 대체될 수 있습니다.
  • ex)
  • method1(int[] block, Block currBlock), method2(int[] block, Block currBlock), method(int[] block, Block currBlock)
  • --> 파라미터를 Board 클래스로 뽑아서, 클래스 인스턴스를 파라미터로 설정한다
• 추측적 일반성(Speculative generality)
  • 개발자가 미래에 필요할 수 있는 일반성을 프로그램에 포함시키는 경우입니다. 
  • 이는 종종 간단히 제거될 수 있습니다.
  • 과연 이걸 specific하게 작성하면 나중에 새로운 기능을 추가할 때 이 부분의 작업이 증가하지 않을까?
  • 너무 generality를 높이면 오히러 작업 시간이 증가하고, 구조가 안좋아질 수 있다.

Program Testing은 프로그램이 의도하는 대로 작동, 결함을 발견하기 위해서 하는 것이다.

어떤 것을 테스트 하는지를 기준으로 보면 Validating Testing, Defect Testing이 있다. 

Validating Testing은 사용자의 요구사항을 충족함을 보이고, 의도한 대로 시스템이 작동하는지 보이는 것이다.

Defect Testing은 잘못된 동작, 명세와 일치하지 않는 결함을 발견. 잘못 동작하도록 하여 결함을 노출시킨다. 결함을 찾는 것!

Q) 이러한 Testing을 어떻게 해서 어떤 것을 확인하면 되나요?

artificial data를 사용하여 프로그램을 실행하고, 테스트 결과로부터 오류와 비기능적 속성을 확인한다.

프로그램 품질 보장, 결함을 발견하기 위해서는 Inspection과 Testing이 있다.

Software Inspection: 정적 시스템 Verification으로,  코드실행없이 아티팩트를 검사하는 단계(명세와 일치하는지 등등. 문서와 코드를 검사)

Software Testing: 시스템의 동작을 관찰, 테스트 데이터 활용. 비기능적 요구사항 또한 체크 가능

(요즘은 위에 두 개 다 IDE에서 잘 지원해준다)

Software Testing을 더 자세히 살펴보자.

Software Testing은 크게 보면 Development Testing, Release Testing, User Testing이 있다.

Development Testing은 뭔가요?

개발 중에 시스템을 테스트하여 버그와 결함을 발견하는 것이다.

그래서 Development Testing 어떻게 하냐?

Development Testing 단계에서는 주로 테스트 케이스를 많이 이용하여 Testing을 한다.

이런 Development Testing은 테스트 단위에 따라서 Unit Testing, Component Testing, System testing으로 나눌 수 있다.

Unit Testing은 개별 프로그램 단위나 객체, 클래스를 테스트한다.(Defection Testing에 해당)

그래서 Unit Testing에서는 객체와 관련된 operation을 테스트하고, attribute들을 막 설정하고 조회하고, 모든 상태에서 객체가 잘 작동하는지 확인한다.(Object class Testing)

그리고 Unit Testing은 단위가 작기 때문에 가능한 경우 자동화 되어서 실행/확인이 가능하다.(Automated Testing)

이 Automated Testing의 단계를 조금 더 살펴보자면 (ex. add(3,5) == 8케이스 사용)

• setup : 테스트 케이스, 즉 입력 및 예상 출력으로 먼저 초기화 // input : (3, 5), expected : 8
• call : 테스트할 객체 또는 메서드 호출 // result = add(3,5)
• assertion : 호출 결과를 예상 결과와 비교 // assertTrue(result == expected)
• tear-down : 리소스 해제 등 시스템 상태를 원래 상태로 복원 // 다른 테스트에 영향을 주지 않게 하기 위해서 이 단계를 많이 거치더라고요

다시 돌아와서, Unit Testing을 잘 하려면, 이미 작성해둔 메서드, 객체를 테스트 하는 것이기 때문에 결국 테스트 케이스를 잘 작성해야 한다.

이러한 Unit Testing 전략으로 Partitioning testing과 Guideline-based testing가 있다.

Partitioning testing은 어떤 전략인가요?

·      입력 그룹을 식별해서 파티션을 나누고

·      이 파티션에서 대표적인 값을 뽑고

·      모든 파티션에 대해서 testing 하는 전략이다

Guideline-based testing은 어떤 전략인가요?

·      테스트 가이드라인을 사용하여 테스트 케이스를 선택하는 것이다

·      테스트 가이드라인의 예시를 들어주세요!

o   보통 자주 저지르는 오류를 포함하는데

o   ex) 자바 collection에서 처음, 중간, 마지막 요소를 테스트해보자

o   모든 오류 메시지를 생성해보자

o   입력이 overflow가 되도록 해보자

o   메서드 처리 결과가 너무 크거나 작도록 해보자

조금 더 큰 단위인 Component testing을 보자.

Component란 Unit test에서 다뤘던 그 Unit들을 통합하여 구성한 것이다. 

그래서 유닛들을 통합했을 때 잘 작동하는지를 테스트 해야 한다. 

component단위에서는 Component interface를 통해 객체가 작동하도록 하기 때문에

(사람으로 따지면 관절을 통해서 부위가 움직이잖아요!),  

Component Interface가 명세에 따라서 잘 작동하는지 보이는 단계가 바로 Component Testing이다. (Interface가 핵심!!!)

그래서 이 단계에서는 Interface testing을 한다.

Interface testing의 목표는 Interface 오류나, Interface를 잘못 가정해서 생긴 defection을 찾는 것이다.

Interface 에는 어떤 것들이 있나요?

·      Parameter Interface: 메서드나 프로시저에서 전달되는 데이터

o   객체 A를 전달해야하는데 객체B를 전달하면 안되겠죠? 

·      Shared memory Interface : 프로시저나 함수 간에 공유되는 메모리 블록

·      Procedural Interface: 하위 시스템이 다른 하위시스템에 호출된 일련의 절차를 캡슐화. 이게 뭔말이냐?

o   A가 B호출, B가 C를 호출, C가 D를 호출,,, 이런 과정, 절차를 말한다

o   이런 Procedural Interface error의 대표적인 예시가 OS에서 다루는 Deadlock

·      Message passing interface : 하위 시스템이 다른 하위시스템으로부터 서비스 요청

Interface error에는 어떤 것이 있나요?

·      Interface misuse : 인터페이스 사용 오류

o   ex) 매개변수를 (피제수, 제수)로 보내야 하는데, (제수, 피제수)로 전달

·      Interface misunderstanding : 호출 컴포넌트가 호출된 컴포넌트 동작에 대한 잘못된 가정을 포함

o   ex) 회원 정보가 없으면 빈 회원 객체를 생성해서 반환해주는 줄 알았는데, null을 반환해주네?

·      Timing error : 호출/호출된 컴포넌트간 다른 속도로 동작하고, 시간 정보에 접근이 이루어질 때 오류가 발생

o   ex) 공유 데이터에 여러 객체가 동시에 접근해서 혼동이 생기는 경우

그러면 Interface error를 테스트 하기 위한 guideline을 알려주세요!

 : 경계를 체크하거나, null 포인터를 매개변수로 보냈을 때 제대로 작동하는지 체크, 컴포넌트가 실패하도록 테스트를 설계해보고, 스트레스 테스트도 해보고, 공유 메모리 시스템에서 컴포넌트 활성화 순서도 바꿔 보고 등등

..

위에서 봤던 Component들이, 또는 시스템 일부가 서로 통합되어 새로운 시스템을 이루고 이걸 테스트 하는 것이 System Testing이다. 따라서 Component 간의 Interaction을 테스트하고, Interface를 통해서 제대로 작동하는지 테스트한다. (시스템 긴급동작도 테스트한다) 

그래서 이 System Testing 단계에서는 시스템 간의 Interaction을 중점으로 보기 때문에, 이걸 Use-case로 개발하여 시스템테스트의 base로 사용한다(Use-case Testing)

여기서 System의 범위는 굉장히 넓어서, Reusable 시스템이나, 다른 하위 팀에서 개발한 컴포넌트들이 포함될 수가 있다. 여태 개발한 것들을 모아서 테스트한다고 보면 된다.

그리고 System 자체가 광범위 하기 때문에 “어느 정도 까지 테스트하면 된다”.  즉 Coverage를 정의 해야 한다. (System Testing Policy). 원자로 시스템, 항공 시스템의 경우에는 더 엄격한 Testing Policy가 필요하겠죠?

여기 까지가 Development Testing이고, 

이제 개발을 끝냈으면 Release를 해야 하는데, 그 전에 Release testing을 해야 합니다.

(개발 팀 외부에서 사용하도록 의도된 특정 릴리즈 시스템을 유저에게 제공하기 전에 테스트하는 것이다.) 

왜 Release Testing을 하나요?

시스템 공급자에게 시스템이 충분히 좋다는 것을 확신시켜주고, 기능, 성능에 대한 신뢰성을 제공하고, 정상 사용중에 실패하지않음을 보여주기 위함입니다!

Release Testing도 결국 시스템을 테스팅 하는 것 아니에요?

맞습니다. 하지만 시스템 테스팅은 시스템 내 error를 발견하는데 중점을 두지만, Release Testing은 조금 더 시스템Provider 입장에서, 시스템이 요구사항을 충족하고 외부 사용에 충분히 좋은지를 확인시켜주는 테스트 합니다

위에서 말한 것처럼, 시스템 요구사항을 만족하고 충분히 좋은지를 알려줘야 합니다.

그래서 크게 보면 아래 두 가지 테스트를 진행합니다

Requirement based Testing : 요구사항을 검토하고, 이에 대한 테스트를 개발합니다. 보통 시나리오를 가지고 테스트를 합니다

Performance Testing : 성능/안정성과 같은 System attribute 테스트를 합니다. 시스템이 충분히 외부에서 사용될 수 있음을알려주는 것이죠!(ex. stress test)

이제 Release 준비가 끝났다면, 사용자에게 Release를 뿌려봐야겠죠? 

하지만 Release한다고 해서 Testing이 끝난 것이 아닙니다. 

사용자의 작업 환경에서 발생하는 영향들이 시스템의 신뢰성, 사용성에 영향을 주기 때문에 User testing을 반드시 해야 합니다.

이 User testing에서는 사용자, 또는 잠재적 사용자가 자신의 환경에서 시스템을 테스트 하고, 의견을 제공합니다.

User testing의 유형에는 크게 3가지가 있습니다

·      Alpha testing : 소프트웨어 사용자가 개발팀과 함께 소프트웨어를 테스트합니다

o   게임 유저를 회사에 초청해서 테스트 하거나, 사내 테스트를 하는 등

·      Beta testing : 테스트를 위한 릴리즈를 사용자에게 뿌려서 문제를 발견하고 피드백을 받습니다.

·      Acceptance testing : 요거는 살짝 결이 다른데, 고객이 시스템을 테스트 하고, 고객 환경에서 시스템을 사용할 준비가되었는지 평가, 결정합니다. (주로 외주를 하고 Product를 제공하는 맞춤형 시스템에서 많이 하는 것)

o   특정 경우 애자일과 안맞을 수도 있다(계약맺고 개발하는 것을 생각해봐요)

지금까지 다룬 Testing은 작성된 코드를 바탕으로 테스트를 작성했지만, 

이와 반대로 테스트를 작성한 후 코드를 작성하는 방식이 있다. 

이를 TDD(Test-Driven Development) 라고 한다. TDD는 테스트와 코드 개발을 교차진행하는 방식이다. 테스트 통과가 주요 동인이고, 단계에 맞는 테스트를 개발하고 코드를 점진적으로 개발해 나간다.

어떤 장점이 있기에 TDD를 사용할까?

·      Regression testing에도 효과적이다. (변경사항 이전에 작동하던 코드가 깨지는지)

·      Simplified Debugging (문제가 있는 곳을 찾기 수월함)

·      System documentation(테스트 케이스가 명세의 역활을 한다)

·      Code coverage가 올라간다. 

o   Code Coverage 종류로는 Statement/Branch/Condition Coverage가 있다

o   코드 커버리지를 올리려면

§  setup 부분과 call 부분을 신중하게 설계

§  public이 private을 반드시 호출

§  모듈화를 잘해서 테스트 케이스를 쉽게

o   물론 Code coverage만으로는 테스트 스윗 평가에 충분하지 않다.

§  Mutation(변형) testing을 해보자 (코드 변형 후 테스트가 결함 감지할 수 있는지 확인하는 테스팅)