[정보처리기사] 필기 시나공 요약 1과목 소프트웨어 설계 - 요구사항 확인

개발과 관련한 소스는 보통 깃허브를 통해 관리하다 처음으로 작성하는 티스토리 글. 개발자는 아니고, 해양학 전공자인 현업이기에 공부하면서 기록용으로 하나둘씩 글로 써보기로 하였다.

 

첫 시작은 퇴사 후 가장 먼저 공부하고 싶었던 '정보처리기사' 자격증을 준비하며 매일 공부한 내용을 조금씩 남겨보고, 시간이 된다면 DB 쪽도 다뤄볼 까 생각중이다.

 

정보처리기사 필기와 실기는 시험 영역이 같으며, 총 5과목으로 구성되어있다. 소프트웨어 설계, 소프트웨어 개발, 데이터베이스 구축, 프로그래밍 언어 활용, 정보시스템 구축 관리로 되어 있으며, [1과목 소프트웨어 설계] - [요구사항 확인]부터 다뤄보도록 하겠다.

출처: 2022 시나공 정보처리기사 필기, 길벗출판사

1. 소프트웨어 생명 주기

소프트웨어 개발 방법론의 바탕이 되는 것. 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며 다양한 형태가 존재(폭포수, 프로토타입, 나선형, 애자일 등)

 

1-1. 폭포수 모형(Waterfall Model)

가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형으로, 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형

 

1-2. 프로토타입 모형(Prototype Model)

소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위해 개발된 모형(시제품을 만들어 최종 결과물 예측)

 

1-3. 나선형 모형(Spiral Model)

보헴(Boehm)이 제안한 것으로 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것(계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가)

 

1-4. 애자일 모형(Agile Model)

고객과의 소통에 초점을 맞춘 방법론. 스프린트(Sprint) 혹은 이터레이션(Iteration) 등 짧은 개발 주기를 반복하며 고객의 평가와 요구를 적극 수용하는 모형(스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발, DSDM, DAD 등)

2. 스크럼(Scrum) 기법

팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어. 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성. 스크럼 개발 프로세스는 제품 백로그, 스프린트 계획 회의, 스프린트, 일일 스크럼 회의, 스프린트 검토 회의, 스프린트 회고 순서

 

출처: 위키피디아, 스크럼 (애자일 개발 프로세스)

2-1. 제품 책임자(PO: Product Owner)

이해관계자들 중 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람. 제품에 대한 요구사항이 담긴 백로그를 작성하고 우선순위를 지정

 

2-2. 스크럼 마스터(SM: Scrum Master)

팀이 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할. 스크럼 회의를 주관 및 진행 사항을 점검

 

2-3. 개발팀(DT: Development Team)

PO와 SM을 제외한 모든 팀원. 디자이너, 테스터 등 개발을 위해 참여하는 모든 대상

 

2-4. 제품 백로그(Product Backlog)

제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열. 지속적으로 업데이트 되며, 스토리를 기반으로 릴리즈 계획을 수립

 

2-5. 스프린트 계획 회의(Sprint Planning Meeting)

제품 백로그 중 단기 일정을 수립하는 과정. 스토리를 태스크(Task) 단위로 나눈 후 작업 목록인 스프린트 백로그(Sprint Backlog)를 작성

 

2-6. 스프린트(Sprint)

보통 2~4주 정도의 기간 내에 진행하는 실제 개발 작업. 태스크는 'To do, In Progress, Done'의 상태를 갖음

 

2-7. 일일 스크럼 회의(Daily Scrum Meeting)

매일 15분 정도의 짧은 시간동안 진행사항을 점검. 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표기

 

2-8. 스프린트 검토 회의(Sprint Review)

User Story에 잘 부합하는 지 사용자가 포함된 참석자 앞에서 일주일에 1시간 테스팅을 수행. PO가 피드백을 정리 후 백로그에 업데이트

 

2-9. 스프린트 회고(Sprint Retrospective)

스프린트 주기를 되돌아보며 규칙 준수, 개선점 등을 확인하는 작업

3. XP(eXtreme Programming) 기법

고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화. 소프트웨어를 빠르게 개발하는 것이 목적. 5대 핵심가치로 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)이 있음

 

3-1. 사용자 스토리(User Story)

XP 개발 프로세서의 첫 단계로, 고객의 요구사항을 간단한 시나리오로 표현

 

3-2. 릴리즈 계획 수립(Release Planning)

부분 혹은 전체 개발 완료 시점에 대한 일정 수립

 

3-3. 스파이크(Spike)

신뢰성을 높이고 기술 문제에 대한 위험성을 감소시키기 위해 별도로 만드는 간단한 프로그램

 

3-4. 이터레이션(Iteration)

하나의 릴리즈를 더 세분화한 단위로 보통 1~3주의 기간.

 

3-5. 승인 검사(Acceptance Test)

하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트

 

3-6. 소규모 릴리즈(Small Release)

고객의 반응을 기능별로 확인하여 더 유연하게 대처하기 위함

 

3-7. XP의 주요 실천 방법(Practice)

짝 프로그래밍(Pair Programming), 공동 코드 소유(Collective Ownership), 테스트 주도 개발(Test-Driven Development), 전체 팀(Whole Team), 계속적인 통합(Continuous Integration), 디자인 개선(Design Improvement) or 리팩토링(Refactoring), 소규모 릴리즈(Small Releases)

1일차 공부 기록을 작성하였으며, 현행 시스템 파악부터 글 수정을 통해 업로드 예정입니다.