반응형
제목: Development of a Software Design Error Taxonomy: A Systematic Literature Review
저자: Tushar Agrawal, Gursimran Singh Walia, Vaibhav K. Anu
유형: 저널페이퍼, 총 21페이지, 2024년 4월
https://link.springer.com/article/10.1007/s42979-024-02797-2
이 논문은 소프트웨어 엔지니어링 문헌(2000년 이후 출판물)에 보고된 소프트웨어 설계 문제에 대한 체계적 조사를 통해 16건의 소프트웨어 설계 에러를 식별하고 분류하였다. 각 설계 에러에 대해 설명하기 위해 소매업 주문 관리 시스템(Order Management System: OMS)을 예로 들었고, 아래 3가지 용어를 구분하여 설명을 제시했다.
- 에러(ERROR): 소프트웨어 설계 결함 및 실패의 근본 원인이다. 소프트웨어 설계 과정의 문제 해결, 계획 또는 실행에서 발생하는 인간의 인지 오류 또는 프로세스 실패를 의미한다.
- 결함(FAULT): 소프트웨어 아티팩트에 기록된 에러의 징후이다. 결함을 식별하고 수정하지 않으면 소프트웨어 실패로 이어질 수 있다.
- 실패(FAILURE): 소프트웨어 시스템의 잘못된 실행, 예를 들어 예상치 못한 작동이나 잘못된 출력으로 인한 시스템 크래시 등을 의미한다.
하나의 ERROR가 여러 FAULT를 일으킬 수 있고, 마찬가지로, 하나의 FAULT가 여러 ERROR의 결과일 수 있다.
소프트웨어 설계 에러 분류
저자들은 문헌 검토 과정에서 발견한 설계 에러를 다음 4개의 상위 카테고리별로 그룹화하였다.
- 인지 부하 에러(Cognitive load errors): 설계자의 생리적 상태로 인해 발생. 소프트웨어 설계 과정에서 설계자가 겪는 스트레스나 피로가 이러한 에러로 이어질 수 있다.
- 지식 기반 에러(Knowledge-based errors): 계획 단계에서 지식 인식 부족과 관련. 설계자가 충분한 지식을 갖추지 못해 소프트웨어 설계에 결함을 초래할 수 있는 계획을 수립한다.
- 조직 영향 에러(Organizational influence errors): 상위 관리자의 지원과 압박 부족으로 인해 발생. 조직 변화로 인한 중단이나 지연, 마감일 임박, 시간 부족으로 인한 질낮은 설계도 이러한 에러의 원인일 수 있다.
- 프로세스 에러(Process errors): 일상적인 작업을 준수하지 않거나 소프트웨어 엔지니어링 프로세스를 준수하지 않을 때 발생. 소프트웨어 설계자는 긴급성과 필요성에 따라 목표를 달성하기 위해 표준 프로세스에서 벗어나는 경향이 있다.
| 에러 카테고리 | 소프트웨어 설계 에러명 |
| 인지 부하 에러 | 준비 부족 설계 요소 간과 요구사항 명세서 번역 중 사무적 오류 이해관계자 정보 손실 |
| 지식 기반 에러 | 비즈니스 도메인 및 관련 프로세스에 대한 지식 부족 도구 관련 지식 부족 소프트웨어 설계 표준 및 기술 노하우에 대한 지식 부족 타사 제품 선택 시 제한된 합리성 이해관계자의 의견/문제에 대한 잘못된 가정 |
| 조직 영향 에러 | 소프트웨어 설계에 필요한 자원 부족 (소프트웨어 설계 관련) 교육 부족 상위 경영진의 기능적 고착성(고정된 사고방식) 마감일 임박으로 인한 시간적 압박 팀 내 의사소통 오류/오해 |
| 프로세스 에러 | 설계 문서 작성 시 프로세스 준수 부족 수리 또는 유지보수 활동에서 함께 발생 |
인지 부하 에러(Cognitive load errors)
| 설계 에러명 | 설명 | ERROR 예 | FAULT 예 | FAILURE 예 |
| 준비 부족 | 소프트웨어 설계자가 충분한 준비 없이 이해관계자들과의 설계 논의에 참석하였다. 준비 부족으로 설계 중인 시스템에 대한 관련 질문을 하지 못했고, 결과적으로 설계자는 잘못된 설계를 초래했다. | 레가시 주문 프로세스(스프레드시트)에는 수년간의 주문 데이터가 저장되어 있었다. 설계자는 피로로 인해 기존 프로세스에 대한 질문을 준비하지 않았고, 사용자가 새로운 주문 관리 시스템(OMS)에서 이전 주문을 조회해야 하는지 여부를 묻지 않았다. 결과적으로 설계자는 스프레드시트의 과거 데이터를 OMS에 로드하는 프로세스를 설계하지 않았다. | 소프트웨어 설계자는 과거 주문 데이터를 새로운 형식으로 변환하고 새 시스템에 로드하기 위한 플로우차트와 프로세스 맵을 작성하지 않았다. 개발팀은 관련 설계 아티팩트 결여로 과거 주문 조회 모듈을 구현하지 않았다. | 시스템 시작 당시 애플리케이션은 빈 데이터베이스로 시작되었으며, 이전 시스템의 주문 정보가 없었다. 사용자가 이전 주문에 대한 문의나 업데이트를 위해 스프레드시트에 저장된 이전 데이터를 참조해야 했기 때문에, 사업팀은 레거시 프로세스를 폐기할 수 없었다. |
| 설계 요소 간과 | 소프트웨어 설계자는 부주의나 스트레스로 인해 설계 요소의 하위 수준 세부 사항(예: 클래스 다이어그램에서 객체 간 관계 또는 객체의 속성)을 잊거나 놓치는 경우가 많다. | 구매자는 이메일이나 우편으로 할인 쿠폰 코드를 받는다. 설계자는 쇼핑 카트와 다른 객체 간의 관계가 너무 많아 OMS 시스템 설계에서 쇼핑 카트와 쿠폰 코드 간의 관계를 명시하지 않았다. 따라서 쿠폰이 쇼핑 카트 워크플로에 포함되지 않았다. | 쇼핑 카트 설계에 쿠폰 검증 및 처리를 위한 프로세스 흐름도가 제공되지 않았다. 개발자는 쇼핑 카트나 결제 페이지에 쿠폰 코드를 입력하는 기능을 제공하지 않았다. | 구매자는 쿠폰 코드를 사용하여 구매 할인을 받을 수 없었다. 필요한 경우 할인을 받으려면 콜센터에 전화해야 했다. |
| 요구사항 명세서 번역 중 사무적 오류 | 소프트웨어 설계자는 소프트웨어 설계 아티팩트를 생성하거나 업데이트하기 위해 요구사항을 참조한다. 설계자가 요구사항을 설계로 변환할 때 주의하지 않으면 표기 오류가 발생하여 올바른 요구사항을 잘못 옮길 수 있다. | 요구사항에는 국내 주문과 해외 주문에 대해 서로 다른 운송업체가 지정되어 있었다. 설계자가 요구사항을 번역할 때 주의하지 않아 국내 배송업체와 해외 배송업체의 설계에 차이가 없었다. | 국제 배송 프로세스는 일반적으로 국내 배송 프로세스와 다르다. 국제 배송 통합 인터페이스에는 세관 추적을 위한 추가 요구사항이 있다. 번역 오류로 인해 설계자는 운송업체를 구분하지 않았고, 해당 애플리케이션은 국제 배송업체 프로세스의 추가적인 통합 요구사항을 지원하지 않았다. | 한 국가에서 다른 국가로 물품을 배송하려면 국제 운송업체의 추가 점검과 잔액이 필요하다. 국제 주문은 적절한 통합 부족으로 인해 배송 과정에서 더 이상 진행되지 않았다. |
| 이해관계자 정보 손실 | 이러한 오류는 설계자가 이해관계자로부터 받은 정보를 잘못 보관하거나 잊어버릴 때 발생한다. 정보 손실로 인해 설계자는 충분한 세부 정보 없이 설계를 작성하게 되고, 이는 소프트웨어 설계 결함으로 이어질 수 있다. | 소매업체는 일반적으로 여러 공급업체로부터 제품을 구매하여 최종 소비자에게 판매한다. 이해관계자들은 각 제품이 고객에게 판매할 때와 공급업체에서 구매할 때 각각 다른 부품 번호를 가지고 있다고 논의했다. 솔루션 설계자는 모든 제품이 두 개의 부품 번호를 가지고 있다는 사실을 적절히 기록하지 않았다. | 소프트웨어 설계자는 모든 품목의 판매 품목 번호와 공급업체 품목 번호 간의 매핑이 있어야 한다는 사실을 간과했다. 설계자는 클래스 다이어그램의 품목 객체와 공급업체 관련 정보 간의 연결을 생성하지 않았다. 이 설계에 따른 소프트웨어 구현은 품목을 소스 공급업체와 연결할 방법이 없다. | 결함 있는 품목의 반품을 해당 품목을 공급한 공급업체와 연결할 수 없었다. 시스템은 공급업체 정보와 품목 간의 매핑을 이해하지 못해 공급업체 정보를 제공하지 못하고, 창고 운영팀은 결함 있는 반품을 어디로 보내야 할지 알지 못한다. 이 재고는 폐기품이며 소매업체에 재정적 손실을 초래한다. |
지식 기반 에러(Knowledge-based errors)
| 설계 에러명 | 설명 | ERROR 예 | FAULT 예 | FAILURE 예 |
| 비즈니스 도메인 및 관련 프로세스에 대한 지식 부족 | 소프트웨어 설계자가 비즈니스 도메인과 관련 프로세스를 이해하지 못할 수 있다. 따라서 설계자는 주문 접수 또는 주문 반품/교환과 같은 비즈니스 프로세스를 지원하는 소프트웨어 워크플로를 설계하는 방법을 알지 못한다. | 소프트웨어 설계자는 소매업 주문 관리에 대한 도메인 지식이 부족하여 품목 교환 프로세스를 단일 거래 프로세스로 이해하지 못했다. 교환은 고객이 품목을 반품한 후, 동일하거나 다른 품목으로 교체하는 것을 포함한다. | 소프트웨어 설계자는 교환 프로세스에 대한 프로세스 맵을 거래 관점에서 2단계 프로세스로 작성했다. 먼저 사용자는 품목을 반품하여 환불을 받고, 나중에 새 판매로 교체 품목을 구매해야 한다. 구현 팀은 교환을 단일 거래로 만드는 대신 이 문서화된 설계를 준수했다. | 일반적으로 고객은 교환이 단일 거래로 이루어지기를 기대한다. 단일 거래를 통해 고객은 반품 품목의 환불을 교체 품목의 구매 가격에 사용할 수 있고, 가격 차액만 지불하면 된다. 그러나 2단계 프로세스에서 고객은 구매 시점에 교환 상품에 대한 비용을 지불해야 하고, 시스템은 반품을 별도의 거래로 처리한다. |
| 도구 관련 지식 부족 | 이러한 유형의 소프트웨어 설계 오류는 소프트웨어 설계자가 소프트웨어 설계 도구를 처음 사용하거나 설계 도구, 사용법 및 한계를 이해하지 못할 때 발생한다. | 소프트웨어 설계자가 클래스 다이어그램 작성을 위해 주어진 UML 도구를 사용하는 방법을 몰랐다. | 소프트웨어 설계자는 주문 관리 시스템에서 여러 객체 클래스 간에 적절한 관계를 설정하지 않았다. 설계자는 주문과 결제 방법 간에 1:n 관계가 아닌 1:1 관계를 설정했다. 따라서 소프트웨어 구현은 단일 주문에 대해 여러 결제 방법을 지원하는 것을 고려하지 않았다. | 고객은 구매 시 기프트 카드를 사용하는 경우가 있다. 고객은 시스템이 먼저 기프트 카드를 사용하고 잔액을 고객 신용카드로 결제할 것으로 예상한다. 그러나 한가지 결제 방법만 허용되었기 때문에 사용자는 신용카드로 결제하거나 기프트 카드에 주문 금액을 결제할 수 있는 충분한 잔액이 있어야 한다. |
| 소프트웨어 설계 표준 및 기술 노하우에 대한 지식 부족 | 이 소프트웨어 설계 오류는 설계자가 설계 과정에서 소프트웨어 설계 표준이나 모범 관행(best practices)을 이해하지 못할 때 발생한다. | 소프트웨어 설계자가 엔터프라이즈 소프트웨어 애플리케이션의 성능 측면을 이해하지 못했다. 주문 관리 시스템은 연중 시기, 프로모션 등에 따라 대량의 데이터를 수집한다. 데이터베이스에서 대량의 데이터를 쿼리/패치하면 성능 문제가 발생하여 시스템 응답 속도가 느려질 수 있다. 설계자는 충분한 성능 분석 없이 OMS가 주문 히스토리를 가져오도록 설계했다. | 소프트웨어 설계자는 OMS 객체에 대한 다양한 오퍼레이션에 대해 최적의 성능을 계획하지 않았다. 주문 히스토리 가져오기에서 시간 경과에 따라 데이터가 증가할 때 페이지화(pagination)를 고려하지 않았다. 따라서 개발자는 주문 히스토리 데이터를표시할 때 여러 페이지 뷰로 나뉘도록 구현하지 않았다. | 페이지화 결여로 인해 주문 수가 증가함에 따라 주문 히스토리 페이지에서 시스템의 응답 속도가 느려졌다. 주문이 계속 데이터베이스를 채우고 있었기 때문에 데이터베이스가 더 나은 성능을 제공할 만큼 빠르게 응답하지 못했다. |
| 타사 제품 선택 시 제한된 합리성 | 설계 중인 소프트웨어와 번들로 제공되는 타사 제품 및 라이브러리 간의 호환성을 검증하기 위해서는 상세한 분석과 개념 증명이 필요하다. 이러한 유형의 소프트웨어 설계 오류는 소프트웨어 솔루션 설계 과정에서 심층 분석 없이 다른 제품을 포함하거나, 관련 설명서를 읽지 않고 타사 제품/라이브러리를 번들로 제공할 때 발생한다. | 주문 접수 시 사용자가 상품 배송을 위한 유효한 주소를 입력하는지 확인하기 위해 우편 주소 검증이 필요하다. 설계자는 타사 주소 검증 서비스 제공업체를 선정하여 철저한 분석 없이 설계에 포함시켰다. | 소프트웨어 설계자는 고객이 입력한 모든 우편 주소가 항상 검증되도록 사용자 프로필 및 결제 페이지 디자인을 제작했다. 이 설계를 기반으로 개발자는 OMS 애플리케이션을 타사 우편 주소 검증 서비스와 통합했다. | 이 주소 검증 서비스는 미국 주소에 대한 데이터 검증만 제공했으며, 해외 주소에 대한 검증은 제공하지 않았다. 미국 이외의 국가를 선택하는 경우 사용자는 주소 필드에 아무 정보나 입력할 수 있다. |
| 이해관계자의 의견/문제에 대한 잘못된 가정 | 소프트웨어 설계자는 비즈니스 이해관계자와 인터액션하여 소프트웨어 설계 프로세스를 완성한다. 이러한 인터액션 과정에서 설계자는 이해관계자의 기대를 잘못 해석할 수 있다. 이러한 유형의 오류는 소프트웨어 설계자가 이해관계자의 관점/의견에 대해 이해관계자와 명확히 논의하지 않고 특정 가정을 할 때 발생한다. | 기존 비즈니스 프로세스에서는 품목의 재고가 없는 경우 새 재고가 배송 창고에 도착할 때까지 해당 주문은 백오더로 간주된다. 이것이 주문 발송을 지연시키므로, 비즈니스 이해관계자들은 새로운 OMS를 통해 공급업체가 고객에게 직접 배송(드롭 쉬핑)할 수 있도록 개선하고자 했다. 그러나 소프트웨어 설계자는 이 프로세스가 동일하게 유지될 것이라고 가정했다. | 소프트웨어 설계자는 백오더 품목을 처리하기 위해 공급업체와 자동으로 드롭 쉬핑 주문을 생성하는 드롭 쉬핑 플로차트와 프로세스 맵을 만들지 않았다. 드롭 쉬핑 기능이 있었다면 공급업체는 고객에게 직접 품목을 배송할 수 있었을 것이다. 개발자는 시스템에 그러한 기능을 만들지 않았다. | 시스템은 주문을 공급업체로 라우팅하지 않고 백오더를 생성한다. 구매팀은 백오더 목록을 검토하고 공급업체와 수동으로 주문을 생성한다. 이러한 수동 프로세스로 인해 주문 처리가 지연된다. 성수기에 주문량이 증가하면 구매팀은 추가 작업을 수행해야 한다. |
조직 영향 에러(Organizational influence errors)
| 설계 에러명 | 설명 | ERROR 예 | FAULT 예 | FAILURE 예 |
| 소프트웨어 설계에 필요한 자원 부족 | 상위 경영진은 조직 방향 및 정책 변화에 따라 의사 결정을 하고, 이는 하드웨어 및 인적 자원과 같은 물리적 자원에 영향을 미친다(예: 비용 절감이나 해고). 가용 자원의 이러한 변화가 발생하면 소프트웨어 설계 품질에 영향이 있다. | 경영진은 조직 내 비용 절감으로 인해 직원들에게 임금 인상 및 보너스를 지급하지 않았다. 팀의 소프트웨어 엔지니어들은 더 나은 기회와 특전을 찾아 회사를 떠났다. 나머지 팀원들은 압박 속에서 증가된 업무량을 감당해야 했다. | 설계자가 주문 관리 시스템 설계의 인터페이스 사양에서 세부 사항을 누락했고, 유스케이스 설계 문서에 부정적인 테스트 케이스를 명시하지 않았다. 개발자는 설계를 기반으로 소프트웨어를 구현했지만 모든 가능한 검증사항에 대한 단위 테스트를 하지 않았다. | 사용자 인터페이스는 주문 결제 시 해당 품목의 재고를 예약하지 않았다. 주문 수가 가용 재고를 초과하면서 약속된 재고 부족으로 인해 창고에서 주문이 취소되는 경우가 증가했다. |
| 교육 부족(소프트웨어 설계 관련) | 조직마다 업무 문화가 다르다. 어떤 조직은 학습 문화가 없거나 비용 절감 조치로 인해 기술 개발을 장려하지 않는다. 적절한 교육 프로세스 부재로 소프트웨어 설계자가 고품질 소프트웨어 설계를 개발하는 데 필요한 기술이 부족할 수 있다. | 소프트웨어 설계자가 시스템 컨텍스트 및 통합 프로세스 맵을 적절하게 작성하지 않았다. 설계자는 관련 교육 과정에 참석하여 기술을 개발하지 않았다. | 소프트웨어 설계자가 시스템 워크플로 다이어그램을 제대로 작성하지 않았다. 이 불완전한 설계 아티팩트는 기록 시스템 또는 품목 기록 및 관련 속성을 처리하는 시스템을 명시하지 않았다. | 시스템이 기록 시스템(제품 마스터)과 통합되어 있지 않다. 소스 제품 마스터와 OMS는 판매를 위한 품목 데이터를 보유하고 있어야 한다. 분리되고 이질적인 시스템들이 품목 데이터의 두 가지 사일로를 생성하여 데이터 불일치를 초래했다. |
| 상위 경영진의 기능적 고착성(고정된 사고방식) | 상위 경영진은 기본 소프트웨어 설계에 직접적인 영향을 미치는 제품 및 서비스 관련 기능적 결정을 내린다. 영업 및 마케팅을 중심으로 한 사업 전략이 이러한 경영진 차원의 결정을 좌우한다. 소프트웨어 설계자는 일반적으로 이러한 조직 전략 결정에 대한 자문을 요청받지 않는다. 따라서 소프트웨어 설계자는 고정적이고 경직된 사업 전략을 기반으로 설계를 구축해야 하며, 이는 종종 소프트웨어 설계의 결함으로 이어진다. | 상위 경영진은 전자상거래와 고객 서비스라는 두 가지 소프트웨어 제품을 시장에 출시하기로 결정했다. 전자상거래는 셀프 서비스 채널이지만, 고객 서비스는 담당자(CSR)가 해당 소프트웨어를 사용하여 전화나 이메일로 주문을 받는다. CSR은 고객의 변경, 반품, 환불 등도 지원한다. 소프트웨어 설계자는 소프트웨어 수명 주기, 라이선스 등의 문제로 인해 동일한 모듈을 재사용하는 대신 주문 관리 프로세스를 위한 두 개의 병렬 모듈을 개발했다. | 소프트웨어 설계자는 소프트웨어 수명 주기가 서로 독립적인 두 개의 독립적인 소프트웨어 제품을 개발하기 위해 OMS 설계에 중복성을 도입해야 했다. 두 개발팀은 그다지 공통 부분 없이 설계 작업을 진행했으며 모듈을 재사용하지 않았다. | 사용자가 문제를 보고하기 위해 전화를 걸면 CSR은 최종 사용자의 화면과 CSR의 화면이 서로 다르고 정보도 다르기 때문에 문제를 확인할 수 없다. 주문 등록에서 문제가 생길때마다 개발자는 두 모듈(최종 사용자 모듈과 CSR 모듈) 모두에서 문제를 해결해야 한다. 설계자는 두 모듈을 유사한 컴포넌트와 화면을 사용하여 설계할 수 있었다. 그러면 팀은 문제가 발생한 컴포넌트에서 문제를 해결하여 이중 작업을 피할 수 있다. |
| 마감일 임박으로 인한 시간 압박 | 소프트웨어 설계자들은 마감일 임박이나 예산 감축으로 인해 고위 경영진으로부터 지속적인 압박을 받는다. 이 경우 소프트웨어 설계자들은 전체적인 그림을 보지 못하거나 특정 설계 요소를 놓칠 수 있다. 이는 결함이 포함된 품질 낮은 소프트웨어 설계로 이어질 수 있다. | 마감일 임박에 신경쓰던 소프트웨어 설계자가 사용자 계정 보안을 유지하기 위해 일정 기간마다 사용자가 비밀번호를 업데이트하도록 강제하는 프로세스를 설계하지 않았다. | 소프트웨어 설계자는 비밀번호의 마지막 변경을 확인하고 비밀번호가 만료된 경우 사용자에게 알리는 백그라운드 프로세스를 문서화하지 않았다. 개발팀은 비밀번호를 최신 상태로 유지하기 위해 사용자가 비밀번호를 변경하도록 강제하는 시스템을 프로그래밍하지 않았다. | 구매자가 영원히 만료되지 않는 비밀번호를 사용할 수 있다. 영구 비밀번호를 사용하면 시스템의 보안이 약화되고 취약해질 수 있다. |
| 팀 내 의사소통 오류/오해 | 소프트웨어 설계자는 소프트웨어 설계를 완료하기 위해 소프트웨어의 영향을 받는 여러 비즈니스 기능(예: 영업, 마케팅, 조달, 재무 등) 및 지원팀의 이해관계자와 소통해야 한다. 소프트웨어가 프로세스를 완료하기 위해 다른 애플리케이션과 연동해야 하는 경우, 여러 팀과의 원활한 소통이 필수적이다. 소프트웨어 설계자가 팀 내부 또는 다른 팀과 설계 관련 사양이나 프로세스를 제대로 전달하지 못하면 오류가 발생할 수 있다. | 온라인 주문의 결제 수단 중 하나는 PayPal이었다. PayPal 팀은 OMS와의 인터페이스에 필요한 어떠한 변경도 약속하지 않았다. 설계자는 개념 증명(proofs-of-concept)을 수행하기 위해 개발팀 내에서 PayPal과의 인터페이스를 만들겠다는 작업계획을 전달하지 않았다. | 설계자는 주문 결제 수단으로 PayPal 결제를 지원하도록 OMS를 설계했다. 설계자는 PayPal 팀과 세부적인 통합 설계에 대해 논의했다. 그러나 설계자는 개발팀에 세부 사항을 전달하지 않았다. | 설계자는 OMS 사용자가 PayPal을 또다른 결제 수단으로 사용할 수 있도록 의도했다. OMS와 PayPal은 사용자에게 통합된 사용 경험을 제공하기 위해 매끄럽게 통합되어야 한다. 그러나 개발자들은 PayPal과 통합하기 위해 팝업 화면을 사용하는 등 불편한 사용자 경험을 만들어냈다. 결제 프로세스에서 여러 번의 클릭이 필요했고 모바일 친화적이지 않았다. |
프로세스 에러(Process errors)
| 설계 에러명 | 설명 | ERROR 예 | FAULT 예 | FAILURE 예 |
| 설계 문서 작성 시 프로세스 준수 부족 | 소프트웨어 설계 프로세스 중에 설계자가 충분히 상세한 문서를 작성하지 않을 때 발생한다. | 데이터 객체마다 데이터 필드에 대한 검증 유형이 다르다. 일부 규칙은 간단하지만 복잡한 규칙도 있어서 개발자의 특별한 주의가 필요하다. 설계자가 특정 데이터 타입의 여러 객체의 속성에 대한 데이터 검증 규칙을 문서화하지 않았다. | 소프트웨어 설계자가 설계 표준인 유효성 검사를 포함하지 않았다. 예를 들어 설계 아티팩트에 이메일 주소 검증 및 전화번호 형식 검증 규칙을 명시하지 않았다. 이러한 데이터는 주소 및 개인 정보의 일부이며, 사용자가 주문 관리 시스템에서 입력 시 그 유효성을 검사해야 한다. | 주문 화면에서 사용자는 @ 기호 없는 잘못된 이메일 주소와 선택 국가에 맞지 않는 형식의 전화번호를 입력할 수 있었다. 개발자는 이메일을 문자열 필드로 전화번호를 숫자 필드로 처리했는데, 이는 설계자가 유효성 검사 기준을 문서화하지 않았기 때문이다. 잘못된 이메일 형식으로 인해 주문 확인 이메일 프로세스에서 고객에게 이메일을 전송하지 못했다. |
| 수리 또는 유지보수 활동과 함께 도입됨 | 소프트웨어 설계자는 새로운 유스케이스를 위해 기존 설계를 기반으로 재설계하거나 새로운 설계를 개발해야 하는 경우가 많다. 설계자는 변경 영향 분석을 수행하여 전체 소프트웨어 솔루션과 프로세스에 미치는 영향을 평가해야 한다. 소프트웨어 설계자가 상세한 분석 없이 다른 설계 문제를 해결하는 과정에서 새로운 오류가 도입될 수 있다. | 설계자는 처음에 로그인을 위한 고유한 "User-ID"라는 개념을 사용하여 애플리케이션을 설계했다. 이를 통해 사용자는 서로 다른 로그인으로 여러 계정을 생성할 수 있었다. 사용자 보고서에 따르면, 고객들은 동일한 이메일 주소로 서로 다른 User-ID를 사용하여 여러 사용자 계정을 생성했다. 설계자는 사용자가 로그인에 "전체 이메일 주소"를 입력하도록 하여 이 문제를 해결하려고 했다. | 설계자는 처음에 클래스 다이어그램에 고유한 User-ID 속성을 사용하여 사용자 정보 클래스를 설계했다. 이메일은 사람마다 고유하므로, 설계자는 사용자 ID로 이메일을 사용하도록 수정했다. 하지만 설계자는 사용자 객체에서 이메일 속성을 제거하지 않았고고 중복성이 도입되었다. | 두 개의 이메일 필드(사용자 ID용 하나와 이메일용 하나)로 인해 사용자는 등록 과정에서 이메일을 두 번 입력해야 했다. 일부 사용자는 두 개의 다른 이메일 주소를 입력하기도 했다. 사용자 ID는 편집할 수 없는 필드였기 때문에 사용자는 이메일을 업데이트할 수 없었다. |
반응형
'개발생명주기단계별 > 설계_설계 V&V' 카테고리의 다른 글
| 영상자료 - 상태 기반 테스팅 기법 (0) | 2021.11.01 |
|---|---|
| 문서요약 - UML 테스팅 프레임워크 by Pudipeddi (0) | 2019.10.03 |
| 문서요약 - 구조적 워크쓰루 프로세스 가이드 by DHS (0) | 2019.07.10 |
| 문서요약 - 객체 지향 설계 인스펙션을 위한 리딩 기법 by Travassos (0) | 2019.05.20 |
| 설계 인스펙션 체크리스트 by Software Quality Consulting (0) | 2019.05.16 |