정보처리기사 실기 공부log - 20200915

 

요구사항 

 

요구사항 : 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건으로, 개발에 참여하는 이해관계자(개발자, 개발의뢰자, 사용자)들 간 의사소통을 원활하게 함 

 기술하는 내용에 따라 : 기능 요구사항 + 비기능 요구사항 

기술하는 관점과 대상의 범위에 따라 : 시스템 요구사항 + 사용자 요구사항 

요구사항 개발 프로세스 : 요구사항을 체계적으로 도출하면 이를 분석한 후 분석 결과를 명세서에 정리한 다음 확인 및 검증하는 일련의 과정 

 

요구사항 도출 : 시스템, 사용자, 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있고 어떻게 수집할 것인지를 식별하고 이해하는 과정. 인터뷰, 설문, 프로토타이핑, 브레인스토밍, 워크샵, 유스케이스 등 기법으로 도출한다. 

SDLC 동안 지속적으로 반복된다. 

개발자와 고객 사이의 관계가 만들어지고, 이해관계자가 식별된다. 

*유스케이스 : 사용자의 요구사항을 기능 단위로 표현하는 것 

 

요구사항 분석 : 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 걸러내는 과정 

 

요구사항 명세 : 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것 

기능 요구사항은 빠짐없이, 비기능 요구사항은 필요한 것만 명확하게 기술 

사용자가 이해하기 쉬우며, 개발자가 효과적으로 설계할 수 있도록 작성 

 

요구사항 확인 : 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지 검토 

분석가의 확인, 개발자의 검증 

요구사항 관리도구를 이용하여 요구사항 정의 문서들에 대해 형상관리를 수행 

 

형상? 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 설명서, 데이터 

형상관리? 형상들의 변경사항을 관리하는 일련의 활동 

 

요구사항 분석 기법 

개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법으로, 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등이 있다. 

 

요구사항 분류 

요구사항을 명확히 확인할 수 있도록 다음과 같은 기준으로 분류한다. 

기능 요구사항인지 vs 비기능 요구사항인지 

하나 이상의 상위 요구사항에서 유도된 것인지 vs 이해관계자나 다른 원천으로부터 직접 발생한 것인지 

개발할 제품에 관한 것인지 vs 개발 과정(프로세스)에 관한 것인지 

우선순위에 따른 분류 

소프트웨어에 미치는 영향의 범위에 따른 분류 

소프트웨어 생명 주기 동안에 변경될 가능성이 있는지 여부에 따른 분류 

 

개념모델링 

요구사항을 보다 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화하여 개념적으로 표현한 “모델"을 만드는 과정 

유스케이스 다이어그램, 데이터 흐름 모델, 객체 모델 등 

UML로 표기 

 

요구사항 확인 기법 

요구사항 분석 후 문서화된 내용을 확인하고 검증하는 방법으로, 개발 자원이 배정되기 전에 수행해야 한다. 

요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트 등이 있다. 

 

요구사항 검토 

문서화된 요구사항을 훑어보면서 확인하는 가장 일반적인 요구사항 검증 방법 

 

프로토타이핑 

초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정 

빠른 제작 가능, 사용자와 개발자 또는 개발자 간 의사소통이 원활, 문제점 사전 식별 가능 

사용자의 관심이 프로토타입에 집중, 프로토타입 개선에 대한 비용부담, 사용성 과대평가 우려 

 

모델 검증 

요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증 

 

인수 테스트 

사용자가 실제로 사용될 환경에서 요구사항들이 모두 총족되는지 사용자 입장에서 확인하는 과정 

사용자 인수 테스트, 운영상 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파검사, 베타검사 

 

UML 

Unified Modeling Language 

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간 의사소통이 원활하도록 표준화한 대표적인 객체지향 모델링 언어로, 사물 + 관계 + 다이어그램 등으로 구성 

시스템의 구조를 표현하는 6개의 구조 다이어그램 + 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성 가능 

 

사물 

모델을 구성하는 가장 중요한 기본 요소로, 다이어그램 안에서 관계가 형성될 수 있는 대상 

구조사물 : 시스템의 개념적/물리적 요소를 표현 - 클래스, 유스케이스, 컴포넌트, 노드 

행동사물 : 시간과 공간에 따른 요소들의 행위를 표현 - 상호작용, 상태머신 

그룹사물 : 요소들을 그룹으로 묶어서 표현 - 패키지 

주해사물 : 부가적인 설명이나 제약조건 등을 표현 - 노트 

 

관계 

사물과 사물 사이의 연관성을 표현 

연관관계(Association) : 2개 이상의 사물이 서로 관련되어 있음을 표현, 방향성은 화살표 있는 실선으로 나타내며 양방향은 화살표 없는 실선 

의존관계(Dependency) : 연관관계와 유사하지만 짧은 시간 동안(조건 등)만 연관을 유지하는 관계, 영향을 주는 쪽에서 받는 쪽으로 점선 화살표를 연결 

집합관계(Aggregation) : 하나의 사물이 다른 사물에 독립적으로 포함되어 있는 관계, 포함하는 쪽이 속 빈 마름모 실선을 가짐 

포함관계(Composition) : 하나의 사물이 다른 사물에 종속적으로 포함되어 있는 관계, 포함하는 쪽이 속 찬 마름모 실선을 가짐 <포함하니까 꽉 찬 마름모> 

일반화관계(Generalization) : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현, 구체적(하위) 사물에서 일반적(상위) 사물 쪽으로 속 빈 화살표 실선을 연결 

실체화관계(Realization) : 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현, 사물에서 기능 쪽으로 속 빈 화살표 점선을 연결

 

다이어그램 

사물과 관계를 도형으로 표현한 것 

여러 관점에서 시스템을 가시화한 “뷰"를 제공함으로써 의사소통에 도움을 줌 

정적 모델링에서는 구조적 다이어그램, 동적 모델링에서는 행위 다이어그램을 주로 사용 

구조적 다이어그램 : 클래스 다이어그램, 객체 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램, 복합체 구조 다이어그램, 패키지 다이어그램 

행위 다이어그램 : 그 외 

 

기능 모델링 

사용자의 요구사항을 분석하여 개발될 시스템이 갖춰야 할 기능들을 정리한 후 사용자와 함께 정리된 내용을 공유하기 위해 표현하는 것으로, 유스케이스 다이어그램과 액티비티 다이어그램이 있다. 

 

유스케이스 다이어그램 

개발될 시스템과 관련된 외부 요소들(사용자, 외부 시스템)이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자 관점에서 표현한 것