[정보처리기사 실기] 1. 요구사항 확인

민영·2022년 6월 29일
0

정보처리기사

목록 보기
1/4
post-thumbnail

01 소프트웨어 개발 방법론

[소프트웨어 개발 방법론의 변화]
구조적 방법론-> 정보공학 방법론-> 객체지향 방법론-> 컴포넌트 기반 방법론-> 애자일 방법론-> 제품 계열 방법론-> 테일러링 개발 방법론

애자일(Agile) 방법론

: 요구사항, 설계, 구현, 시험 단계를 통해 개발하는 방법론, 개발 단계의 변화에 신속하게 대응하기 위해 요구사항을 지속적으로 분석하고 반영하여 시간 지연을 최소화하는 방법론 (반복적인 개발을 통한 잦은 출시를 목표로 한다)

  • XP(eXtreme Programming): 의사소통의 개선과 즉각적인 피드백에 의한 단순한 코딩으로 소프트웨어 품질을 높이는 방법 (문서화보다 변경을 추구, 개발 초기부터 소프트웨어 검사를 병행할 것을 권고하는 방법)
  • 스크럼(SCRUM): 애자일 방법론 중의 하나로 프로젝트 관리 중심의 방법론

[소프트웨어 개발 순서]
요구분석-> 아키텍처-> 설계-> 구현-> 시험

[소프트웨어 개발의 생명주기 모형]
- 폭포수 모형: 각 단계를 명확히 하고 다음 단계로 넘어감
- 프로토타입 모형: 구현하기 전 고객 평가를 받고 프로토타입을 조정하는 단계가 있음
- 나선형 모형: 모든 단계를 반복하면서 프로토타입을 지속적으로 발전시킴
- V모형: 검증을 강조한 기법
- 4세대 모형: 4세대 언어를 이용한 기법

02 현행 시스템 분석

현행시스템 파악의 목적 : 개발하고자 하는 시스템의 개발 범위 및 개발 방향성 설정에 도움을 주기 위해

[현행 시스템 파악 절차]
구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 파악

1. 구성/기능/인터페이스 파악

  • 구성: 업무와 이를 지원하는 업무로 구분하여 기술한 것
  • 기능: 단위 업무 시스템이 현재 제공하고 있는 기능을 기술한 것
  • 인터페이스: 데이터 주고받는 형식, 프로토콜, 주기 등을 기술한 것

2. 아키텍처 및 소프트웨어 구성 파악

아키텍처 요구사항

  • 시스템 구성 및 동작 원리를 나타내고 있어야 한다.
  • 구성요소간의 관계 및 시스템 외부 환경과의 관계가 표현되어야 한다.
  • 요구사항 및 시스템의 전체 생명주기를 고려해야 한다.
  • 개발자와 사용자 간의 의사소통 도구로 활용할 수 있어야 한다.
  • 재사용할 수 있도록 설계해야 한다.

소프트웨어 아키텍처 모델
- 계층화 패턴
- 클라이언트/서버 패턴
- 마스터/슬레이브 패턴
- 파이프-필터 패턴
- 브로커 패턴
- Peer to Peer 패턴
- Event-Bus 패턴
- MVC 패턴 (Model-View-Controller)
- 블랙보드 패턴
- 인터프리터 패턴

3. 하드웨어 및 네트워크 파악

- 하드웨어 구성도: 중앙처리장치 처리 속도, 메모리 크기, 보조기억장치 등의 주요한 사양들의 수량 명시, 현행 시스템들이 어느 서버에서 운용되고 있는지 파악

  • 이중화 기술은 CPU와 메모리를 여러개 두어 장애가 발생할 경우를 대비한다.
  • 이중화 기술은 목표 시스템의 인프라 구축 난이도에 따라 비용이 증가할 수도 있다.

- 네트워크 구성도: 현행 시스템들이 어떠한 네트워크 구성을 하고 있는지 그림이나 표 형태로 표현한 것

  • 서버 위치 파악, 서버간의 네트워크 연결 방식 파악, 서버의 물리적인 위치 관계 파악
  • 조직 내 보안 취약성 분석 및 대응 파악
  • 네트워크 장애 발생 추적 및 대응 파악

+) 저장 장치
DAS(Direct Attached Storage): 서버와 저장장치를 직접 연결

NAS(Network Attached Storage): 서버와 저장장치를 네트워크로 연결 -> 서버간에 스토리지 및 파일 공유가 용이

SAN(Storage Area Network): DAS의 빠른 처리와 NAS의 스토리지 공유 장점을 합친 방식 -> 광케이블과 광채널 스위치를 통해 근거리 네트워크 환경을 구성하여 빠른 속도로 데이터를 처리


03 요구사항 확인

요구공학 : 요구사항을 정의하고, 문서화하고, 관리하는 프로세스이다.

[요구사항 개발 프로세스]
: 요구사항 도출-> 요구사항 분석-> 요구사항 명세-> 요구사항 확인

1. 요구사항 도출

: 개발될 소프트웨어가 해결해야 할 문제를 이해하는 단계

도출 기법

  • 인터뷰
  • 스토리텔링: 애자일 방법에서 주로 사용하는 방법, 개발자와 사용자 간의 대화를 하면서 함께 요구사항을 분석해내는 방법
  • 프로토타이핑: 기본적인 기능만 빠르게 구현한 임시 소프트웨어로 사용자에게 피드백을 받는 방법
  • 벤치마킹

2. 요구사항 분석

: 요구사항의 타당성 조사, 분석, 정의하는 단계

분석 기법

  • DFD(Data Flow Diagram) 자료흐름도 : 구성요소들 사이에 자료와 정보가 어떻게 르르고 있는가를 그림으로 나타낸 다이어그램 (시간의 흐름을 알 수 없다!)
  • DD(Data Dictionary) 자료사전 : 시스템과 관련된 모든 자료의 명세와 속성을 파악할 수 있도록 조직화한 도구
  • Mini-Spec 소단위 명세서 : 규모가 큰 자료흐름도의 부족한 부분을 구조적 언어나 의사 결정표의 형태로 구성한 간략한 명세서
  • ERD
  • UML

3. 요구사항 명세

: 파악된 요구사항을 검토, 평가하고 승인될 수 있는 문서를 작성

명세 기법

  • 정형 명세기법: 수학적인 원리와 표기법을 이용하여 서술
  • 비정형 명세기법: 자연어를 기반으로 서술

4. 요구사항 확인

: 요구사항 명세서를 검증하고 확인하는 단계

  • 검증(Verification): "제품을 올바르게 생성하고 있나요?", 소프트웨어가 요구사항 문서에 맞게 구현되었음을 검사하는 것을 말함
  • 확인(Validation): "올바른 제품을 생성하고 있나요?", 소프트웨어가 고객의 의도에 맞게 구현되었음을 검사하는 것을 말함

+) 요구사항 검증

1) 요구사항 검토

  • Peer Review (동료검토): 다수의 이해관계자에게 요구사항 명세서를 설명하고 결함을 발견하는 형태로 진행된다.
  • Walk Through: 소프트웨어 개발 단계마다 실시하는 비정형 검토 회의이다.
  • Inspection: 소프트웨어 개발에 참여하지 않은 다른 전문가가 오류를 찾아내는 공식적 검토 방법이다.
  • 프로토타입: 일부 기능을 임시적으로 개발하여 사용자의 요구사항을 검증하는 방법이다.
  • 리펙토링: 결과의 변경없이 프로그램 소스의 구조를 재조정해서 가독성을 높이고 유지보수를 편하게 한다.

2) 테스트 설계
: 테스트 케이스를 생성하여 요구사항이 현실적으로 테스트 가능한지 검토한다. (송수신 시스템, 데이터베이스 등을 검토)

3) CASE (Computer Aided Software Engineering)
: CASE란 소프트웨어의 생명주기 전반을 지원하는 프로그램 또는 소프트웨어 개발을 지원하는 자동화 도구를 말한다. 객체지향 시스템뿐만 아니라 구조적인 시스템을 포함해 모든 분야에 적용된다.

  • 상위(Upper) CASE: 요구분석과 설계를 지원
  • 하위(Lower) CASE: 코드 작성(구현), 검사(테스트)를 지원
  • 통합(Total) CASE: 개발 주기의 전 과정을 지원

CASE의 4가지 구성요소

CASE의 특징

  • 소프트웨어 생명주기의 전 단계를 연결한다.
  • 스스로 동작하는 것이 아니므로 분석가의 지원이 필요하다.
  • 개발 기간을 단축시킬 수 있고 유지보수가 간편해지고 재사용성이 높아진다.
  • CASE Tool간의 호환성이 없다.
  • 요구사항 변경 사항을 추적하고 분석 및 관리할 수 있다.
  • 분산된 환경에서 다양한 이해관계자가 공동 작업할 수 있다.
  • 컴파일러나 인터프리터와 같은 언어 번역 프로그램은 지원하지 않는다.

+) 요구사항 관리

  1. 요구사항 협상
  2. 요구사항 기준선 설정
  3. 요구사항 변경 관리
  4. 요구사항 확인 및 검증

+) 요구사항 기술적 타당성 검토

  1. 성능 및 용량 산정의 적정성
  2. 시스템간 상호 운용성
  3. IT시장 성숙도 및 트렌드 부합성
  4. 기술적 위험 분석: 복잡성, 의존성, 검증 여부

04 분석모델 확인

1. 분석모델 검증

- 유스케이스 모델 검증: 액터, 유스케이스, 유스케이스 명세서 점검
- 개념 수준의 분석 클래스 검증: 주요 클래스 도출 여부, 클래스 이름과 속성의 적절성, 클래스 간의 관계
- 분석 클래스 검증: 유스케이스 실현에 필요한 분석 클래스의 스테레오 타입으로의 표시 여부, 클래스 간의 관계, 클래스 정보의 상세화 정도 확인

2. 분석 모델의 시스템화 타당성 분석

- 성능 및 용량 산정의 적정성
- 시스템 간 상호 운용성
- IT 시장 성숙도 및 트렌드 부합성
- 기술적 위험 분석

profile
그날의 기록

0개의 댓글