정보처리기사 8일차

1.소프트웨어 설계

 1.4 인터페이스 설계

  1.4.1 인터페이스 설계 능력 단위 정의

  1.4.2 인터페이스 요구사항 확인

---

- 인터페이스 설계 능력 단위 정의

인터페이스 설계란 응용소프트웨어 개발을 위해 정의된 시스템 인터페이스 요구사항을 확인하고 인터페이스 대상을 식별하여 인터페이스 설계서를 작성하는 능력이다

 

- 인터페이스 요구사항 확인

 

1. 내외부 인터페이스 요구사항

 

1.1 내외부 인터페이스 요구사항의 개념

 

내외부 인터페이스란 조직 내/외부에 존재하는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미한다. 네트워크를 통해 조직 내/외부에 존재하는 시스템 간의 요구기능을 수행하기 위해서 내외부 인터페이스 설계와 개발은 필수적이다.

 

내외부 인터페이스 요구 사항의 구성

• 내외부 인터페이스 이름
• 연계 대상 시스템
• 연계 범위 및 내용
• 연계 방식
• 송신 데이터
• 인터페이스 주기
• 기타 고려 사항

1.2 내외부 인터페이스 요구 사항 분석

 

내외부 인터페이스 요구 사항 분석은 요구사항 정의 단계에서 정의한 기능 및 비기능 내외부 인터페이스 요구 사항을 식별하고 분류, 조직화하여 명세를 구체화하는 작업이다.

요구사항 명세서와 유스케이스 다이어그램 등과 같은 개념모델을 검토하여 상위 수준의 요구사항은 분해하여 적절한 수준으로 상세화 한다.

요구사항에 대한 중요도를 평가하여 우선순위를 부여한다.

 

2. 요구공학

 

2.1 요구공학의 개념

 

1. 요구공학

요구공학이란 시스템 요구사항 문서를 생성, 검증, 관리 하기위하여 수행되는 구조화된 활동의 집합을 의미한다.

 

2. 요구공학의 목적

이해관계자 사이에 효과적인 의사소통 수단을 제공하고 요구사항에 대한 공통 이해를 설정한다.

요구사항 손실 방지 및 에러감지로 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 한다.

 

2.2 요구공학 프로세스

 

요구공학의 프로세스는 요구사항 개발과 요구사항 관리로 구성된다.

 

1. 요구사항 개발(CMM Level 3 프로세스 영역(PA)) 

요구사항 개발은 요구사항 도출, 분석, 명세, 확인의 절차로 이루어진다. (SWEBOK : SoftWare Enginnering Body of Knowledge)

 

요구사항 개발 절차

절차	내용	활용기법
요구사항 도출	소프트웨어가 해결해야할 문제를 이해하고 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련되어 있다.	인터뷰, 시나리오, 작업분석, BPR, 프로토타이핑, RFP, 워크샵, 벤치마킹
분석	요구사항들 간의 상충을 해결하고, 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호작용하는지 이해한다.	구조적 분석 : DFD, DD, Mini spec, ERD Use Case 기반 분석 : UML, 모델링
명세	처계적으로 검토, 평가, 승인 될 수 있는 문서를 작성하는 것을 의미한다.	ER 모델링, FSM(Finite State Machine) SADT(구조적 분석과 디자인 기술)
확인/검증	분석가가 요구사항을 이해했는지에 대한 확인이 필요하고, 요구사항 문서가 조직의 표준에 부학하고 이해 가능하며 일관성 있고 완전한지에 대한 검증이 중요하다.	검증 : 소프트웨어개발 라이프사이클의 각 단계의 산출물이 이전 단계에서 설정된 개발 규격과 요구들을 충족시키는 지의 여부를 판단하기 위한 활동이다. 확인 : 소프트웨어 개발 라이프사이클의 각 단계의 산출물이 최초 사용자 요구 또는 소프트웨어 요구에 적합한지를 입증하기 위한 활동이다.

요구사항 명세 원리와 내용

원리	내용
명확성	각각의 요구사항 명세 내용은 하나의 의미만 부여한다.
완전성	기능, 성능, 속성, 인터페이스, 설계제약 등에 관한 모든 시스템 요구사항이 포함된다.
검증가능성	요구사항 내용의 충족요구와 달성 정도의 확인이 가능하다.
일관성	명세 내용간의 상호간 모순이 없어야 한다.
수정용이성	요구사항 변경 시 쉽게 수정할 수 있어야 한다.
추적가능성	각 요구사항 근거에 대한 추적과 상호참조가 가능하여야 한다.
개발 후 이용성	시스템 개발 후 운영 및 유지보수에 효과적인 이용이 가능하여야 한다.

요구사항은 기능적 요구사항과 비기능적 요구사항으로 구분된다.

구분	기능적 요구사항	비기능적 요구사항
개념	시스템에서 제공되어야 할 특정 기능을 정의한다.	시스템의 전체적 품질이나 기능적 요구사항의 구현시 고려해야하는 제약사항이다.
내용	데이터모델 : 개념적인 모델의 상태를 구체화 한것으로 생성, 삭제 등의 실행을 정의한다. 데이터 흐름 처리모델 : 시스템행위가 어떻게 이루어지는가를 표현하여, 데이터 모델의 입출력이 데이터의 일부분으로 사용한다. 프로세스모델 : 병행, 상호작용, 다른프로세스들 간의 동기화 등의 사건과 활동을 서술한다.	S/W뿐만 아니라 시스템 전체에 대한 요구사항이다. 성능 : 응답속도, 자원사용량 보안 : 침해대응, 사용자인증/권한 아키텍처 : 확정성, 유연성 안정성 : 장애대응, 서비스연속성

2. 요구사항 검증

요구 사항 검증은 사용자의 요구가 정확하게 요구 사항 명세서에 기술되었는지를 검토하고 베이스라인으로 설정하는 활동이다.

 

3. 요구 사항 검증 방법

요구 사항 검토는 요구 사항 검토 담당자들이 요구사항 명세서를 수작업으로 분석하는 방법으로 요구사항 명세서에 오류가 없는지, 불명확한지, 표준을 준수했는지 등을 검토한다. 검토방법은 동료 검토와 워크 스루, 인스펙션 등이 활용된다.

구분	내용
동료검토	2~3명이 진행하는 리뷰의 형태이다. 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견한는 형태로 진행한다.
워크 스루	소프트웨어 시스템 개발 단계마다 실시하는 비정형 검토 회의이다. 오류를 조기에 검출하는 데 목적을 두고 리뷰를 통해 오류를 검출하고 문서화한다.
인스펙션	소프트웨어 요구, 설계, 원시 코드등의 저장자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법이다. 소프트웨어의 품질을 높이는 방법의 하나이다.

프로토타이핑은 개발할 시스템에 대한 주요기능이나 일부분을 약식으로 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 경험할 수 있게 하고 요구사항을 확인한다.

 

테스트 설계는 요구사항을 테스트할 수 있도록 테스트 케이스를 생성하여 추후 요구사항이 현실적으로 테스트 가능한지를 검토한다.

• 인터페이스 요구사항에 대한 테스트 케이스는 송신시스템과 수신 시스템에서 확인해야 할 사항을 각각 도출하고, 송/수신 시스템에서 각각 개별 데이터의 유효값을 체크하는 테스트 케이스와 송/수신 데이터 간 연관 관계를 체크하느 테스트 케이스로 구별해서 작성한다.
• 송/수신 데이터가 코드성 데이터일 경우, 코드의 유효값을 체크할 수 있도록 테스트 케이스를 작성한다.
• 수신 시스템에서 전송받은데이터를 운영 DB에 반영하는 과정에서 오류가 발생하지않는지, 송/수신 시스템에서 참조하는 테이블에 데이터가 없거나 데이터 갱신 및 등록 오류가 발생하는지를 점검할 수 있도록 테스트 케이스를 작성한다.

CASE 도구 활용은 구조화된 요구사항명세서에 대해서는 자동화된 일관성 분석을 제공하느 CASE도구를 활용할 수 있다 대규모 개발 프로젝트에서는 다양한 이해관계자들이 요구사항 명세서를 검토해야 하고, 요구사항 명세서에 대해 형상관리를 수행해야 해서 요구사항 관리툴을 이용한다.

 

4. 요구사항 관리(CMMI Level2 프로세스 영역(PA))

 

요구사항 협상, 요구사항 기준선, 요구사항 변경관리, 요구사항 확인을 수행한다.

 

구분	내용
요구사항 협상	가용한 자원과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법이다.
요구사항 기준선	공식적으로 검토되고 합의된 요구사항 명세서이다.
요구사항 변경 관리	요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법이다.
요구사항 확인	구축된 시스템이 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 방법이다.

---

오답풀이

 

다음 중 CASE 도구의 설명으로 옳지 않은 것은?

1. 소프트웨어 개발과정 일부 또는 전체를 자동화하기 위한 도구이다.

2. 표준화된 환경구축 및 문서과정의 자동화를 할 수 있다.

3. Upper CASE는 계획 수립, 요구분석, 기본설계 단계를 지원하고 이를 Diagram으로 표현한다.

4. Lower CASE는 상세설계 작업을 지원하며 화면 출력 등의 작성을 지원한다.(정답)

 

Lower CASE 는 시험, 유지보수 작업을 지원하며 소스코드와 시스템 명세서를 획득한다.

 

 

CASE 도구의 분류

Upper CASE

계획수립, 요구분석, 기본설계 단계를 지원하고 이를 다이어그램으로 표현한다.

Middle CASE

상세설계 작업을 지원하며 화면 출력 등의 작성을 지원한다.

Lower CASE

시험, 유지보수 작업을 지원하며 소스코드와 시스템 명세서를 획득한다.

I - CASE

위 세가지를 통합한 것으로 Rational ROSE, COOL 등이 국내에서 사용중이다.