Krononberg

Design Validation Issues 본문

개발 로그/기록장

Design Validation Issues

k._. 2023. 9. 8. 12:57

1. Independence of Validators (검증자의 독립성):
    - 검증자의 독립성은 디자인 검증의 효율성과 신뢰성을 보장하기 위해 중요합니다.
    - 독립적인 검증자는 설계자의 편견 없이 작업을 평가할 수 있으며, 이로 인해 누락되거나 간과된 문제점을 보다 쉽게 식별할 수 있습니다.
    - 반대로, 설계자와 너무 밀접하게 연결된 검증자는 중요한 문제점을 놓칠 수 있습니다.

2. Dependence on Design Method (설계 방법에 대한 의존성):
    - 특정 설계 방법에 너무 많이 의존할 경우, 그 방법의 제한사항이나 단점이 검증 과정에 영향을 미칠 수 있습니다.
    - 다양한 설계 방법론과 도구를 사용하는 것이 좋으며, 상황에 따라 가장 적합한 방법을 선택하는 것이 중요합니다.

3. On-going versus After-the-fact (진행 중인 검증 vs. 사후 검증):
    - 디자인 프로세스 내에서 검증을 지속적으로 수행하는 것은 초기 단계에서 문제를 식별하고 수정하는 데 도움이 됩니다.
    - 그러나 사후 검증도 중요하며, 이를 통해 전체 설계 프로세스를 통해 누락되거나 간과된 문제점을 찾아낼 수 있습니다.
    - 모든 단계에서의 균형 잡힌 검증 접근법이 효과적인 결과를 가져올 수 있습니다.

4. Architectural versus Detail Design (아키텍처 설계 vs. 상세 설계):
    - 아키텍처 설계: 소프트웨어 또는 시스템의 고수준 구조를 정의합니다. 주요 구성 요소, 모듈 및 이러한 요소 간의 관계를 설명합니다. 이것은 전체 시스템의 '빅 픽처'를 제공합니다.
    - 상세 설계: 각 구성 요소나 모듈의 내부 구조와 동작을 정밀하게 정의합니다. 알고리즘, 데이터 구조 및 인터페이스와 같은 세부 사항을 포함합니다.

5. Functional Behavior versus Non-functional Constraints (기능적 행동 vs. 비기능적 제약 사항):
    - 기능적 행동: 시스템이 어떤 기능을 수행해야 하는지에 관한 것입니다 (예: 사용자 인증, 데이터 저장 등).
    - 비기능적 제약 사항: 시스템의 성능, 안정성, 보안성과 같은 특성을 설명합니다. 이것은 시스템이 어떻게 동작해야 하는지에 대한 요구 사항입니다.

6. Specification/What versus Design/How (명세서/무엇 vs. 설계/어떻게):
    - 명세서 (What): 시스템이 무엇을 해야 하는지에 대한 요구 사항을 정의합니다.
    - 설계 (How): 시스템이 이러한 요구 사항을 어떻게 만족시킬 것인지에 대한 구체적인 해결책 및 접근 방식을 설명합니다.

7. Application Specificity (애플리케이션 특정성):
    - 일부 설계 접근법은 특정 애플리케이션 또는 도메인에 맞춰져 있을 수 있습니다. 
    - 반면, 다른 접근법들은 보다 범용적이거나 여러 애플리케이션에 적용될 수 있습니다.
    - 애플리케이션의 특정성을 고려하면 해당 애플리케이션에 가장 적합한 설계 방법론과 도구를 선택할 수 있습니다.

'개발 로그 > 기록장' 카테고리의 다른 글

Information Hiding  (0) 2023.09.08
software architecture - Coupling & Cohesion  (0) 2023.09.08
소프트웨어 디자인 approach  (0) 2023.09.08
Software design이란?  (0) 2023.09.08
Viewport란?  (0) 2023.09.08