기타8 [소프트웨어 개발 방법론] 애자일 - 칸반(Kanban) 애자일 개발 방법론 중 하나인 칸반(Kanban)은 스크럼에 비해 훨씬 느슨한 방법론이다. 칸반은 본래 제조 생산 업무를 제한해서 효율을 높이고 재고를 줄이기 위해 만들어졌다. 이를 소프트웨어 개발에 적용할 때는 칸반 보드(Kanban board)에 초점을 맞춘다. 칸반 보드는 몇 개의 칼럼(Column)이 있는 간단한 보드로, 개발 프로세스가 진행되는 단계를 표현한다. 프로젝트에서 해야 하는 일을 시각화하고, 동시에 진행하는 업무의 양을 제한하는 것이 목적이다. 칸반도 스크럼과 마찬가지로 팀을 기반으로 하기에 시스템의 업무 흐름이 칸반 보드에 공개적으로 드러나면서 정형화, 시각화된다. 따라서 피드백을 통해 끊임없이 발전하는 것에 집중하게 한다. 칸반 진행 방식 칸반의 방식은 딱히 정해져 있지 않다. 그.. 2022. 2. 5. [소프트웨어 개발 방법론] 애자일 - 스크럼(Scrum) 애자일 개발 방법론 중 하나인 스크럼은 1990년대 초반에 만들어졌다. 스크럼은 소프트웨어 개발팀의 특정 역할, 소프트웨어를 개발하는 작업 흐름, 스프린트라고 부르는 회의를 특정 규범에 따라 정의한 방법론이다. 1. 스크럼 직책 스크럼에는 3개의 직책이 있다. 제품 책임자(Product Owner) : 소비자의 소리를 전달하고 작업의 우선순위를 결정한다. 개발팀 : 소프트웨어 배포와 관련된 모든 일을 맡는다. 스크럼 마스터(Scrum Master) : 팀이 하는 일을 지연시키는 방해물을 제거하고 스크럼이 문제없이 진행될 수 있게 돕는다. 2. 스크럼 진행 방식 스크럼은 기본적으로 작은 반복 주기로 나누는 '스프린트'로 소프트웨어 개발을 한다. 스프린트로 정해둔 기간 내에 해야 할 것들의 양을 정한다. 스.. 2022. 2. 5. [소프트웨어 개발 방법론] 애자일 - 개념 전통적인 소프트웨어 개발 방법인 폭포수 방법의 문제점을 보완하기 위해 애자일(agile)이 도입되었다. 애자일 원칙 소프트웨어 업계에 종사하던 17명의 사람들이 모여 애자일 선언문을 만든 것이 애자일의 시작이다. 애자일 선언문은 다음의 12가지 원칙을 기반으로 한다. 우리는 가치 있는 소프트웨어를 빠르게 그리고 지속적으로 제공해서 고객을 만족시키는 것을 가장 중요하게 생각한다. 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해서 고객의 경쟁력을 높이는 데 기여한다. 새로운 소프트웨어는 몇 주나 몇 달의 주기로 자주 제공하라. 간격은 짧을수록 좋다. 프로젝트가 진행되는 동안 사업부서 사람들과 개발자는 매일 만나서 함께 일해야 한다. 의욕 있는 사람들 위주로 팀을 구성하라. 그.. 2022. 1. 29. [소프트웨어 개발 방법론] 폭포수 개발 소프트웨어 개발 방법론은 소프트웨어를 만드는 절차를 정의한다. 이런 방법론들은 소프트웨어를 만드는 방법과 팀을 이끄는 방법을 알려준다. 폭포수(Waterfall) 개발이란 폭포수 개발은 가장 전통적인 개발 방법론이다. 이름 그대로 한 단계가 끝나면 다음 단계로 한 번에 한 단계씩 넘어가는 방식이다. 폭포수 개발 방법론에는 소프트웨어 개발 생명주기(SDLC)가 포함되어 있다. 소프트웨어 개발 생명주기(Software Development Life Cycle) SDLC는 다음의 과정을 포함한다. 요구사항 분석 : 개발할 소프트웨어에 필요한 요구사항을 모두 알아내는 단계이다. 무엇을 해야 하고, 어떤 기능이 있어야 하며, 어떻게 동작해야 하는지 등을 본격적으로 개발에 들어가기 전에 알아야 한다. 소프트웨어 디.. 2022. 1. 29. [OAuth 2.0] 4. API 호출과 Refresh Token 1. API 호출 액세스 토큰이 발급되었다면, 이제 액세스 토큰을 활용해서 Resource Server를 조작해야 한다. 이를 조작하기 위해선 Resource Server가 클라이언트들에게 " '어떤 방식'으로 하면 Resource Server를 사용할 수 있다 " 라고 알려주는데 이때 '어떤 방식'이 API(Application Programming Interface'이다. API의 데이터는 액세스 토큰을 통해서 가져올 수 있다. 2. Refresh Token 액세스 토큰은 수명이 있다. 수명이 끝나면 API에서 더 이상 데이터를 가져올 수 없기에 매번 액세스 토큰을 재발급해야 한다. 그러나 이는 비효율적이므로 refresh token을 사용해 수명이 다한 액세스 토큰을 자동으로 재발급받을 수 있다. .. 2022. 1. 23. [OAuth 2.0] 3. 액세스 토큰 발급 전 과정을 마치면, R.S는 authorization code를 통해서 이미 인증을 했으므로 authorization code 값을 지워버린다(다시 인증을 하지 않기 위해). 이제 R.S는 accessToken을 발급한다. R.S는 이 accessToken을 client에 응답해주고, client는 내부적으로 accessToken값을 저장한다. 위 그림으로 예를 들면, 이제 client는 해당 accessToken값(4)으로 접근하면, R.S가 user id가 1이고 accessToken값이 4인 사람에게 b, c 기능을 허용하고 동작하게 된다. 2022. 1. 19. 이전 1 2 다음
