3구 개발 및 보안

1. 스크럼의 개요

스크럼이란 럭비 경기에서 양팀이 서로 대치해 있는 대형을 일컫는 것으로 팀의 중요성을 강조하는 용어이다.

• 스크럼은 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다.

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

제품 책임자(PO; Product Owner)

 -> 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정한 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당한다.

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

 -> 요구사항이 담긴 백로그(Backlog)를 작성하고 백로그에 대한 우선수이를 지정한다.

 -> 팀원들이 백로그에 스토리를 추가할 수는 있지만 우선순위를 지정할 수 없다.

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

스크럼 마스터(SW; Scrum Master)

 -> 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행한다. 팀원들을 통제하는 것이 목표가 아니다.

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

개발팀(Dt; Develpment Team)

-> 모든 사람이 팀원이다. 개발자 외에도 디자이너, 테스터 등 개발을 위해 참여하는 모든 사람이 대상이 된다.

-> 최대 인원 7~8명이 적당

2. 스크럼 개발 프로세스

제품 백로그(Product Backlog)

 -> 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록이다.

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

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

스프린트 계획 회의(Sprint Planning Meeting)

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

-> 스프린트에서 처리할 요구사항(User Story)을 개발자들이 나눠서 작업할 수 있도록 테스크(Task)라는 작업 단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그(Sprint Backlog)를 작성한다.

스프린트(Sprint)

-> 실제 개발 작업을 진행하는 과정으로, 보통 2 ~ 4주 정도로 진행

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

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

-> 개발 담당자에게 할당된 태스크는 보통 할 일(To Do), 진행 중(In Progress), 완료(Done)의 상태를 갖는다.

일일 스크럼 회의(Daily Scrum Meeting)

-> 약속 된 시간에 약 15분 정도 진행 사항을 점검

-> 회의는 보통 서서 진행, 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시

-> 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와준다.

스프린트 검토 회의(Sprint Review)

-> 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행한다.

-> 스프린트의 한 주당 한 시간 내에서 진행한다.

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

스프린트 회고(Sprint Retrospective)

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

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

이상포스터를 마치겠습니다.

안녕하세요 정보처리기사 필기를 준비하고 있는 3구입니다. 저는 A부분 중요한 부분만 포스팅하겠습니다.

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

 소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다.

• 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다.

• 개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수 있고, 개별적인 모형을 사용할 수도 있다.

• 소프트웨어 생명 주기에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있다.

2. 폭포수 모형(Waterfall Model)

 폭포수 모형은 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 있습니다. 즉, 처음부터 조립해서 물건을 만들었는데 조립한 뒤 분해할 수 없다는 것입니다.

• 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 소ㅍ프트웨어 생명 주기 모형, 고전적 생명 주기 모형이라고도 함

• 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형이다.

• 제품의 일부가 될 매뉴얼을 작성해야 한다.

• 각각의 단계가 끝난 후 다음 단계를 수행하기 위한 결과물이 명확하게 산출 되어야 한다.

• 두 개 잏상의 과정이 병행하여 수행되지 않는다.

타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

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

 프로토타입 모형은 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품을 만들어 최종 결과물을 예측하는 모형이다.

• 시제품은 사용자와 시스템 사이의 인터페이스 중점을 두어 개발

• 시트템의 모형을 만드는 과정으로서 요구된 소프트웨어를 구현하는데, 이는 추후 구현 단계에서 사용될 골격 코드가 된다.

• 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보안하기 위한 모형이다.

4. 나선형 모형(Spiral Model, 점진적 모형)

 나선형 모형은 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.

• 나선을 따라 돌듯이 소프트웨어 개발 과정을 여러번 반복하면서 진행하는 개발 방법, 점진적 모형이라고도 함

• 위험을 관리하고 최소화하는 것을 목적

• 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없다.

계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가

5. 애자일 모형(Agile Model)

  애자일은 '민첩한', '기만한'이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다.

• 애자일 모형은 고객의 다양한 요구사항의 변화에 유연하게 대응하기 위해 일정한 개발 주기를 반복하는 것이 핵심!!

• 고객과의 소통에 초점을 맞춘 방법론

• 스프린트(Sprint) , 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용한다.

• 고객의 요구사항에 우선순위를 부여하여 개발 작업을 진행

• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합

• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형이는 스크럼(Scrum), XP(eXtrem Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(adaptive Software Development), FDD(Feature Driven Develpment), DSDM(Dynamic System Develpment Method), DAD(Disciplined Agile Delivery)등이 있다.

애자일 개발 4가지 핵심 가치

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

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

3. 고객과 협업에 더 가치를 둔다

4. 변화에 반응하는 것에 더 가치를 둔다.

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

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

1. 고객을 만족시킨다.

2. 요구사항 변경을 적극 수용한다.
3. 주 단위로 실행되는 소프트웨어를 제공
4. 프로젝트 기간에 함께 일한다. (고객, 개발자)
5. 의자가 확실한 사람들로 팀을 구성, 개발 환경과 지원을 제공, 일을 잘 끝낼 수 있도록 신뢰
6. 얼굴을 맞대고 의견을 낸다.
7. 1차 기준은 작동하는 소프트웨어인지 확인
8. 일정한 속도로 개발을 진행한다.
9. 관심을 기울이면 민첩성이 향상된다.
10. 단순화를 추구한다.
11. 자기 스스로 일을 주도하는 조직적인 팀으로부터 나온다.
12. 효과적인 팀이 될 수 있는 방안을 정기적으로 깊이 고민하고 그에 따라 팀의 행동을 조정한다.

음... 애자일 개발은 못 할 것 같네요^^ 전,,

이상포스터를 마치겠습니다.