2025 정보처리기사 필기 도전기 2 - 소프트웨어 설계

1차 공부 자료

https://codespecialist.tistory.com/57

2025 정보처리기사 필기 도전기 1 - 소프트웨어 설계

 

안녕하세요. 오늘은 2일 차 공부내용 공유드립니다! 일하면서 자격증 공부하기가 쉽지 않네요 ㅠㅠ ㅎㅎ

 

■ 애자일 선언

2011년 17명의 애자일 전문 개발자가 공통의 관점을 정리해 '애자일 SW 개발 선언문'을 만들었습니다.

선언문에는 애자일 개발 철학이 담겨있는 4가지 핵심 가치와 애자일 개발을 실무에 적용할 때 기준이 되는 12가지 실행지침이 담겨져 있는데, 그 내용은 다음과 같음.

 

애자일개발 4가지 핵심가치 ※시험에 나온 적이 있는 영역

1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.

4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

애자일 개발 12가지 실행지침

1. 유용한 소프트웨어를 빠르고 지속적으로 제공하여 고객을 만족시킨다.

2. 개발 막바지라도 요구사항 변경을 적극 수용한다.

3. 몇개월이 아닌 몇 주단위로 실행되는 소프트웨어를 제공한다.

4. 고객과 개발자가 프로젝트 기간에 함께 일한다.

5. 개발에 대한 참여 의지가 확실한 사람들로 팀을 구성하고, 필요한 개발 환경과 지원을 제공하며, 일을 잘 끝낼 수 있도록 신뢰한다.

6. 같은 사무실에서 얼굴을 맞대고 의견을 나눈다.

7. 개발의 진척도를 확인하는 1차 기준은 작동하는 소프트웨어이다.

8. 지속가능한 개발을 장려하고 일정한 속도로 개발을 진행한다.

9. 기술적 우수성과 좋은 설계에 지속적인 관심을 기울이면 민첩성이 향상된다.

10. 단순화를 추구한다.

11. 최상의 아키텍처, 명확한 요구사항, 최상의 설계는 자기 스스로 일을 주도하는 조직적인 팀으로부터 나온다.

12. 더 효과적인 팀이 될 수 있는 방안을 정기적으로 깊이 고민하고 그에 따라 팀의 행동을 조정한다.

 

■ 폭포수 모형과 애자일의 비교

구분	폭포수 모형	애자일
새로운 요구사항 반영	어려움	지속적으로 반영
고객과의 의사소통	적음	지속적임
테스트	마지막에 모든기능을 테스트	반복되는 일정 주기가 끝날때마다 테스트
개발 중심	계획,문서(매뉴얼)	고객

 

애자일 모형을 기반으로 한 소프트웨어 개발 유형

■ 스크럼의 개요

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말한다. 스크럼은 이처럼 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어

스크럼은 팀원 스스로가 스크럼 팀을 구성해야하며, 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야함.

스크럼팀은 제품책임자, 스크럼마스터, 개발팀으로 구성된다.

제품책임자(PO)

1. 이해관계자들(소프트웨어 사용자, 개발자, 의뢰자 등) 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당함.

2. 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체

3. 요구사항이 담긴 백로그(=스토리)를 작성하고 백로그에 대한 우선순위를 지정함

4. 팀원들이 백로그에 스토리를 추가할 수는 있지만 우선순위는 지정할 수는 없다. ※ 우선순위는 오직 제품관계자만 지정

5. 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신함.

 

스크럼 마스터

1. 스크럼팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행

※ 팀원들을 통제하는 것이 목표가 아니다.

2. 일일 스크럼 회의를 주관하여 진행사항을 점검하고, 개발과정에서 발생된 장애 요소를 공론화하여 처리함.

 

개발팀

1. 제품책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스트 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됨

2. 보통 최대인원은 7~8명이 적당하다.

 

■ 스크럼 개발 프로세스

 

제품 백로그

1. 제품개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록

2. 개발 과정에서 새롭게 도출되는 요구사항으로 인해 지속적으로 업데이트됨

3. 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획을 수립함.

 

스트리트 계획 회의

1. 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것

2. 스프린트에서 처리할 요구사항을 개발자들이 나눠서 작업할 수 있도록 테스트라는 작업단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성함.

 

스프린트

1. 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행함.

2. 스프린트 백로그에 작성된 태스크를 대상으로 작업시간(양)을 추정한 후 개발 담당자에게 할당함.

3. 테스트크를 할당할 때는 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 것이 좋다.

4. 개발 담당자에게 할당된 태스크는 보통 할 일(Todo), 진행 중(inProgress), 완료(Done)의 상태를 갖는다.

 

일일스크럼회의

1. 모든 팀원이 매일 약속된 시간에 15분 정도의 짧은 시간 동안 진행 상황을 점검함.

2. 회의는 보통 서서 진행하며, 남은 작업시간은 소멸차트에 표시함.

3. 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌

 

스프린트 검토 회의

1. 부분 또는 전체 완성제품이 요구상황에 잘 부합되는지 사용자가 포함된 참석자 앞에서 태스크를 수행함.

2. 스프린트의 한 주당 한 시간 내에서 진행함.

3. 제품책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트함.

 

스프린트 회고

1. 스프린트 주기를 되돌아보며, 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록함.

2. 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행함