[자격증] 정보처리기사 실기 : 3강 요구사항 확인 (분석모델 확인하기)

 정보

• 업무명     : 정보처리기사 실기 : 2강 요구사항 확인 (분석모델 확인하기)

• 작성자     : 이상호

• 작성일     : 2020-05-09

• 설   명      :

• 수정이력 :

 

 

 내용

[분석모델 검증]

[1] 분석모델검증

• 1. 검증 방법 

  • 한국정보화진흥원의  "정보시스템 감리지침: 시스템 개발사업 객체지향 컴포넌트 모델 V1.0” 에서 사업유형이 시스템 개발, 감리 시점이 요구 분석, 감리 영역이 응용시스템인 경우 “유스케이스 모형 상세화 수준 및 적정성”과 “개념 수준의 분석클래스 도출”에 관한 점검 항목을 기준으로 검증하고 감리 시점이 분석 설계, 감리 영역이 응용시스템인 경우 “유스케이스로부터 분석 클래스 도출 및 상세화”에 관한 점검항목을 기준으로 검증한다. 

 

• 2. 유스케이스 모델 검증

  • 한국정보화진흥원의 정보시스템 감리지침에서는 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성에 대하여 다음과 같은 사항을 점검하도록 하고 있다. 

 

• 3. 개념 수준의 분석 클래스 검증

  • 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검해야 한다. 

  • 주요 점검 항목은 다음과 같다. 

    • 개별 유스케이스 단위로 작성하지 않고 시스템 전체를 대상으로 작성하였는가? 

    • 중요도가 높은 요구사항 또는 유스케이스에 필요한 엔터티 클래스가 도출되었는가? 

    • 도출된 클래스 이름과 설명이 이해관계자 간에 이견이 발생하지 않도록 명확한가? 

    • 클래스의 속성은 도출하였는가? 도출된 속성의 이름과 설명이 명확한가? 

    • 클래스들 간에 순환적 관계가 불필요하게 정의되어 있는가? 

    • 클래스 간의 관계에서 다중성(Multiplicity)이 정의되었는가?

 

• 4. 분석 클래스 검증 

  • 유스케이스마다 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토한다. 

  • (1) 유스케이스 실현(Realization)에 필요한 분석 클래스 도출 확인 

    • (가) 하나의 유스케이스를 실현하기 위하여 3개 이상의 클래스가 역할(Role) 기준으로 도출되어야 하며,  유스케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있다. 

    • (나)  유스케이스별로 도출된 분석 클래스들이 역할(Role) 기준으로 경계(Boundary), 엔터티(Entity), 제어(Control) 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인한다. 

 

• 유스케이스  이벤트 흐름에 따라 다르지만 일반적으로 유스케이스 당 1개의 제어 클래스가  존재하고, 연결된 액터마다 1개의 경계 클래스가 존재하는지 확인한다. 

 

• (2) 경계(Boundary)와 제어(Control) 클래스의 도출 여부 및 상세화 정도 확인 유스케이스 실현에 필요한 분석 클래스들이 도출되었는지 확인하기 위하여,  유스케이 스 단위로 분석 클래스를 확인한다. 

 

• (3) 클래스 간의 관계, 클래스 정보의 상세화 정도 확인

 

 

 

[분석모델의 시스템화 타당성 분석]

[1] 분석모델의 기술적 타당성 검토

• 유스케이스 모델의 개별  유스케이스에 대한 분석모델을 작성한 이후,  해당 분석모델로 시스템을 개발하는 경우에 어떠한 영향을 미치는지 필요한 자원,  상호 운용성, 시장성숙도, 기술적 위험 분석 측면에서 타당성을 조사한다.

 

• 성능 및 용량

  • 요구사항을 만족시키기 위한 분석모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원을 식별한다. 

  • 분석 클래스에서 불필요하고 지나치게 많고 속성들을 포함시키게 되면 객체 생성 시 시스템의 메모리 자원을 많이 요구하게 되며, 이로 인한 JVM 에서 과도한 가비지컬렉션(Garbage Collection)이 발생하여 전체 시스템의 성능 저하가 빈번히 발생한다.

• 시스템 간 상호 운용성

  • 분석모델을 이용하여 보다 구체적으로, 시스템 간 상호 정보 및 서비스를 교환 가능한지 검토한다. 

  • 분석모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대해서 확인한다.

• 시장 성숙도 및 트렌드 부합성

  • 분석모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합하는지 확인한다. 

  • 예를 들어, 시스템에서 중요하고 빈번하게 사용되는 클래스를 Spring의 프로토타입 빈(Prototype Bean)으로 사용할 것을 가정하고 분석모델이 작성 되지 않았는지 검토한다. 

• 기술적 위험 분석

  • 분석모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인한다. 

  • 분석모델이 검증되지 않은 기술의 사용을 가정으로 하고 있어 추가적인 비용 발생 가능성이 있는지 확인한다. 

  • 분석모델을 구현하기 위하여 특정 업체 기술, 특허, 라이선스에 의존해야 하는지 확인한다.

 

[연습문제]

• 분석모델검증절차에 포함 되지 않는 것은? 

  • 요구 사항 정의

  • 유스케이스 모델 검증

  • 개념수준 분석 클래스 검증

  • 분석 클래스 검증

 

• 개념 수준의 분석 클래스 검증의 항목이 아닌 것은? 

  • 개별 유스케이스 단위로 작성하지 않고 시스템 일부를 대상으로 작성하였는가?  

  • 중요도가 높은 요구사항 또는 유스케이스에 필요한 엔터티 클래스가 도출되었는가? 

  • 도출된 클래스 이름과 설명이 이해관계자 간에 이견이 발생하지 않도록 명확한가? 

  • 클래스의 속성은 도출하였는가? 도출된 속성의 이름과 설명이 명확한가? 

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음