3구 개발 및 보안

1. 네트워크 설치 구조

통신망은 정보를 전달하기 위해서 통신 규약에 의해 연결한 통신 설비의 집합이다.

2. 성형(Star, 중앙 집중형)

성형은 중앙에 중앙 컴퓨터가 있고, 이를 중심으로 단말장치들이 연결되는 중앙 집중식의 네트워크이다.

• 포인트 투 포인트 방식이다.

• 중앙 컴퓨터를 통하여 데이터를 교환이다.

• 단말장치 추가, 제거 쉽다.

• 하나가 고장나더라도 다른 단말장치에 영향을 주지 않음, 중앙이 고장나면 전체 통신 마비가 된다.

• 교환 노드의 수가 가장 적다.

3. 링형(Ring,루프형)

링형은 서로 이웃하는 것끼리 포인트 투 포인트(Point-to-Point)방식으로 연결시킨 형태이다.

• 분산 및 집중 제어 모두 가능하다.

• 단말장치의 추가/ 제거 및 기밀 보호가 어렵다.

• 전송 지연이 발생할 수 있다.

• 중계기의 수가 많아진다.

• 데이터는 단방향, 양방향으로 전송할 수 있으며, 단방향의 링의 경우 컴퓨터, 단말장치, 통신 회선 중 어느 하나라도 고장나면 전체 통신망에 영향을 미친다.

4. 버스형(Bus)

버스형은 한 개의 통신 회선에 여러 대의 단말장치가 연결되어 있는 형태이다.

• 물리적 구조가 간단하고, 추가와 제거가 용이하다.

• 단말장치가 고장나더라도 전체에 영향을 주지 않는다. 신뢰성을 높일 수 있다.

• 기밀 보장이 어렵고, 통신 회선의 길이에 제한이 있다.

5. 계층형(Tree, 분산형)

계층형은 중앙 컴퓨터와 일정 지역의 단말장치까지는 하나의 통신 회선으로 연결시키고, 이웃하는 단말장치는 일정 지역 내에 설치된 중간 단말장치로부터 다시 연결시키는 형태이다.(분산)

6.망형(Mesh)

망형은 모든 지점과 서로 연결한 형태, 노드의 연결성이 높다.

• 많은 양의 통신을 필요로 하는 경우에 유리하다.

• 공중 데이터 통신망에서 사용되며, 통신 회선의 총 경로가 가장 길다.

• 회선 장애 시 다른 경로를 통하여 데이터를 전송할 수 있다.

• 모든 노드를 망형으로 연결하려먼 노드의 수가 n개 일 때, n(n-1)/2개의 회선이 필요하고 노드의 n-1개의 포트가 필요하다.

예를 들어 25개의 노드를 망형으로 연결할 때 회선 수 = n(n-1) / 2 = 25(25-1)/2 = 600 = 300(개) , 포트수 = n-1 = 24개

7. 네트워크 분류

두 가지의 종류가 있다 . LAN과 WAN이 있다.

근거리 통신망(LAN; Local Area Network)는 회사, 학교, 연구소 등에서 비교적 가까운 거리에 있는 컴퓨터, 프린터, 테이프 등과 같은 자원을 연결하여 구성한다. 주로 공유 목적이며 버스형이나 링형 구조를 사용하며 전송 속도가 빠르며, 에러 발생율이 낮다.

광대역 통신망(WAN; Wide Area Network)는 국가, 대륙과 대륙 등과 같이 멀리 떨어진 사이트들을 연결하여 구성한다. 통신 속도가 느리고, 에러 발생률이 높다.

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

1. UI 프로토타입의 개요

프로토타입은 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형, 테스트가 가능하다.

• 사용자의 요구사항을 개발자가 맞게 해석했는지 검증하기 위한 것, 최대한 간단하게

• 일부 핵심적인 기능만을 제공, 최종 제품의 작동 방식을 이해 시키는데 필요한 기능은 반드시 포함

• 사용자의 요구사항이 모두 반용될 때까지 프로토타입을 계속하여 개선하고 보완해야 한다.

• 프로토타이핑 및 테스트를 거치지 않고는 실제 사용자와 제품 간의 상호 작용 방식을 예측하기 어려우므로 실제 사용자를 대상으로 테스트하는 것이 좋다.

2. UI프로토타입의 장 단점

3. 프로토타이핑의 종류

4. UI프로토타입 계획 및 작성 시 고려 사항

개발 계획을 수립하는 과정과 프로토타입의 개발한 후 결과를 보고하는 과정으로 진행

5. UI 프로토타입 제작 단계

1. UI 설계 도구

사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구

즉, 건물을 짓기 전에 건물에 대한 설계도를 그리듯이 UI도 그렇게 함

UI종류

2. 와이어프레임(Wireframe)

기획 단계의 초기에 제작하는 것, 페이지에 대한 개략적인 레이아웃이나 UI요소 등에 대한 뼈대를 설계하는 단계

• 제작할 때는 각 페이지의 영역 구분, 콘텐츠, 텍스트 배치 등을 화면 단위로 설계한다.

• 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 와이어프레임을 사용한다.

• 와이어프레임 툴 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

3. 목업(Mockup)

디자인, 사용 방법, 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형이다.

• 시각적으로만  구성 요소를 배치하는 것

• 목업 툴 : 파워 목업, 발사믹 목업 등

4. 스토리보드(Story Board)

와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서이다.

• 디자이너와 개발자가 최종적으로 참고하는 작업 지침서, 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의 등 서비스 구축을 위한 모든 정보가 들어 있다.

• 상단이나 우측에는 제목, 작성자 등을 입력하고, 좌측에는 UI화면 우측에는 디스크립션을 기입

• 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분, 명확하고 세부적으로 작성해야 한다.

• 스토리보드 툴 : 파워포인트, 키노트, 스케치, Axure 등

5. 프로토타입(Prototype)

인터랙션을 적용, 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

• 사용자 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플

• 작성 방법에 따라 페이퍼 프로토타입과 디지털 타입으로 나눔

• 프로토타입 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등

6. 유스케이스(Use Case)

사용자 측면에서의 요구사항, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

• 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화할 수 있다.
• 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것, 다이어그램 형식으로 묘사

• 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성한다.

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

1. 사용자 인터페이스(UI, User Interface)의 개요

사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어를 의미

• 정보 내용을 전달하기 위한 표현 방법

사용자 인터페이스의 세 가지 분야

- 정보 제공과 전달을 위한 물리적 제어에 관한 분야

- 콘텐츠의 상세적인 표현과 전체적인 구성에 관하 분야

- 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야

2. 사용자 인터페이스(UI)의 특징

• 사용자의 만족도에 가장 큰 영향을 미치는 중요한 요소

• 사용자의 편리성과 가독성을 높임, 작업 시간을 단축시키고 업무에 대한 이해도를 높여준다.

• 최소한의 노력으로 원하는 결과를 얻음

• 기능에 대해 구체적인 방법을 제시

• 정보 제공자와 공급자 간의 매개 역할을 수행

• 사용자 인터페이스를 설계하기 위해서는 소프트웨어 아키텍처를 반드시 숙지해야 한다.

3. 사용자 인터페이스 구분

• CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

• GUI(Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

• NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

4. 사용자 인터페이스의 기본 원칙

• 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.

• 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 한다.

• 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.

• 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 한다.

5. 사용자 인터페이스의 설계 지침

• 사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용할 수 있어야 한다.

• 일관성 : 버튼이나 조작 방법 등을 일관성 있게 해야한다.

• 단순성 : 인지적 부담을 감소시켜야 한다.

• 결과 예측 가능 : 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다.

• 가시성 : 최대한 조작이 쉽도록 설계해야 한다.

• 표준화 : 한 번 학습한 이후에는 쉽게 사용할 수 있도록 설계해야 한다.

• 접근성 : 연령, 성별 등 다양한 계층이 사용할 수 있도록 설계해야 한다.

• 명확성 : 개념적으로 쉽게 인지할 수 있게 해야 한다.

• 오류 발생 해결 : 쉽게 인지할 수 있도록 설계해야 한다.

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

1. UI 설계 도구

UI종류에는 와이어프레임, 목업, 스토리보드 , 프로토타입, 유스케이스 등이 있다.

2. 와이퍼프레임(Wireteframe)

초기에 제작하는 것, 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계

• 와이어프레임을 제작할 때는 각 페이지의 영역 구분, 콘텐츠, 텍스트 배치 등을 화면 단위로 설계

• 개발자, 디자이너 등이 레이아웃을 협의 or 현재 진행 상태 등을 공유하기 위해 사용

• 와이어프레임 툴: 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

3. 목업(Mockup)

디자인, 사용방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형

• 시각적으로 구성 요소를 배치

• 목업 툴 : 파워목업, 발사믹 목업 등

4. 스토리보드(Story Board)

와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서

• 최종적으로 참고하는 작업 지침서, 정책, 프로세스, 콘텐츠 구성, 와이어프레임 등 서비스 구축을 위한 모든 정보

• 상단,우측에는 제목, 작성자 등으 입력, 좌측에는 UI화면, 우측에는 디스크립션을 기입

• 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분

• 스토리보드 툴 : 파워포인트, 키노트,  스케치, Axure 등

5. 프로토타입(Prototype)

와이어프레임, 스토리보드 등에 인터랙션을 적용하면서 실제 구현 된 것처럼 테스트가 가능한 동적인 형태의 모형

• 사용성 테스타트나 작업자 간 서비스 이해를 위해 작성하는 샘플

• 작성 방법에 따라 페이퍼 프로토타입과 디지털 프로토타입으로 나뉜다.

• 프로타입 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, ㅏ카오 오븐 등

6. 유스케이스(USe Case)

사용자 측면에서의 요구사항, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술

• 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화 할 수 있다.

• 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것으로, 다이어그램형식으로 묘사

• 유스케이스가 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성한다.

인터랙션(Interaction)이란?

사용자와 시스템을 연결하는 것이 UI라면 인터랙션은 UI를 통해 시스템을 사용하는 일련의 상호 작용을 의미

즉, 마우스로 화면의 어떤 아이콘을 클릭하면 화면이 그에 맞게 반응하는 것

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

1. UML(Umified Modeling Language)의 개요

UML은 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향모델링 언어이다.

즉, 많은 사람들이 모여 작업을 수행하다 보면 같은 대상물을 보고도 서로 다르게 표현하여 의사소통에 문제가 생기는 경우가 있습니다. 이런 문제를 해결하기 좋은 방법은 공통된 표현법(UML 도구)를 만드는 것입니다.

• UML은 Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합하였으며, 객체 기술에 관한 국제표준화기구인 OMG(Objecgt Management Group)에서 표준으로 지정하였습니다.

• UML을 이용하여 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램을 작성할 수 있다.

• 각각의 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현한다.

• UML의 구성요소에는 사물, 관계, 다이어그램 등이 있다.

2. 사물(Things)

모델을 구성하는 가장 중요한 기본 요소, 다이어그램 안에서 관계가 형설될 수 있는 대상들을 말한다.

- 사물에는 구조 사물, 행동 사물, 그룹 사물, 주해 사물이 있다.

3. 관계(Relationships)

사물과 사물 사이의 연관성을 표현하는 것

연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계 등이 있다.

연관(Association) 관계

연관 관계는 2개 이상의 사물이 서로 관련되어 있음을 표현한다.

• 사물 사이를 실선으로 연결하여 표현, 방향성은 화살표

• 서로에게 영향을 주는 양방향  관계의 경우 화살표를 생략하고 실선으로만 연결한다.

• 연관에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기한다.

집합(Aggregation) 관계

하나의 사물이 다른 사물에 포함되어 있는 관계를 표현한다.

• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적

• 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현한다

포함(Composition) 관계

집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현한다.

• 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립될 수 없고 생명주기를 함께한다.

• 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현한다.

일반화(Generalization) 관계

하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다.

• 예를 들어 사람은 여자와 남자보다 일반적인 개념이고 반대로 여자와 남자는 사람보다 구체적인 개념이다.

• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)라고 부른다.

• 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현한다.

의존(Dependency)관계

연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현한다.

• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계이다.

• 영향을 주는 사물(이용자)이 여향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현한다.

실체화(Realization) 관계

사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서소를 그룹화 할 수 있는 관계를 표현한다.

• 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다.

4. 다이어그램(Diagram)

사물과 관계를 도형으로 표현한 것이다.

• 여러 관점에서 시스템을 가시화한 뷰(View)를 제공함으로 써 의사소통에 도움을 준다.

• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용한다.

• 구조적(Structural) 다이어그램의 종류

• 행위(Behavioral)다이어그램의 종류

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

1. XP(eXtreme Programming)

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.

• XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.

• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높이다.

• 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인할 수 있다.

• 비교적 소규모 인원의 개발 프로젝트에 효과적이다.

• XP의 5가지 핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

2. XP 개발 프로세스

사용자 스토리(User Story)

- 고객의 요구사항을 간단한 시나리오로 표현한 것이다.

- 내용은 기능 단위로 구성하며, 필요한 경우 간단한 테스트 사항도 기재한다.

릴리즈 계획 수립(Release Planning)

- 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 한다.

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

스파이크(Splike)

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

- 처리할 문제 외의 다른 조건은 모두 무시하고 작성한다.

이터레이션(Iteration)

- 하나의 릴리즈를 더 세분화 한 단위를 이터레이션(Iteration)이라고 한다.

- 일반적으로 1~3주 정도의 기간으로 진행된다.

- 이 기간 중에 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수 있다.

승인검사(Acceptance Test, 인수 테스트)

- 계획된 릴리즈 단위의 부분 완료 제품이 구현되며 수행하는 테스트이다.

- 사용자스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행한다.

- 테스트 이후 새로운 요구사항이 작성되거나 요구사항의 상대적 우선순위가 변경될 수 있다.

- 테스트가 완료되면 다음 이터레이션을 진행한다.

소규모 릴리즈(Small Release)

- 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응할 수 있다.

- 이터레ㅔ이션이 모두 완료되면 고객에 의한 최종 테스트를 수행한 후 릴리즈, 즉 최종결과물을 고객에게 전달한다.

- 릴리즈가 최종 완제품이 아닌 경우 다음 릴리즈 일정에 맞게 개발을 계속 진행한다.

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

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)

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

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

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