Topics covered

• Dependability properties
• Sociotechnical systems
• Redundancy and diversity
• Dependable processes

System dependability

• For many computer-based systems, the most important system property is the dependability of the system.
• The dependability of a system reflects the user’s degree of trust in that system.
  • It reflects the extent of the user’s confidence that it will operate as users expect and that it will not ‘fail’ in normal use.
• Dependability covers the related systems attributes of reliability, availability and security.
  • These are all inter-dependent.

시스템의 신뢰성

• 많은 컴퓨터 기반 시스템에서 가장 중요한 시스템 속성은 그 시스템의 신뢰성입니다.
• 시스템의 신뢰성은 사용자가 그 시스템에 대한 신뢰도를 반영합니다.
  • 이것은 사용자가 시스템이 예상대로 작동할 것이라는 확신과, 일반적인 사용 중에 '실패'하지 않을 것이라는 확신의 정도를 반영합니다.
• 신뢰성은 안정성, 가용성, 그리고 보안성과 같은 관련 시스템 속성을 포괄합니다.
  • 이들은 모두 상호 종속적입니다.

Importance of dependability

• System failures may have widespread effects with large numbers of people affected by the failure.
• Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by their users.
• The costs of system failure may be very high if the failure leads to economic losses or physical damage.
• Undependable systems may cause information loss with a high consequent recovery cost.

신뢰성의 중요성

• 시스템의 실패는 광범위한 영향을 미치며, 많은 수의 사람들이 그 실패의 영향을 받을 수 있습니다.
• 신뢰성이 없고, 안정성이 없거나 또는 보안성이 떨어지는 시스템은 사용자들에게 거부당할 수 있습니다.
• 실패가 경제적 손실이나 물리적 손상을 초래할 경우, 시스템 실패의 비용은 매우 높을 수 있습니다.
• 신뢰성이 떨어지는 시스템은 정보 손실을 초래할 수 있으며, 이에 따른 복구 비용이 높을 수 있습니다.

신뢰성은 특히 필수 시스템, 즉 생명을 유지하거나 중요한 기능을 제공하는 시스템에서 중요합니다. 예를 들어, 의료 장비, 항공 교통 제어 시스템, 핵 발전소 제어 시스템 등에서는 신뢰성이 매우 중요합니다. 이러한 시스템에서의 실패는 인명 피해나 막대한 경제적 손실을 초래할 수 있습니다. 또한, 정보 보안이 중요한 시스템에서도 신뢰성은 중요한 역할을 합니다. 예를 들어, 은행이나 정부 시스템에서는 사용자의 개인정보와 중요 데이터를 안전하게 보호해야 합니다.

Dependability properties

The principal dependability properties

Other dependability properties

• Repairability
  • Reflects the extent to which the system can be repaired in the event of a failure.
• Maintainability
  • Reflects the extent to which the system can be adapted to new requirements.
• Error tolerance
  • Reflects the extent to which user input errors can be avoided and tolerated.

주요 신뢰성 속성
이미지에 제시된 세 가지 주요 신뢰성 속성에 대해 설명하겠습니다.

• 가용성(Availability): 이는 시스템이 사용자의 요구에 따라 작동할 수 있는 시간의 비율을 나타냅니다. 예를 들어, 99.9% 가용성은 시스템이 연간 약 9시간 동안 작동하지 않을 수 있다는 것을 의미합니다.
• 신뢰성(Reliability): 이는 시스템이 실패 없이 지속적으로 작동할 수 있는 기간을 나타냅니다. 신뢰성이 높을수록 시스템은 더 긴 시간 동안 정상적으로 작동할 수 있습니다.
• 보안(Security): 이는 시스템이 무단 접근, 변경, 또는 손상으로부터 안전하다는 정도를 나타냅니다. 보안성이 높은 시스템은 허가되지 않은 사용자로부터 데이터와 기능을 잘 보호합니다.

Dependability attribute dependencies

• Safe system operation depends on the system being available and operating reliably.
  • Availability, Reliability ➞ Safety
• A system may be unreliable because its data has been corrupted by an external attack.
  • Denial of service attacks on a system are intended to make it unavailable.
  • Also, If a system is infected with a virus, you cannot be confident in its reliability or safety.
  • Security ➞ Reliability, Availability, Safety.
• There are many other examples which show that dependability attributes are inter-dependent.

기타 신뢰성 속성
다음은 신뢰성과 관련된 추가적인 속성들입니다.

• 수리 가능성(Repairability): 이는 시스템이 실패한 경우 어느 정도로 수리할 수 있는지를 반영합니다. 좋은 수리 가능성을 가진 시스템은 빠르고 효과적으로 복구될 수 있습니다.
• 유지 보수성(Maintainability): 이는 시스템이 새로운 요구 사항에 어느 정도로 적응할 수 있는지를 반영합니다. 높은 유지 보수성을 가진 시스템은 새로운 요구 사항이나 변경 사항에 빠르게 대응하고 적응할 수 있습니다.
• 오류 허용성(Error Tolerance): 이는 사용자 입력 오류를 얼마나 피하고 허용할 수 있는지를 반영합니다. 오류 허용성이 높은 시스템은 사용자의 실수를 피하거나 이를 용인하면서도 계속해서 정상적으로 작동할 수 있습니다.

Dependability achievement

• Avoid the introduction of accidental errors when developing the system.
• Design V & V processes that are effective in discovering residual errors in the system.
• Design systems to be fault tolerant so that they can continue in operation when faults occur.
• Design protection mechanisms that guard against external attacks.
• Configure the system correctly for its operating environment.
• Include system capabilities to recognise and resist cyberattacks.
• Include recovery mechanisms to help restore normal system service after a failure.

신뢰성 달성

신뢰성은 다음과 같은 방법으로 달성할 수 있습니다:

• 시스템 개발 과정에서 우발적인 오류를 도입하는 것을 피합니다. 이는 코드 품질 관리, 효율적인 개발 프로세스, 잘 정의된 요구사항 등을 통해 달성할 수 있습니다.
• 시스템 내의 잔여 오류를 발견하는 데 효과적인 설계 검증 및 검정(Design V & V) 프로세스를 설계합니다. 이는 테스트 전략, 자동화된 테스트, 평가 지표 등을 포함할 수 있습니다.
• 시스템을 결함 허용(fault-tolerant)으로 설계하여, 결함이 발생했을 때에도 계속 운영할 수 있게 합니다. 이는 레디던시(중복성), 유연성, 자체 진단 및 복구 기능 등을 포함할 수 있습니다.
• 외부 공격을 방지하는 보호 메커니즘을 설계합니다. 이는 암호화, 권한 관리, 방화벽, 침입 탐지 시스템 등을 포함할 수 있습니다.
• 시스템을 운영 환경에 맞게 올바르게 구성합니다. 이는 시스템 설정, 환경 변수, 외부 서비스와의 통합 등을 포함할 수 있습니다.
• 사이버 공격을 인식하고 저항하는 시스템 기능을 포함합니다. 이는 침입 탐지 및 예방 시스템, 공격 패턴 분석, 보안 로깅 및 모니터링 등을 포함할 수 있습니다.
• 실패 후 정상 시스템 서비스를 복구하는 데 도움이 되는 복구 메커니즘을 포함합니다. 이는 데이터 백업 및 복구, 장애 복구 계획, 상태 체크포인트 등을 포함할 수 있습니다.

Dependability costs

• Dependability costs tend to increase exponentially as increasing levels of dependability are required.
• There are two reasons for this:
  • The use of more expensive development techniques and hardware that are required to achieve the higher levels of dependability.
  • The increased testing and system validation that is required to convince the system client and regulators that the required levels of dependability have been achieved.
    

신뢰성 비용

신뢰성을 높이는 데는 비용이 발생하며, 요구되는 신뢰성 수준이 높아질수록 이 비용은 지수적으로 증가하는 경향이 있습니다. 이는 주로 다음 두 가지 이유 때문입니다:

1. 더 비싼 개발 기법과 하드웨어의 사용: 더 높은 수준의 신뢰성을 달성하기 위해서는 종종 고급 기법과 하드웨어가 요구됩니다. 예를 들어, 안정성이 더 높은 하드웨어를 사용하거나, 보다 견고한 소프트웨어 개발 접근법을 적용하거나, 혹은 전문적인 검증과 검사 프로세스를 수행하는 것 등이 이에 해당합니다. 이런 요소들은 초기 개발 비용을 증가시키지만, 이는 결국 더 높은 수준의 신뢰성을 달성하는 데 도움이 됩니다.
2. 증가된 테스트와 시스템 유효성 검증: 더 높은 수준의 신뢰성을 달성하기 위해서는 테스트와 시스템 유효성 검증을 더욱 철저히 수행해야 합니다. 이는 시스템이 예상대로 작동하고 있는지, 그리고 요구 사항을 정확히 충족하고 있는지를 확인하기 위한 것입니다. 또한 이런 과정은 시스템 사용자와 규제 당국에게 요구되는 신뢰성 수준이 실제로 달성되었다는 것을 입증하는 데도 중요합니다.

그림에서 보여주는 것처럼, 이러한 비용은 신뢰성 수준이 증가함에 따라 지수적으로 증가합니다. 즉, 약간의 신뢰성 향상을 위해 상당히 많은 비용이 들 수 있다는 것을 의미합니다. 이는 신뢰성이 매우 중요한 시스템(예: 핵발전소 제어 시스템, 의료 기기 등)에서는 비용을 아끼지 않고 높은 수준의 신뢰성을 달성하려고 노력하지만, 덜 중요한 시스템에서는 더 낮은 수준의 신뢰성이 수용 가능할 수 있음을 의미합니다.

Dependability economics

• Because of very high costs of dependability achievement, it may be more cost effective to accept untrustworthy systems and pay for failure costs.
• However, this depends on social and political factors.
  • A reputation for products that can’t be trusted may lose future business.
• Depends on system type.
  • For business systems in particular, modest levels of dependability may be adequate.

Dependability economics
신뢰성 달성의 매우 높은 비용 때문에, 신뢰할 수 없는 시스템을 수용하고 실패 비용을 지불하는 것이 더 비용 효율적일 수 있습니다. 즉, 시스템을 완벽하게 신뢰성 있게 만드는 대신, 시스템이 실패했을 때 발생하는 비용을 감수하는 것이 비용 측면에서 더 효율적일 수 있다는 의미입니다.

그러나 이는 사회적 및 정치적 요인에 따라 달라집니다. 신뢰할 수 없는 제품에 대한 평판이 미래의 비즈니스를 잃을 수 있으므로, 이런 식의 접근 방식이 항상 적합하지는 않습니다.

또한 이는 시스템의 종류에 따라 다릅니다. 특히 비즈니스 시스템의 경우, 보통은 중간 정도의 신뢰성이 충분할 수 있습니다.

Sociotechnical systems

Systems and software

• Software engineering is not an isolated activity but is part of a broader systems engineering process.
• Software systems are therefore not isolated systems but are essential components of broader systems that have a human, social or organizational purpose.
  

Systems and software
소프트웨어 공학은 고립된 활동이 아니라, 더 넓은 시스템 공학 프로세스의 일부입니다. 따라서 소프트웨어 시스템은 고립된 시스템이 아니라, 인간, 사회 또는 조직적 목적을 가진 더 넓은 시스템의 필수적인 구성 요소입니다.

제공된 그림은 이 개념을 잘 보여줍니다. 소프트웨어 시스템은 훨씬 더 큰 소시오기술 시스템의 일부로서, 사람들과의 상호작용, 조직 구조, 사회적 요소, 물리적 환경과 결합되어 작동합니다. 이러한 시스템들은 종종 복잡한 문제를 해결하거나 중요한 기능을 수행하기 위해 사람들과 협력하여 작동합니다.

The Socio-Technical System (STS) stack

The Socio-Technical System (STS) stack
이 그림은 소시오기술 시스템(STS) 스택을 보여줍니다. STS 스택은 다음과 같은 레이어로 구성되어 있습니다:

• 소프트웨어 시스템: 개별 소프트웨어 구성 요소로, 특정 기능을 제공합니다. 예를 들어, 어플리케이션 또는 데이터베이스가 여기에 해당됩니다.
• 하드웨어 시스템: 소프트웨어를 실행하는 물리적 장비를 포함합니다. 예를 들어, 서버, 네트워크 장비, 컴퓨터 등이 포함됩니다.
• 사람들: 시스템을 사용하거나 유지 관리하는 사람들을 포함합니다.
• 사회적 시스템: 조직 및 그룹이 시스템을 사용하는 방식과 관련된 사회적 규범과 프로세스를 포함합니다.
• 물리적 환경: 시스템이 동작하는 물리적 환경을 포함합니다. 예를 들어, 데이터 센터의 위치, 기후 조건 등이 여기에 해당됩니다.

Holistic system design

• There are interactions and dependencies between the layers in a system and changes at one level ripple through the other levels.
• For dependability, a system's perspective is essential.
  • Contain software failures within the enclosing layers of the STS stack.
  • Understand how faults and failures in adjacent layers may affect the software in a system.
    • e.g.) Apps for delivery, mobility, contents recommendation, reviews, etc.

Holistic system design
시스템의 각 레이어 사이에는 상호작용과 의존성이 있으며, 한 레벨에서의 변경이 다른 레벨로 파급됩니다. 따라서 신뢰성을 위해 시스템 전체를 고려하는 것이 필수적입니다.

• 소프트웨어 실패를 STS 스택의 포함 레이어 내로 제한해야 합니다.
• 인접 레이어에서의 결함과 실패가 시스템의 소프트웨어에 어떤 영향을 미칠 수 있는지 이해해야 합니다.
  • 예를 들어 배달, 이동성, 콘텐츠 추천, 리뷰 등의 앱이 이에 해당됩니다.

Regulation and compliance

• The general model of economic organization that is now almost universal in the world is that,
• privately owned companies offer goods and services and make a profit on these.
• To ensure the safety of their citizens, most governments regulate (limit the freedom of) privately owned companies,
• so that they must follow certain standards to ensure that their products are safe and secure.

Regulation and compliance
현재 거의 전 세계적으로 통용되는 경제 조직의 일반적인 모델은 사유 기업이 상품과 서비스를 제공하고 이로 이익을 내는 것입니다. 그러나 그들의 시민의 안전을 보장하기 위해, 대부분의 정부는 사유 기업의 자유를 제한(규제)하여, 그들의 제품이 안전하고 보안되도록 특정 표준을 준수해야 합니다. 이것이 규제와 준수(Regulation and compliance)가 필요한 이유입니다.

Regulated systems

• Many critical systems are regulated systems, which means that their use must be approved by an external regulator before the systems go into service.
  • Nuclear systems
  • Air traffic control systems
  • Medical devices
• A safety and dependability case has to be approved by the regulator.
  • Therefore, critical systems development has to create the evidence to convince a regulator that the system is dependable, safe and secure.

Regulated systems
많은 중요한 시스템들은 규제된 시스템으로, 이는 시스템이 서비스에 들어가기 전에 외부 규제 기관의 승인을 받아야 함을 의미합니다. 핵 시스템, 항공 교통 관제 시스템, 의료 기기 등이 이에 해당합니다.
규제 기관에게 승인받아야 하는 안전성과 신뢰성 케이스가 필요합니다. 따라서 중요 시스템 개발은 시스템이 신뢰할 수 있고, 안전하며, 보안되어 있다는 것을 규제 기관에게 확신시키는 증거를 만들어야 합니다.

Safety regulation

• Regulation and compliance (following the rules) applies to the sociotechnical system as a whole and not simply the software element of that system.
• Safety-related systems may have to be certified as safe by the regulator.
• To achieve certification, companies that are developing safetycritical systems have to produce an extensive safety case that shows that rules and regulations have been followed.
• It can be as expensive develop the documentation for certification as it is to develop the system itself.

Safety regulation
규제와 준수(규칙을 따름)는 시스템 전체에 적용되며, 그 시스템의 소프트웨어 요소에만 적용되는 것이 아닙니다. 안전 관련 시스템은 규제 기관에 의해 안전하다고 인증받아야 할 수 있습니다.
인증을 받기 위해, 안전 중심의 시스템을 개발하는 회사들은 규칙과 규정을 따랐음을 보여주는 광범위한 안전 케이스를 제작해야 합니다. 인증을 위한 문서를 개발하는 것이 시스템 자체를 개발하는 것만큼 비용이 많이 들 수 있습니다. 이는 규제 준수의 복잡성과 중요성을 나타냅니다.

Redundancy and diversity

Redundancy and diversity

• Redundancy
  • Keep more than a single version of critical components so that if one fails then a backup is available.
• Diversity
  • Provide the same functionality in different ways in different components so that they will not fail in the same way.
• Redundant and diverse components should be independent so that they will not suffer from ‘common-mode’ failures
  • For example, components implemented in different programming languages means that a compiler fault will not affect all of them.

Redundancy
중복성은 시스템의 중요한 구성 요소를 하나 이상 보유하는 것을 의미합니다. 이는 만약 한 요소가 실패하더라도 백업이 사용 가능하도록 보장합니다. 예를 들어, 공중 무선 통신망에서는 여러 개의 동일한 데이터 패킷을 전송하여 네트워크에 문제가 발생하더라도 데이터가 손실되지 않도록 합니다.

Diversity
다양성은 다른 구성 요소에서 같은 기능을 다른 방식으로 제공하는 것을 의미합니다. 이로 인해 모든 구성 요소가 동일한 방식으로 실패하지 않게 합니다. 예를 들어, 다른 프로그래밍 언어로 구현된 구성 요소는 컴파일러 오류가 모든 요소에 영향을 미치지 않도록 합니다.

중복과 다양한 구성 요소는 독립적이어야 하므로 '공통 모드' 실패로부터 안전하게 보호됩니다.

Process diversity and redundancy

• Process activities, such as validation, should not depend on a single approach, such as testing, to validate the system.
• Redundant and diverse process activities are important especially for verification and validation.
• Multiple, different process activities the complement each other and allow for cross-checking help to avoid process errors, which may lead to errors in the software.

Process diversity and redundancy
프로세스 활동, 예를 들어 유효성 검사는 테스트와 같은 단일 접근 방식에 의존해서는 안됩니다. 중복 및 다양한 프로세스 활동은 특히 검증 및 유효성 검사에 중요합니다.

각각이 다른 프로세스 활동을 보완하고 교차 검사를 허용하는 여러 프로세스 활동은 프로세스 오류를 피하는데 도움이 되며, 이는 소프트웨어의 오류로 이어질 수 있습니다. 이러한 방법을 통해 시스템의 신뢰성과 안정성을 높일 수 있습니다.

Problems with redundancy and diversity

• Adding diversity and redundancy to a system increases the system complexity.
• This can increase the chances of error because of unanticipated interactions and dependencies between the redundant system components.
• Some engineers therefore advocate simplicity and extensive V & V as a more effective route to software dependability.
• e.g.) Airbus FCS architecture is redundant/diverse; Boeing 777 FCS architecture has no software diversity.

Problems with redundancy and diversity
레드런던시와 다양성을 시스템에 추가하면 시스템 복잡성이 증가합니다. 이로 인해 예상치 못한 상호 작용과 레드런던트 시스템 구성 요소 간의 종속성으로 인해 오류가 발생할 확률이 높아질 수 있습니다. 일부 엔지니어들은 이러한 이유로 간소화와 광범위한 검증 및 유효성 검사(V & V)를 소프트웨어 신뢰성을 향상시키는 더 효과적인 방법으로 주장합니다. 예를 들어, Airbus FCS 아키텍처는 redundant/diverse하며, 반면에 Boeing 777 FCS 아키텍처는 소프트웨어 다양성이 없습니다.

Dependable processes

Dependable processes

• To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process.
• A well-defined repeatable process is one that does not depend entirely on individual skills; rather can be enacted by different people.
• Regulators use information about the process to check if good software engineering practice has been used.
• For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation.

Dependable processes
소프트웨어 결함을 최소화하기 위해서는 잘 정의된, 반복 가능한 소프트웨어 프로세스가 중요합니다. 잘 정의된 반복 가능한 프로세스는 개별 기술에 완전히 의존하지 않는 프로세스입니다; 다른 사람들이 실행할 수 있습니다.

규제 기관은 좋은 소프트웨어 공학 실무가 사용되었는지 확인하기 위해 프로세스에 대한 정보를 사용합니다. 결함 검출을 위해서는, 프로세스 활동이 검증 및 유효성 검사에 상당한 노력을 포함해야 함이 명확합니다. 이는 결함을 발견하고 수정하는 데 중요한 단계이며, 이로 인해 시스템의 전반적인 신뢰성이 향상됩니다.

Dependable process characteristics

• Explicitly defined

  • A process that has a defined process model that is used to drive the software production process.
  • Data must be collected during the process that proves that the development team has followed the process as defined in the process model.

• Repeatable

  • A process that does not rely on individual interpretation and judgment.
  • The process can be repeated across projects and with different team members, irrespective of who is involved in the development.

  Dependable process characteristics

• 명시적으로 정의된

  • 정의된 프로세스 모델을 가진 프로세스로, 소프트웨어 제작 프로세스를 주도합니다.
  • 개발 팀이 프로세스 모델에 정의된 대로 프로세스를 따랐음을 증명하는 데이터를 프로세스 동안 수집해야 합니다.

• 반복 가능한

  • 개별적인 해석과 판단에 의존하지 않는 프로세스입니다.
  • 이 프로세스는 프로젝트 간에, 또는 다른 팀원들과 반복하여 수행할 수 있으며, 누가 개발에 참여하든 간에 이것이 가능합니다.

이러한 특성들은 프로세스가 누가 수행하든지 일관성을 유지할 수 있게 하며, 이를 통해 소프트웨어의 전반적인 신뢰성과 품질이 향상될 수 있습니다.

Dependable process activities

• Requirements reviews to check that the requirements are, as far as possible, complete and consistent.
• Requirements management to ensure that changes to the requirements are controlled and that the impact of proposed requirements changes is understood.
• Formal specification, where a mathematical model of the software is created and analyzed.
• System modeling, where the software design is explicitly documented as a set of graphical models, and the links between the requirements and these models are documented.

Dependable process activities

• 요구사항 리뷰
  • 가능한 한 완전하고 일관된 요구사항을 검토합니다.
• 요구사항 관리
  • 요구사항에 대한 변경이 통제되고, 제안된 요구사항 변경의 영향이 이해되는 것을 보장합니다.
• 형식적 명세
  • 소프트웨어의 수학적 모델을 생성하고 분석합니다.
• 시스템 모델링
  • 소프트웨어 디자인이 그래픽 모델의 세트로 명확하게 문서화되고, 요구사항과 이러한 모델 간의 링크가 문서화됩니다.

이러한 활동들은 프로세스 내에서 신뢰성을 달성하기 위한 중요한 단계들로, 각 단계가 결함을 발견하고 수정하며, 시스템의 전반적인 신뢰성을 향상시킵니다.

Dependable process activities

• Design and program inspections, where the different descriptions of the system are inspected and checked by different people.
• Static analysis, where automated checks are carried out on the source code of the program.
• Test planning and management, where a comprehensive set of system tests is designed.
  • The testing process has to be carefully managed to demonstrate that these tests provide coverage of the system requirements and have been correctly applied in the testing process.

Dependable process activities

• 디자인 및 프로그램 검토
  • 시스템의 다른 설명들이 서로 다른 사람들에 의해 검토되고 확인됩니다.
• 정적 분석
  • 프로그램의 소스 코드에 대해 자동화된 검사가 수행됩니다.
• 테스트 계획 및 관리
  • 체계적인 시스템 테스트 세트가 설계됩니다.
  • 테스팅 프로세스는 시스템 요구사항에 대한 커버리지를 제공하고 테스팅 프로세스에서 올바르게 적용되었음을 보여주기 위해 신중하게 관리되어야 합니다.

이러한 활동들은 소프트웨어의 결함을 찾고 수정하는 데 도움이 되며, 전체 시스템의 신뢰성을 향상시키는 데 기여합니다.

Dependable processes and agility

• Dependable software often requires certification so both process and product documentation has to be produced.
• Up-front requirements analysis is also essential to discover requirements and requirements conflicts that may compromise the safety and security of the system.
• These conflict with the general approach in agile development of co-development of the requirements and the system and minimizing documentation.

Dependable processes and agility

• 신뢰할 수 있는 소프트웨어는 종종 인증을 필요로 하므로 프로세스 및 제품 문서화가 필요합니다.
• 사전 요구사항 분석도 시스템의 안전성과 보안을 위협할 수 있는 요구사항 및 요구사항 간의 충돌을 찾기 위해 필수적입니다.
• 이것들은 애자일 개발의 일반적인 접근법인 요구사항과 시스템의 공동 개발 및 문서화 최소화와 충돌합니다.

이 맥락에서, 애자일 개발 방법론이 신뢰할 수 있는 시스템을 개발하는데 있어 충분하지 않을 수 있다는 의미입니다. 애자일 방법론은 주로 빠른 반복주기와 가변적인 요구사항에 초점을 맞추며, 신뢰성이 높은 시스템에서는 종종 더 많은 계획, 검증, 문서화가 필요하며, 이들은 애자일 방법론의 기본 원칙과 일치하지 않을 수 있습니다. 이러한 차이를 이해하고 적절한 접근법을 선택하는 것이 중요합니다.

Dependable processes and agility

• An agile process may be defined that incorporates techniques such as iterative development, test-first development and user involvement in the development team.
• So long as the team follows that process and documents their actions, agile methods can be used.
• However, additional documentation and planning is essential so ‘pure agile’ is impractical for dependable systems engineering.

Dependable processes and agility
애자일 방법론은 반복적인 개발, 테스트 우선 개발, 사용자의 개발 팀 참여 등의 기법을 포함한 프로세스를 정의할 수 있습니다. 개발팀이 그 프로세스를 따르고 자신들의 행동을 문서화한다면, 애자일 방법을 사용할 수 있습니다.

그러나 추가적인 문서화와 계획이 필수적이므로 '순수 애자일'은 신뢰할 수 있는 시스템 공학에는 실용적이지 않습니다.

이 말은 애자일 방법론을 그대로 적용하면 신뢰할 수 있는 시스템을 개발하는데 부적합하다는 것을 의미합니다. 그 이유는 애자일 방법론이 기본적으로 빠른 변화와 반복에 초점을 맞추어 개발되었기 때문입니다. 반면, 신뢰성이 요구되는 시스템에서는 계획, 검증, 문서화와 같은 요소들이 중요합니다. 따라서 이런 시스템을 개발할 때는 애자일 방법론의 일부를 채택하되 추가적인 문서화와 계획이 반드시 포함되어야 합니다.

즉, 애자일 방법론을 적용하되, 추가적인 문서화와 계획을 통해 신뢰성을 달성할 수 있도록 해야 합니다. 이렇게 조정된 방식을 사용하면, 개발 속도와 유연성을 유지하면서도 신뢰성을 달성할 수 있습니다.