본문 바로가기
Archive/정보처리기사

[정보처리기사] 1.소프트웨어 설계 - 요구사항 확인(요구사항 확인)

by 우창욱 2023. 12. 3.

용어 정리

자료 흐름도(Data Flow Diagram: DFD)

자료사전(Data Dictionary: DD)

기호
= 자료 항목 정의
+ 복합적인 자료 요소의 구성
{ }  반복
[ ]  선택
( ) 생략가능
** 주석
| 또는 ; 대체 항목 나열

소프트웨어 개발 생명주기 모델

이름 특징
폭포수 모델(waterfall model) 앞 단계가 완료될 때까지 대기 상태이다.
완성된 모습을 후반부가 되기 전엔 볼 수 없다.
고객이 원하는 모습이 아니어도 수정이 어렵다.
원형 모델(prototype model) 점진적으로 시스템을 개발해나가는 방법이다.
원형(prototype)을 가능한 빨리 개발한 후 고객과 검증하는 것이 목적이다.
나선형 모델(spiral model) 고비용의 시스템 개발이나 큰 시스템 구축 시 효과적이다.
프로젝트 수행 시 발생하는 위험을 최소화하려는 목적의 모델이다.
개발자가 위험을 정확하게 분석하지 못했다면 심각한 문제이다.

폭포수 모델
나선형 모델
원형 모델

소프트웨어 개발 방법론

소프트웨어를 생산하는 데 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 개발과정에서 프로그래머들이 일관성을 유지하고 효과적인 협업이 이루어질 수 있도록 돕기위한 방법론이다.

종류

이름 특징
구조적 개발 방법론(1970 년대) 기능중심
정보공학 방법론(1980 년대) 자료구조 중심
객체지향 개발 방법론(1990 년대) 객체중심
CBD 방법론(2000년대) 컴포넌트 중심

구조적 분석

효율적인 시스템 분석 명세서를 작성하기 위한 도형 중심의 분석용 도구를 이용하여 사용자의 요구사항을 파악하고 문서화하는 체계적인 분석 기법이다.

사용자의 요구사항을 정확하게 작성할 수 있고 Yourdon등에 의해 개발되어 보급되었다 (1960년 말 ~ 1980년대)

소단위 명세서(Mini Specification)

자료흐름도에 나타난 모든 최소 단위의 처리에 대해 자료흐름이 변환되는 절차 또는 논리적인 활동을 기술하는 도구

애자일(Agile)

2001년 Agile 연합 모임을 결성하고, Agile 소프트웨어 개발 선언문을 발표하였다. 가볍지만 충분한을 원칙으로 세우고 있는 소프트웨어 개발 방법론이다.

- +
프로세스와 도구 개인과의 상호작용
문서화 제대로 동작하는 소프트웨어의 개발에 집중
고객과의 계약 협상 고객과의 협력

 

XP(eXtreme Programming)

애자일의 가치를 적용한 개발방법론. 고객과 개발팀의 커뮤니케이션을 주장함

용어 내용
스토리 고객의 요구사항
스토리 추정 개발자가 스토리를 보고 기간과 강도를 결정
릴리즈 고객에게 제공되는 제품 배포
반복 릴리즈 안에서 반복되는 작업
드라이버 코드 작성자
파트너 드라이버를 도와 조언

 

객체지향 방법론

소프트웨어 개발은 기존 시스템을 분석하고 이를 표준화된 새로운 시스템 환경으로 전환하는 데 초점을 맞추기 시작하여,

소프트웨어를 개발할 때 작은 단위의 모듈들을 구성하고 추후 이를 재사용하여 소프트웨어의 효율성을 높이자는 생각에서 객체지향 방법론이 발표되었다.

 

용어 개념
객체 업무수행을 위한 대상이 되는 사람 / 장소 / 사물 / 사건 / 개념
클래스 공통 속성과 메서드를 가진 객체를 묶어 추상화한 개념
캡슐화 구현부가 외부에 노출되지 않게 쌓여진 상태
데이터 은닉 객체가 자신의 속성(프로퍼티)과 메서드(행위)를 숨기고 있는 것
상속 클래스가 가진 속성과 행위를 객체가 물려받는 것
조합 다른 객체를 사용하여 객체를 구성하는 것. 보다 복잡한 클래스를 만드는 일종의 '조립'
다형성 한 가지 인터페이스나 기본 클래스를 사용하여 여러 타입의 객체를 처리하는 능력

 

SOLID(객체지향 설계)

로버트 마틴이 2000년대 초반에 명명한 객체지향 프로그래밍 및 설계의 5가지 기본 원칙

앞 글자 약어 개념
S SRP 단일 책임 원칙(Single Responsibility Principle). 한 클래스는 하나의 책임만 가져야 한다.
O OCP 개방-폐쇄 원칙(Open/Closed Principle). 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.
L LSP 리스코프 치환 원칙(Liskov Substitution Principle). 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
I ISP 인터페이스 분리 원칙(Interface Segregation Principle). 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
D DIP 의존관계 역전 원칙(Dependency Inversion Principle). 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 예시로 의존성 주입이 있다. 

애자일 방법론 유형

이름 특징
XP(eXtreme Programming) 의사소통 개선과 즉각적인 피드백
용기, 단순성, 의사소통, 피드백, 존중
스크럼(SCRUM) 프로젝트 관리를 위한 상호, 점진적 개발방법론
XP와 달리 진행 체계 수립, 역할, 정의에 중점
기존 모델과 달리 모든 LifeCycle을 담지 않는다.
확약, 전념, 정직, 존중, 용기
린(LEAN) TOYOTA의 대표적인 생산방식
인력, 생산 설비 등을 필요한 만큼만 유지하면서 생산효율을 극대화하는 방식
전적으로 고객 관점이다.
Crystal 프로세스나 도구보다 사람에게 더 많은 중점을 두는 방법론이다.
ASD
(Adaptive Software Development)
확실하지 않은 상황에서 그에 적응할 수 있는 소프트웨어 방법을 제시한다.
FDD
(Feature Driven Development)
기능중심개발
고객 중심의, 아키텍쳐 중심의 실용적인 개발 프로세스이다.

 

스크럼에서 사용하는 용어

이름 개념
Product Owner(PO) 제품 책임자, 백로그를 작성하는 주체
Scrum Master(SM) 스크럼이 잘 수행될 수 있도록 도와주는 역할.
객관적으로 도와주고 문제 해결을 한다.
백로그 요구사항 리스트
제품 백로그 전체 기간 동안 개발할 백로그
스프린트 짧은 기간(1~4주) 동안 동작하는 SW를 사용자에게 제공하면서 피드백을 받고 수정한다.

 

XP의 5가지 가치

 

XP의 12가지 실천사항

계획 게임(Planning game) / Planning Process 페어 프로그래밍(Pair Programming)
짧은 릴리즈 주기(Short/Small releases) 코드 공동 소유(Collective Ownership)
메타포(공통의 name system) 지속적인 통합, CI(Continuous Integration)
단순 설계(Simple Design) 주당 40시간 작업(40-hour work)
테스트 기반 개발(Testing) 고객의 참여(On-site customer)
리팩토링(Refactoring) 코딩 표준(Coding Standards)

 

객체지향 분석 기법

기법 원리 특징
Rumbaugh(럼바우)의 OMT 1. 클래스의 외부 명세를 정의한다.
2. 객체 모델링(객체 다이어그램), 동적 모델링(상태 다이어그램), 기능 모델링(자료흐름도)로 분리한다.
1. 소프트웨어 생명 주기를 지원한다.
2. 데이터베이스 구조화에 용이하다.
Booch 방법론 1. 시스템 형성 구조를 모형화하는 DFD를 사용한다.
2. 클래스 다이어그램, 객체 다이어그램, 모듈 다이어그램, 프로세스 다이어그램
1. 전체 시스템 가시화에 유용하다.
2. 실시간 처리에 유용하다.
3. 설계를 위한 문서화 기법을 강조한다.
4. 분석 단계가 취약하다.
Coad/Yaurdon 방법론 1. 객체지향 특징을 가장 충족시키는 방법
2.E-R 다이어그램을 사용하여 객체의 행위를 모델링한다. 
1. 객체지향 CASE Tool을 지원한다.