2020 정보처리기사 필기 : 1과목 : 1장

 1장 : 요구사항 확인

---

1. 소프트웨어 생명 주기 (Software Life Cycle) ★★★

• 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것. 
• 소프트웨어 수명 주기 라고도 한다.
• 이를 통해 만든 모형을 ‘생명 주기 모형’ 또는 ‘소프트웨어 프로세스 모형’ 또는 ‘소프트웨어 공학 패러다임’이라고 한다. 
• 모형의 종류
  • 폭포수 모형
  • 프로토타입 모형
  • 나선형 모형
  • 애자일 모형

---

2. 폭포수 모형 (Waterfall Model) ★★★

• 가장 오래된 방식이다. 
• 가장 폭넓게 사용되는 방식이다. 
• 고전적 생명 주기 모형이라고도 한다. 
• 선형 순차적 모형이다. 
• 메뉴얼을 작성해야 한다. 
• 단계별 명확한 산출물이 필요하다. 
• 두 개 이상의 과정이 동시에 수행되지 않는다. 

---

3.     프로토타입 모형 (Prototype Model) ★★★

• 견본품을 만들어 최종 결과물을 예측한다. 
• 원형 모형이라고도 한다.  

---

4.     나선형 모형 (SM : Spiral Model) ★★★

• 폭포수 모형의 장점 + 프로토타입 모형의 장점
• 점진적 모형이라고도 한다. 
• 위험을 관리하고 최소화하는 것을 목표로 한다. 
• 요구사항의 수정이 가능하다. 
• 유지보수 과정이 필요 없다. 
• 대형 프로젝트에 유리하다. 

---

5.     애자일 모형 (Agile Model) ★★★

• 유연함에 초점을 맞춘 모형이다. 
• 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는, 짧은 개발 주기를 반복한다. 
• 고객의 의견을 적극 수용한다. 
• 기법 종류
  • 스크럼 (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
• Test-Driven Development
• Whole Team
• Continuous Integration
• Design Improvement (Refactoring)
• Small Releases

---

9.     XP 개발 과정 순서 ★★★

순서	과정	설명
1	사용자 스토리	고객의 요구사항을 시나리오로 표현한다.  기능 단위로 내용을 구성한다.
2	릴리즈 계획 수립	개발 완료 시점에 대한 일정을 수립한다.  ** 릴리즈 : 부분적으로 기능이 완료된 제품을 제공하는 것
3	스파이크	신뢰성과 위험성을 위해 별도로 만드는 간단한 프로그램이다.
4	이터레이션	릴리즈를 더욱 세분화 한 것이다.  새로운 스토리가 작성될 수 있다.
5	승인 검사	고객이 직접 수행한다.  오류 사항은 다음 이터레이션에 포함한다.  우선순위가 변경될 수 있다.
6	소규모 릴리즈	유연한 대응이 가능하다.

---

10. 운영체제 (OS : Operation System)

• 사용자와 하드웨어 간의 인터페이스
• 효율적인 환경을 제공하는 소프트웨어

 

 

** 가용성 : 프로그램이 주어진 시점에서, 요구사항에 따라 운영될 수 있는 능력

---

11. 데이터 베이스 관리 시스템 (DBMS : DataBase Management System)

• 데이터베이스를 관리해주는 소프트웨어
• 데이터의 종속성과 중복성 문제를 해결할 수 있다. 
• 예 : Oracle, MySQL, Microsoft SLQ Server

 

 

** 종속성 <ㅡ> 독립성

---

12. 웹 애플리케이션 서버 (WAS : Web Application Server)

• 웹 서버는 정적인 콘텐츠를 처리한다.
• 웹 애플리케이션 서버는 동적인 콘텐츠를 처리한다.
• 미들웨어 중 하나이다.

 

 

** 미들웨어 : 운영체제가 추가적으로 제공하는 소프트웨어

---

13. 요구사항 (Requirement)

• 서비스에 대한 설명, 제약조건 등을 의미한다.
• 소프트웨어 개발 또는 유지 보수에 대한 기준과 근거를 제공한다. 
• 기술하는 내용에 따라
  • 기능 요구사항 
  • 비기능 요구사항 

•  기술 관점과 대상의 범위에 따라
  • 시스템 요구사항 (개발자 관점)
  • 사용자 요구사항 (사용자 관점) 

---

14. 요구사항 개발 과정 (EASV)

• 도출 (Elicitation)
  • 서로의 의견을 교환, 식별, 이해하는 단계
  • 의사소통이 중요하다. 
  • 소프트웨어 개발 생명 주기동안 지속적으로 반복된다.

• 분석 (Analysis)
  • 명확하지 않은 요구사항을 거르는 단계
  • 범위를 파악한다. 

• 명세 (Specification)
  • 문서화하는 단계
  • 빠짐없이 명확히 기술해야 한다. 

• 확인 (Validation) 
  • 검토하는 단계

---

15. 요구사항 분석 기법

• 요구사항 분류 : 기능 요구사항과 비기능 요구사항으로 분류한다. 
• 개념 모델링 : 관점에 맞게, 다양하게 표현한다. 
• 요구사항 할당
• 요구사항 협상
• 정형 분석 : 정형화된 언어를 이용하여, 마지막 단계에서 수행한다. 

---

16. 요구사항 확인 기법

• 요구사항 검토
• 프로토타이핑
• 모델 검증
• 인수 테스트

---

17. UML (Unified Modeling Language) ★★★

• 표준화 객체지향 모델링 언어이다.
• 6개의 구조 다이어그램과, 7개의 행위 다이어그램을 작성할 수 있다. 
• 구성 요소
  • 사물 (Thing)
  • 관계 (Relationship)
  • 다이어그램 (Diagram)

---

18. 사물 (Thing) ★★★

• 가장 중요한 기본 요소
• 관계가 형성될 수 있는 대상
• 종류
  • 구조 사물 : 개념적, 물리적 요소 (예 : class, use case, component, node)
  • 행동 사물 : 행위 (예 : interaction, state machine)
  • 그룹 사물 : 그룹 (예 : package)
  • 주해 사물 : 설명, 제약 조건 (예 : note)

---

19. 관계 (Relationship) ★★★

• 사물과 사물 사이의 연관성

 

19-1. 연관 관계

• 서로 관련되어 있음을 표현
• 실선과 화살표로 표현

사람이 집을 소유하는 관계이다. 살람은 자기가 소유하고 있는 집에 대해 알고 있지만, 집은 누구에 의해 자신이 소유되고 있는지 모른다는 의미이다. 

선생님은 학생을 가르치고, 학생은 선생님으로부터 가르침을 받는 것을 의미한다.   

 

 

19-2. 집합 관계

• 포함하는 쪽과 포함되는 쪽은 서로 독립이다.

프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결도 가능하다. 

 

 

19-3. 포함 관계

• 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고, 생명주기를 함께한다.

문을 열 수 있는 키는 하나이며, 해당 키로 다른 문을 열 수 없다. 문이 없으면 열쇠도 필요없어진다. 

 

 

19-4. 일반화 관계

• 더 일반적인지, 더 구체적인지를 표현

커피에는 아메리카노와, 에스프레소가 있다. 

 

 

19-5. 의존 관계

• 연관은 있지만, 필요에 의해 서로에게 영향을 주는, 짧은 시간 동안만 연관을 유지하는 관계

등급이 높으면, 할인율을 적용하고, 등급이 낮으면 할인율을 적용하지 않는다. 

 

 

19-6. 실체화 관계

• 사물이 할 수 있거나 해야 하는 기능으로 설로를 그룹화 할 수 있는 관계를 표현한다.

비행기와 새는 "날 수 있다"는 행위로 그룹화할 수 있다. 

---

20. 다이어그램 (Diagram) ★★★

• 사물과 관계를 도형으로 표현한 것
• 종류
  • 구조적 다이어그램 : 정적 모델링에서 사용
  • 행위 다이어그램 : 동적 모델링에서 사용

---

21. 구조적 다이어그램 종류 ★★★

클래스 다이어그램	클래스 간의 관계 표현 시스템 구조 파악
객체 다이어그램	객체 간의 관계 표현
컴포넌트 다이어그램	컴포넌트 간의 관계 표현 구현 단계에서 사용
배치 다이어그램	물리적 요소들의 위치 표현 구현 단계에서 사용
복합체 구조 다이어그램	복합 구조 표현
패키지 다이어그램	그룹화한 패키지들의 관계 표현

---

22. 행위 다이어그램 종류 ★★★

유스케이스 다이어그램	기능 모델링 작업에 사용
시퀀스 다이어그램	시스템이나 객체들이 주고 받는 메시지를 표현
커뮤니케이션 다이어그램	메세지 뿐만 아니라, 연관까지 표현
상태 다이어그램	상태의 변화 표현
활동 다이어그램	처리의 흐름을 순서에 따라 표현
상호작용 개요 다이어그램	제어 흐름 표현
타이밍 다이어그램	시간 제약 표현