1과목. 소프트웨어 설계 - 요구사항 확인

kkiyou·2021년 12월 18일

정보처리기사

목록 보기

1/5

Software Life Cycle

소프트웨어 개발 생명 주기(Software Development Life Cycle, SDLC)

소프트웨어 개발 절차를 정의한 것으로, 각 개발 단계별 주요 활동 결과와 유지보수 과정을 포함한다.

폭포수 모형(Waterfall Model) [★★★★★]
폭포에서 한 번 떨어진 물이 다시 올라갈 수 없는 것 처럼, 각 단계가 완전히 끝난 뒤 다음 단계가 시작되며 이전 단계로 돌아갈 수 없는 소프트웨어 개발 방법론을 의미한다. 따라서 동시에 두 개 이상의 단계를 실행할 수 없다.
개발 단계
검토 → 계획 → (요구)분석 → 설계 → 구현 → 시험(검사) → 유지보수

특징
- 매뉴얼 작성이 필요하다.
- 적용 경험과 성공 사례가 많다.
- 가장 오래된 소프트웨어 개발 모형이다.
동의어: 선형 순차적 모형, 고전적 생명 주기 모형

Keyword: 전통적, 오래된, 고전적, 단계적, 선형적, 매뉴얼

프로토타입 모형(Prototype Model)
실제 개발될 소프트웨어의 프로토타입(시제품)을 만들어, 개발을 완료하기 전에 문제점을 파악하고 사용자의 요구사항을 반영하는 소프트웨어 개발 방법론을 의미한다.
개발 단계
요구 확인 → 설계 → 프로토타입 개발(제작) → 평가 → 프로토타입 개선 → 구현

특징
- 개발 완료 시점에 오류가 발생할 수 있는 폭포수 모형의 단점을 보완함.
동의어: 원형 모형

나선형 모형(Spiral Model) [★★★★★]
보헴(Boehm)이 제안한 모델로, 나사의 나선을 따라 계속 회전하듯이 개발 과정을 반복하여 완벽한 소프트웨어를 개발하는 방법론을 의미한다.
개발 단계
계획 → (위험)분석 → 개발/검증 → 평가

특징
- 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.
- 위험을 관리하고 최소화하는 것이 목표이다.
- 유지보수 과정이 필요 없다.
동의어: 점진적 모형

Keyword: ㄱㅂㄱㅍ, 반복, 점진적

애자일 모형(Agile Model) [★★★★★]
변화에 유연하게 대응하기 위해 일정한 주기로 개발을 반복하는 소프트웨어 개발 방법론을 의미한다. 스프린트(Sprint) 또는 이터레이션(Iteration)으로 불리는 짧은 개발 주기를 반복하고, 결과물에 대한 고객 평가를 반영하여 개선된 소프트웨어를 개발해 나간다.
특징
- 소규모 프로젝트, 숙련된 개발자, 급변하는 환경에 적합함
애자일 선언(Afile Manifesto) 애자일 개발의 4가지 핵심 가치
1) 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
2) 방대한 문서보다는 실행되는 소프트웨어에 더 가치를 둔다.
3) 계약 협상보다는 고객과의 협업에 더 가치를 둔다.
4) 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

Keyword: 고개지향, 주기적, Iteration

애자일 기반 소프트웨어 개발 모형
1) 스크럼(Scrum)
2) 익스트림 프로그래밍, XP(eXtreme Programming)
3) 칸반(Kanban)
4) Lean
5) 크리스탈(Crystal)
6) ASD(Adaptive Software Development)
7) 기능 중심 개발, FDD(Feature Driven Development)
8) DAD(Disciplined Agile Delivery)
Disciplined: 훈련된
※엑스칸크린

소프트웨어 공학(Software Engineering)

소프트웨어 품질과 생산성 향상을 목표로 하는 학문

소프트웨어 공학의 기본 원칙
1. 현대적인 프로그래밍 기술을 계속적으로 적용하여, 높은 품질의 소프트웨어 상품을 개발한다.
2. 소프트웨어의 품질을 유지할 수 있도록 지속적으로 검증한다.
3. 소프트웨어 개발과 관련된 사항 및 결과를 기록한다.

애자일 기반 소프트웨어 개발 모형

스크럼(Scrum) [★☆☆☆☆]
럭비 경기의 스크럼 대형처럼 팀 단위로 개발의 효율성을 높이는 애자일 개발 방법이다.
Scrum: 럭비 경기에서 럭비공을 사이에 두고 상대를 밀어내기 위해 대치하고 있는 대형을 의미한다.
특징
- 개발 작업 전부를 팀 내에서 스스로 해결(cross-functional)할 수 있어야 한다.
팀의 구성 및 역할
- Product Owner(PO, 제품책임자)
  - 높은 제품 이해도를 바탕으로 의사결정을 담당한다.
  - 의해관계자들의 의견을 종합하여 백로그(Backlog)를 작성하고 우선순위를 지정한다.(팀원들은 백로그에 스토리는 추가할 수 있으나, 우선순위를 지정할 수 없다.)
    Backlog: 제품 개발에 대한 요구사항(User Story)를 우선순위에 따라 정리해 놓은 목록
    Stroy: 백로그에 작성될 요구사항, 단어가 아니라 문장으로 표현되기 때문에 스토리라고 명명함.
- Scrum Master(SM)
  
  일일 스크럼 회의를 주관하고, 객관적인 시각에서 팀에게 조언을 하는 역할을 담당한다.
- Development Team(DT, 개발팀)
  
  PO와 SM을 제외한 모든 팀원으로, 개발자, 디자이너, 테스터 등 제품 개발에 참여하는 모든 사람을 의미한다.
개발 단계
제품 백로그 → 스프린트 계획 회의(스프린트 백로그) → 스프린트(Sprint) → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고

Extreme Programming(XP) [★★★☆☆]
고객의 적극적인 참여를 유도하고, 단순한 설계를 통해 짧고 반복적으로 개발하는 애자일 개발 방법이다.
핵심 가치
Communication(의사소통), Simplicity(단순성), Courage(용기), Respect(존중), Feedback

기본 원리
- 1) Pair Programing: 공동 개발 & 공동 책임
- 2) Collective Ownership: 공동 코드 소유(공동 권한)
- 3) Test-Driven Development: 지속적인 테스트
- 4) Whole Team: 각자의 역할에 대한 책임
- 5) Continuous Integration: 모듈 단위의 작업이 마무리 될 때마다 지속적으로 합침
- 6) Design Improvement or Refactoring
- 7) Small Releases: 릴리즈 기간을 짧게 반복하여 변화에 신속하게 대응
Keyword: 고객지향, 테스트, 반복

현행 시스템 분석 [★☆☆☆☆]

새로 개발하려는 시스템의 개발 요소 및 수준, 범위 등을 설계하기 위해 현재 사용하고 있는 시스템을 분석하는 활동을 의미한다.

현행 시스템 분석(파악) 절차

1 단계: System 구성, 기능, 인터페이스 분석
2 단계: Architecture & SoftWare 분석
3 단계: HardWare & Network 분석

분석 요소
1) OS(Operating System, 운영체제)

Windows, UNIX, Linux, Mac OS, iOS, Android 등 사용자가 디지털 기기를 활용할 수 있도록 사용 환경을 제공하는 소프트웨어(시스템)이다.

2) DBMS(DataBase Management System)

사용자의 요구에 따라 Data를 생성하고 DataBase(DB)를 관리하는 소프트웨어이다.

특징

데이터의 종속성과 중복성을 해결한다.

종류: Oracle, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis, IBM DM2 등

3) Web Application server(WAS)

동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
미들웨어: OS와 운영프로그램 사이를 연결하는 소프트웨어

종류: Tomcat, WebSphere, JEUS, Jetty, JBoss, Resin, WebLogic, GlassFish

참고
Web Server는 텍스트나 이미지 등 정적인 콘텐츠를 처리하기 때문에 날씨나 주가 등 실시간으로 변하는 동적 콘텐츠를 처리하기 위해 WAS를 사용한다.

현행 시스템 분석 시 고려사항
가용성, 성능, 호환성, 구축비용, 기술지원

요구사항 확인

요구사항
소프트웨어 개발 및 유지 보수 과정에 필요한 제약조건(기준, 목표)을 의미한다.

요구사항 유형 [★★★☆☆]
```
      --- 기능 요구사항(Functional Requirments)
 --−<
|     --- 비기능 요구사항(Non-functional Requirments)
|
|
|     --- 사용자 요구사항(User Requirements)
 ---<
      --- 시스템 요구사항(User Requirements)
```
- 기능 요구사항(Functional Requirments)
  시스템, 입출력, 연산, 저장 등 기능과 관련된 요구사항을 의미한다. 예컨대 "사용자는 회원 ID와 PW를 입력하여 Login할 수 있다"와 같은 요구사항이다.
- 비기능 요구사항(Non-functional Requirments)
  성능, 보안, 품질, 안정, 인터페이스, 테스트 등 품질과 제약조건에 관한 요구사항을 의미한다.
- 사용자 요구사항(User Requirements)
  사용자의 요구사항으로 알기 쉬운 표현을 사용한다.
- 시스템 요구사항(User Requirements, 소프트웨어 요구사항)
  개발자의 요구사항으로 전문적이고, 기술적인 용어로 표현한다.

요구사항 개발 절차 [★★☆☆☆]
요구사항 도출(확인) → 요구사항 분석(실현 가능성 검토) → 요구사항 명세(문서화) → 요구사항 확인(계약)

1) 요구사항 도출(Requirement Elicitation)
요구사항을 파악하는 단계로 이해관계자(Stockholder) 간의 소통이 중요하며, 소프트웨어 개발 생명 주기(SDLC) 전반에 걸쳐 반복된다.

주요 도구: Interview, Brain Stroming, Workshop, Prototyping, Use Case

2) 요구사항 분석(Requirement Analysis) [★★★★☆]
비용, 일정, 타당성, 실현가능성, 명료성 등의 제약조건을 고려하여 요구사항 중 일부를 제거하는 과정을 의미한다.

구조적 분석 기법
도형 중심의 분석 방법으로 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있다.

종류

자료 흐름도(DFD, Data Flow Diagram, = Bubble Chart)

자료의 흐름과 처리를 중심으로 하는 구조적 분석 기법

기호(symbol) 의미(meaning) 표기법
Process 데이터를 변환(처리)하는 부분 둥근 원 또는 둥근 사각형
Data Flow 자료의 이동 및 연관관계 화살표
Data Store 자료의 저장소 두 줄
Terminator(단말) 데이터를 생성하고 수신하는 외부개체 사각형

자료 사전(DD, Data Dictionary)
자료 흐름도에 있는 자료를 상세하게 정의한 것으로, 메타 데이터(Meta Data)를 의미한다.

기호(symbol) 의미(meaning)
= 정의(is composed of)
+ 구성(and, along with)
$\{\ \}^{Max}_{Min}$ 반복(iteration)
[ ] 선택(selection)
( ) 생략가능(optional)
* * 주석(comment)

3) 요구사항 명세(Requirement Specification)
요구사항을 문서화하는 과정을 의미한다.

요구사항 명세 기법
(1) 정형 명세 기법: 수학적 기호, 정형화된 표현, 간결함, 이해가 어려움
(2) 비정형 명세 기법: 자연어, 서술, 해석자에 따라 해석이 달라질 수 있음, 이해가 쉬움

4) 요구사항 확인/검증(Requirement Validation)
요구사항의 타당성, 상충성 등을 검토한다. 그러나 현실적으로 모든 문제를 확인할 수는 없다. 그럼에도 불구하고 개발이 완료된 후 문제가 발생하면 비용이 많이 들기 때문에 사전에 검증하는 것이 중요하다.

기호(symbol)	의미(meaning)	표기법
Process	데이터를 변환(처리)하는 부분	둥근 원 또는 둥근 사각형
Data Flow	자료의 이동 및 연관관계	화살표
Data Store	자료의 저장소	두 줄
Terminator(단말)	데이터를 생성하고 수신하는 외부개체	사각형

기호(symbol)	의미(meaning)
=	정의(is composed of)
+	구성(and, along with)
$\{\ \}^{Max}_{Min}$	반복(iteration)
[ ]	선택(selection)
( )	생략가능(optional)
* *	주석(comment)

UML(Unified Modeling Language) [★★★★★]
표준화된 언어를 활용해 개발할 대상을 다이어그램으로 표현하는 객체지향 언어이다.

구성요소
1. 사물(Things)[☆☆☆☆☆]
관계가 형성될 수 있는 대상을 의미한다.

사물 내용
Structural Things(구조 사물) 물리적, 개념적 요소
Class, Use Case, Component, Node
Behavioral Things(행동 사물) 시간, 공간적 요소
Interaction, State Machine
Grouping Things(그룹 사물) 요소들을 그룹으로 묶음
Package
Annotation Things(주해 사물) 주석, 제약조건
Note

관계(Relationships)
사물과 사물 사이의 연관성을 표현한다.

관계 내용 표기
Association(연관 관계) 2개 이상의 사물 간 관련성 선생님 — 학생,
사람 → 집
Dependency(의존 관계) 일시적으로 연관(관련성)을 유지하는 관계,
오퍼레이션의 매개 변수로 사용 회원 등급 ---> 할인율
Generalization(일반화 관계,
= Inhreitance) 상위 개념과 하위 개념 (아메리카노, 에스프레소) —▷ 커피
Realization(실체화 관계) 사물을 공통된 특성(기능)으로 그룹화 할 수 있는 관계,
오퍼레이션 수행을 지정 (비행기, 새) ---▷ 날 수 있는
Aggregation(집합 관계) 하나의 사물이 다른 사물에 포함되어 있으나, 상호 독립적인 관계 컴퓨터 ◇– 프린터
Composition(포함 관계) 하나의 사물이 다른 사물에 포함되어 있으나, 상호 독립적이지 못한 관계 문 ◆— 열쇠

Diagram
사물과의 관계를 도형으로 표현한다.

1) Structural Diagram(구조적 다이어그램)
정적 모델링에 사용한다.

종류 내용
Class Diagram 클래스가 가지는 속성,
시스템 구조 파악
Object Diagram(객체) 객체 사이의 관계로
Component Diagram 인터페이스 표현
구현 단계에서 사용
Deployment Diagram(배치) 물리적 요소들의 위치를 표현
구현 단계에서 사용
Composite Structure Diagram(복합체 구조) 클래스나 컴포넌트가 복합 구조를 갖는 경우
Package Diagram 패키지들의 관계

2) Behavioral Diagram(행위적 다이어그램)
동적 모델링에 사용한다.

종류 내용
Use Case Diagram 사용자의 요구 분석,
기능 모델링에 사용
Sequence Diagram 메세지 교환
Communication Diagram 메세지 교환 및 객체들 간의 연관 관계
State Diagram(상태) 상태 변화 또는 다른 객체와의 상호 작용,
럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용
Activity Diagram(활동) 처리의 흐름을 순서
Interaction Overview Diagram(상호작용 개요) 상호작용 제어 흐름을 표현
Timing Diagram 객체 상태 변화와 시간 제약

Use Case Diagram
사용자의 관점(View)에서 표현하며 사용자의 요구사항을 분석하는 도구로 사용한다..

구성요소:
- System(System Scope(범위))
- Actor: 주액터(이득을 얻음), 부액터(목적 달성을 위한 외부시스템)
- Use Case
- Relationships: 포함관계(새로운 유스케이스 생성 시), 확장관계(특정 조건 부합 시)

Class Diagram
시스템 구성 요소를 문서화하는 데 사용한다.

구성요소:
- Class: Attribute(속성, 상태, 정보) 및 Operation(동작, 메소드, 함수)
- 제약조건
- Relationships

Sequence Diagram
메세지를 교환하며 시간의 흐름에 따라 상호 작용 한다.

구성요소:

Actor:

Object

Lifeline(생명선)

Active Box(실행 상자)

Message

Stereotype object: << >>(Guilmet, 길러멧)을 사용해 표현한다.

Keyword: 사물(Things), 관계(Relationships), Diagram, 구조 다이어그램, 행위 다이어그램

사물	내용
Structural Things(구조 사물)	물리적, 개념적 요소 Class, Use Case, Component, Node
Behavioral Things(행동 사물)	시간, 공간적 요소 Interaction, State Machine
Grouping Things(그룹 사물)	요소들을 그룹으로 묶음 Package
Annotation Things(주해 사물)	주석, 제약조건 Note

관계	내용	표기
Association(연관 관계)	2개 이상의 사물 간 관련성	선생님 — 학생, 사람 → 집
Dependency(의존 관계)	일시적으로 연관(관련성)을 유지하는 관계, 오퍼레이션의 매개 변수로 사용	회원 등급 ---> 할인율
Generalization(일반화 관계, = Inhreitance)	상위 개념과 하위 개념	(아메리카노, 에스프레소) —▷ 커피
Realization(실체화 관계)	사물을 공통된 특성(기능)으로 그룹화 할 수 있는 관계, 오퍼레이션 수행을 지정	(비행기, 새) ---▷ 날 수 있는
Aggregation(집합 관계)	하나의 사물이 다른 사물에 포함되어 있으나, 상호 독립적인 관계	컴퓨터 ◇– 프린터
Composition(포함 관계)	하나의 사물이 다른 사물에 포함되어 있으나, 상호 독립적이지 못한 관계	문 ◆— 열쇠

종류	내용
Class Diagram	클래스가 가지는 속성, 시스템 구조 파악
Object Diagram(객체)	객체 사이의 관계로
Component Diagram	인터페이스 표현 구현 단계에서 사용
Deployment Diagram(배치)	물리적 요소들의 위치를 표현 구현 단계에서 사용
Composite Structure Diagram(복합체 구조)	클래스나 컴포넌트가 복합 구조를 갖는 경우
Package Diagram	패키지들의 관계

종류	내용
Use Case Diagram	사용자의 요구 분석, 기능 모델링에 사용
Sequence Diagram	메세지 교환
Communication Diagram	메세지 교환 및 객체들 간의 연관 관계
State Diagram(상태)	상태 변화 또는 다른 객체와의 상호 작용, 럼바우(Rumbaugh) 객체지향 분석 기법에서 동적 모델링에 활용
Activity Diagram(활동)	처리의 흐름을 순서
Interaction Overview Diagram(상호작용 개요)	상호작용 제어 흐름을 표현
Timing Diagram	객체 상태 변화와 시간 제약

kkiyou

다음 포스트