1장 : 요구사항 확인(1과목)
1. 소프트웨어 생명 주기 (Software Life Cycle) ★★★
- 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.
- 소프트웨어 수명 주기 라고도 한다.
- 이를 통해 만든 모형을 ‘생명 주기 모형’ 또는 ‘소프트웨어 프로세스 모형’ 또는 ‘소프트웨어 공학 패러다임’이라고 한다.
- 모형의 종류
- 폭포수 모형: 가장 폭넓게 사용되며 가장 오래됨, 고전적 생명 주기 모형, 선형 순차적, 명확한 산출물
- 프로토타입 모형: 원형 모형, 요구사항이 불명확할 때 쓰임
- 나선형 모형: 점진적 모형, 위험 관리 및 최소화, 유지보수 과정 필요 없음, 대형 프로젝트에 유리
- 애자일 모형: 유연함에 초점, 짧은 개발 주기 반복, 스크럼, XP
보헴이 폭포수, 나선형, cocomo 모두 제안했다고 함... 욕심쟁이
2. 폭포수 모형 (Waterfall Model) ★★★
- 가장 오래된 방식(가장 전통적인 모형)이다.
- 가장 폭넓게 사용되는 방식이다.
- 고전적 생명 주기 모형이라고도 한다.
- 선형 순차적 모형이다. (= 개발 과정의 한 단계가 끝나야만 다음 단계 진행 가능)
- 메뉴얼을 작성해야 한다.
- 단계별 명확한 산출물이 필요하다.
- 두 개 이상의 과정이 동시에 수행되지 않는다.
3. 프로토타입 모형 (Prototype Model) ★★★
- 견본품을 만들어 최종 결과물을 예측한다.
- 원형 모형이라고도 한다.
4. 나선형 모형 (SM : Spiral Model) ★★★ 보헴(=cocomo 제안한 놈)이 제안
- 폭포수 모형의 장점 + 프로토타입 모형의 장점
- 점진적 모형이라고도 한다.
- 위험을 관리하고 최소화하는 것을 목표로 한다.
- 요구사항의 수정이 가능하다.
- 유지보수 과정이 필요 없다.
- 대형 프로젝트에 유리하다.
- '계획수립 - 위험분석 - 개발검증 - 고객평가' 4단계 반복
5. 애자일 모형 (Agile Model) ★★★
- 유연함에 초점을 맞춘 모형이다.
- 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는, 짧은 개발 주기를 반복한다.
- 고객의 의견을 적극 수용한다.
- 프로세스, 도구 < 개인과의 상호작용
- 방대한 문서 < 실행되는 SW
- 계약협상 < 고객과 협업
- 계획 < 변화에 반응
- 즉, 실용적임! 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
- 기법 종류
- 스크럼 (Scrum)
- XP (eXtreme Programming)
- ASD (Adaptive Software Development)
6. 스크럼(Scrum) 기법 ★★★
- 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 담긴 기법이다.
- 팀원 스스로가 팀을 구성하고, 개발 작업은 스스로 해결해야 한다. (Self-Organizing and Cross-Functional)
- 구성원
- 제품 책임자 (PO : Product Owner) : 백로그를 작성하는 주체이다.
- 스크럼 마스터 (SM : Scrum Master) : 조언을 해줄 뿐, 팀원을 통제하는 것을 목표로 하지 않는다.
- 개발팀 (DT : Development Team)
7. 스크럼 개발 과정 순서 ★★★
순서 | 과정 | 설명 |
1 | 제품 백로그 | 요구사항을 우선순위에 따라 나열한다. 지속적으로 업데이트한다. |
2 | 스프린트 계획 회의 | 단기 일정을 수립한다. 스프린트 백로그를 작성한다. |
3 | 스프린트 | 실제 개발 작업을 진행한다. 2~4주 소요된다. |
4 | 일일 스크럼 회의 | 모든 팀원과 함께 진행 상황을 점검한다. 15분정도 소요된다. |
5 | 스프린트 검토 회의 | 사용자와 함께 테스팅을 수행한다. |
6 | 스프린트 회고 | 규칙을 잘 준수했는지, 개선 사항은 없는지 등을 기록한다. |
8. XP(eXtreme Programming) 기법 ★★★
- 고객의 요구사항에 유연하게 대응한다.
- 짧고 반복적인 개발 주기를 가진다.
- 단순하게 설계한다.
- 테스트 과정에서 고객을 직접 참여시킨다.
- 모든 개발자들이 전체 코드에 대한 공동 책임을 가진다.
- 개발자 누구든지 어떤 코드라도 변경할 수 있다.
- 핵심 가치
- 의사소통
- 단순성
- 용기
- 존중
- 피드백
8-1. XP의 주요 실천 방법
- Pair Programming (짝 프로그래밍)
- Collective Ownership (공통 코드 소유)
- Test-Driven Development(테스트 주도 개발)
- Whole Team (전체 팀)
- Continuous Integration (계속적인 통합)
- Design Improvement (Refactoring) (디자인 개선 또는 리팩토링)
- Small Releases (소규모 릴리즈)
9. XP 개발 과정 순서 ★★★
순서 | 과정 | 설명 |
1 | 사용자 스토리 | 고객의 요구사항을 시나리오로 표현한다. 기능 단위로 내용을 구성한다. |
2 | 릴리즈 계획 수립 | 개발 완료 시점에 대한 일정을 수립한다. ** 릴리즈 : 부분적으로 기능이 완료된 제품을 제공하는 것 |
3 | 스파이크 | 신뢰성과 위험성을 위해 별도로 만드는 간단한 프로그램이다. |
4 | 이터레이션 | 릴리즈를 더욱 세분화 한 것이다. 새로운 스토리가 작성될 수 있다. |
5 | 승인 검사 | 고객이 직접 수행한다. 오류 사항은 다음 이터레이션에 포함한다. 우선순위가 변경될 수 있다. |
6 | 소규모 릴리즈 | 유연한 대응이 가능하다. |
10. 운영체제 (OS : Operation System) 가구기주성
- 사용자와 하드웨어 간의 인터페이스
- 효율적인 환경을 제공하는 소프트웨어
운영체제 관련 요구사항 식별 시 고려사항
1) 가용성: 프로그램이 주어진 시점에서, 요구사항에 따라 운영될 수 있는 능력
2) 구축 비용: 지원 가능한 하드웨어 비용, 유지 관리 비용 등
3) 기술 지원: 제작 업체의 안정적인 기술 지원, 정보 공유, 오픈 소스 여부 등
4) 주변 기기: 설치 가능한 하드웨어 등
5) 성능: 대규모 및 대용량 파일 작업 처리, 대규모 요청에 대한 처리 등
11. 데이터 베이스 관리 시스템 (DBMS : DataBase Management System) 가구기상성
- 데이터베이스를 관리해주는 소프트웨어
- 데이터의 종속성과 중복성 문제를 해결할 수 있다.
- 예 : Oracle, MySQL, Microsoft SLQ Server
DBMS 관련 요구사항 식별 시 고려사항
1) 가용성
2) 구축비용
3) 기술 지원
4) 상호 호환성: JDBC, ODBC와의 호환 여부, 설치 가능한 운영체제의 종류 등
5) 성능
** 종속성 <ㅡ> 독립성
12. 웹 애플리케이션 서버 (WAS : Web Application Server) 가구기성
- 웹 서버는 정적인 콘텐츠를 처리한다.
- 웹 애플리케이션 서버는 동적인 콘텐츠를 처리한다.
- 미들웨어 중 하나이다.
웹 애플리케이션 서버(WAS) 관련 요구사항 식별 시 고려사항
1) 가용성
2) 구축비용
3) 기술 지원
4) 성능
** 미들웨어 : 운영체제가 추가적으로 제공하는 소프트웨어
13. 요구사항 (Requirement)
- 서비스에 대한 설명, 제약조건 등을 의미한다.
- 소프트웨어 개발 또는 유지 보수에 대한 기준과 근거를 제공한다.
- 기술하는 내용에 따라
- 기능 요구사항
- 비기능 요구사항
- 기술 관점과 대상의 범위에 따라
- 시스템 요구사항 (개발자 관점)
- 사용자 요구사항 (사용자 관점)
14. 요구사항 개발 과정 (EASV) 도분명확
- 도출 (Elicitation)
- 서로의 의견을 교환, 식별, 이해하는 단계
- 의사소통이 중요하다.
- 소프트웨어 개발 생명 주기동안 지속적으로 반복된다.
- 분석 (Analysis)
- 명확하지 않은 요구사항을 거르는 단계
- 범위를 파악한다.
- 명세 (Specification)
- 문서화하는 단계
- 빠짐없이 명확히 기술해야 한다.
- 확인 (Validation)
- 검토하는 단계
15. 요구사항 분석
- 사용자에 대한 요구사항을 이해하고 문서화(명세화)하는 활동
16-1. 자료 흐름도(DFD, Data Flow Diagram)
- 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 자료 흐름 그래프, 버블 차트라고도 함
자료 흐름도의 네 가지 구성 요소
기호 | 의미 | 표기법 |
프로세스(Process) | 자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며 처리, 기능, 변환, 버블이라고도 함 |
원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입 |
자료 흐름(Data Flow) | 자료의 이동(흐름)이나 연관관계를 나타냄 | 화살표 위에 자료의 이름을 기입 |
자료 저장소(Data Store) | 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄 | 도형 안에 자료 저장소 이름을 기입 |
단말(Terminator) | 시스템과 교신하는 외부 개체로 입력 데이터가 만들어지고 출력 데이터를 받음 |
도형 안에 이름을 기입 |
16-2. 자동화 도구 CASE
- 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구로써 즉, 자동화 도구를 뜻함
이름 | 설명 |
SADT(Structured Analysis and Design Technique) | SoftTech사에서 개발한 것으로 블록 다이어그램을 채택한 자동화 도구 |
SREM(Software Requirements Engineering Methodology) | TRW사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발 |
PSL/PSA PSL(Problem Statement Language) PSA(Problem Statement Analyzer) |
미시간 대학에서 개발한 것 문제(요구사항) 기술 언어 PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서 출력 |
TAGS(Technology for Automated Generation of Systems) | 시스템 공학 방법 응용에 대한 자동 접근 방법으로 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구 |
16-3. HIPO(Hierarchy Input Process Output)
- 시스템의 분석 및 설계나 문서화할 때 사용되는 기법
- 하향식 소프트웨어 개발(전체에서 세부로)을 위한 문서화 도구
HIPO Chart의 종류
1) 가시적 도표: 시스템의 전체적인 기능과 흐름을 보여 주는 계층(Tree) 구조도
2) 총제적 도표: 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
3) 세부적 도표: 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
17. UML (Unified Modeling Language) ★★★
- 공통된 표현법을 사용하여 개발자와 고객, 또는 개발자간의 의사소통을 원활하게 해 주는 대표적인 객체지향 모델링 언어
- 표준화 객체지향 모델링 언어이다.
- 6개의 구조 다이어그램과, 7개의 행위 다이어그램을 작성할 수 있다.
- 구성 요소
- 사물 (Thing)
- 관계 (Relationship)
- 다이어그램 (Diagram)
17-1. UML 4 + 1 Model 구논배프유
- 고객 요구사항을 중심으로, 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture를 구축하는 설계 방법이다.
- De-fecto 표준이다.
- 기존의 view model의 한계를 극복할 수 있다.
- 기능적, 비기능적 요구사항을 동시에 만족시킨다.
구분 | 설명 | 응용 도구 |
Use-case View 유스케이스 뷰 |
사용자 관점이다. (end-user) 시스템 기능을 명세한다. |
Use-case Diagram User Story |
Logical View 논리 뷰 |
설계자 관점이다. (Designer) 전체 레이어를 구성한다. |
Class Diagram Sequence Diagram |
Implementation View 구현 뷰 |
개발자 관점이다. (Programmer) 컴포넌트 간의 상호관계를 정의한다. |
Package Diagram |
Process View 프로세스 뷰 |
시스템 통합 관점이다. (Integrator) 비기능적 요구사항을 기술한다. |
Activity Diagram |
Deployment View 배포 뷰 |
시스템 엔지니어 관점이다. (System Engineer) 물리적 노드 프로세스의 분산 및 배치를 한다. |
Deployment Diagram |
** De-fecto 표준 : 공식적으로 표준화 하지는 않았지만, 업계나 시장에서 사실상의 표준으로 받아들이고 사용하는 기술 및 방법
18. 사물 (Thing) = 객체(Object) ★★★ 구조, 행동, 그룹, 주해
- 가장 중요한 기본 요소
- 관계가 형성될 수 있는 대상
- 종류
- 구조 사물 : 개념적, 물리적 요소 (예 : class, use case, component, node)
- 행동 사물 : 행위 (예 : interaction, state machine)
- 그룹 사물 : 그룹 (예 : package)
- 주해 사물 : 설명, 제약 조건 (예 : note)
19. 관계 (Relationship) ★★★
- 사물과 사물 사이의 연관성
19-1. 연관 관계(Association)
- 서로 관련되어 있음을 표현
- 실선과 화살표로 표현
사람이 집을 소유하는 관계이다. 사람은 자기가 소유하고 있는 집에 대해 알고 있지만, 집은 누구에 의해 자신이 소유되고 있는지 모른다는 의미이다.
선생님은 학생을 가르치고, 학생은 선생님으로부터 가르침을 받는 것과 같이 선생님과 학생은 서로 관계가 있다
선생님 쪽에 표시된 다중도가 '1..*'이므로 학생은 한 명 이상의 선생님으로부터 가르침을 받는다
학생 쪽에 표시된 다중도가 '1..*'이므로 선생님은 한 명 이상의 학생을 가르친다
19-2. 집합 관계(Aggregation) 독립적, 속 빈 마름모
- 포함하는 쪽과 포함되는 쪽은 서로 독립이다.
- 포함되는 쪽(part)에서 포함하는 쪽(whole)으로 속이 빈 마름모를 연결하여 표시
프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결도 가능하다.
19-3. 포함 관계(Composition) 독립 X, 속이 채워진 마름모
- 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고, 생명주기를 함께한다.
- 포함되는 쪽(part)에서 포함하는 쪽(whole)으로 속이 채워진 마름모를 연결하여 표현
문을 열 수 있는 키는 하나이며, 해당 키로 다른 문을 열 수 없다. 문이 없으면 열쇠도 필요 없어진다.
19-4. 일반화 관계(Generalization) 사물과 사물을 일반/구체로 구분하며 속 빈 실선 화살표
- 더 일반적인지, 더 구체적인지를 표현
- 일반적인 개념을 상위, 부모 / 구체적인 개념을 하위, 자식이라 함
- 자식에서 부모 쪽으로 속이 빈 실선를 연결
커피에는 아메리카노와, 에스프레소가 있다.
19-5. 의존 관계(Dependency)
- 연관은 있지만, 필요에 의해 서로에게 영향을 주는, 짧은 시간 동안만 연관을 유지하는 관계
- 영향을 주는 사물(이용자)이 영향는 사물(제공자) 쪽으로 점선 화살표를 연결
등급이 높으면, 할인율을 적용하고, 등급이 낮으면 할인율을 적용하지 않는다.
19-6. 실체화 관계(Realization) 사물과 기능, 속 빈 점선 화살표
- 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계를 표현한다.
- 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
비행기와 새는 "날 수 있다"는 행위로 그룹화할 수 있다.
20. 다이어그램 (Diagram) ★★★
- 사물과 관계를 도형으로 표현한 것
- 종류
- 구조적 다이어그램 : 정적 모델링에서 사용
- 행위 다이어그램 : 동적 모델링에서 사용
21. 구조적 다이어그램 종류 ★★★ 클객컴배복패
클래스 다이어그램 | 클래스 간의 관계 표현 시스템 구조 파악 |
객체 다이어그램 | 객체 간의 관계 표현, 럼바우의 객체지향 분석 기법에서 객체 모델링에 활용 |
컴포넌트 다이어그램 | 컴포넌트 간의 관계 표현 구현 단계에서 사용 |
배치 다이어그램 | 물리적 요소들의 위치 표현 구현 단계에서 사용 |
복합체 구조 다이어그램 | 복합 구조 표현 |
패키지 다이어그램 | 그룹화한 패키지들의 관계 표현 |
22. 행위 다이어그램 종류 ★★★ 유시커상활상타
유스케이스 다이어그램 | 사용자 요구를 분석 기능 모델링 작업에 사용 |
시퀀스 다이어그램 | 시스템이나 객체들이 주고 받는 메시지를 표현 액터, 객체, 생명선, 실행 상자, 메시지로 구성됨 |
커뮤니케이션 다이어그램 | 메세지 뿐만 아니라, 연관까지 표현 |
상태 다이어그램 | 상태의 변화 표현, 럼바우의 객체지향 분석 기법에서 동적 모델링에 활용 |
활동 다이어그램 | 처리의 흐름을 순서에 따라 표현 |
상호작용 개요 다이어그램 | 제어 흐름 표현 |
타이밍 다이어그램 | 시간 제약 표현 |
23. 스테레오 타입(Stereotype)
- UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
- 길러멧(Guilemet)이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태를 기술
《include》 | 연결된 다른 UML 요소에 대해 포함 관계가 있는 경우 |
《extend》 | 연결된 다른 UML 요소에 확장 관계가 있는 경우 |
《interface》 | 인터페이스를 정의하는 경우 |
《exception》 | 예외를 정의하는 경우 |
《constructor》 | 생성자 역할을 수행하는 경우 |
24. 접근제어자
접근제어자 | 표현법 | 내용 |
public | + | 어떤 클래스라도 접근 가능 |
private | - | 해당 클래스 내부에서만 접근 가능 |
protected | # | 동일 패키지 내의 클래스 또는 해당 클래스를 상속받은 외부 패키지의 클래스에서 접근 가능 |
default | ~ | 동일 패키지 내부에 있는 클래스에서만 접근 가능 |