[구글/페이스북] 계정연동 Tip

클라이언트에 구글과 페이스북 계정연동을 할 땐 구글 로그인 버튼/ 페이스북 로그인 버튼/ 각각 사이트에서 제공하는 이미지와 규격대로 적용해야 합니다.

 

페이스북 로그인 버튼 ——————————–

https://developers.facebook.com/docs/facebook-login/web/login-button

 

구글 로그인 버튼 ——————————–

https://developers.google.com/identity/sign-in/web/build-button

[버전관리] Base

버전 관리(version control, revision control) 란?

동일한 정보에 대한 여러 버전을 관리하는 것을 말한다. 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는데 사용된다. 그러한 문서의 변경 사항들에 숫자나 문자로 이뤄진 (“개정판 번호”나 “개정판 레벨”이라고도 불리는) “버전”을 부여해서 구분한다. “버전”을 통해서 시간적으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다. 간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항이 발생 시마다 버전 번호를 1씩 증가시킨다.

소프트웨어 엔지니어링에서는 일반적인 소프트웨어 소스 코드만을 관리하는 내역을 주로 버전 관리라고 정의하게 된다. 일반적으로 산업 공학이나 이전 생산 기반 제조 공학 등에서 소프트웨어 쪽으로 넘어오는 학문적 관심에 의해 이전 생산 공학에서 사용하던 개념을 가져오게 되었고, 그에따라 버전 관리(Software Version Management)와 형상 관리(Software Configuration Management)의 개념들이 따라왔다고 볼 수 있겠다.

한국의 경우, 대부분의 서적들이 일본어를 거쳐 중역(重譯)되면서 오역된 경우가 많고 관련된 분야에 대해 정확하거나 깊은 이해 없이 단순 소개하며 넘어간 경우가 대부분이라 아직도 정확한 버전 관리와 형상 관리의 구분이나 이해가 없다고 보는 것이 맞다.

버전 관리 소프트웨어 도구들은 거의 모든 소프트웨어 개발 프로젝트에서 필수적인 요소로 인식되고 있다.

[출처 : 위키백과]

 

빌드관리는 정해진 형식이 없다. 작업자와 해당 버전에 대한 규정을 정해놓고 진행하면 된다.

간단한 예를 들자면 작업용 빌드의 g0.001.0721.03라는 버전이 존재

g0 : google 빌드한 0번째 버전 [대규모 업데이트 등]

001: 등록한 횟수

0721: 날짜

0.3: 세번째로 빌드한 버전

 

배포용 빌드의 버전은 작업용빌드와 순서만 맞춰주면 된다.

[Milestone] Alpha Build

※ 마일스톤(milestone)이란 프로젝트 진행 과정에서 특기할 만한 사건이나 이정표를 말한다. 예를 들어, 프로젝트 계약, 착수, 인력투입, 선금 수령, 중간보고, 감리, 종료, 잔금 수령 등 프로젝트 성공을 위해 반드시 거쳐야 하는 중요한 지점을 말한다.

※ Alpha란 소프트웨어 테스트를 시작하는 첫 번째 단계.

Alpha 소프트웨어는 불안정해질 수 있으며 충돌 또는 데이터 손실을 초래할 수 있습니다. Alpha 소프트웨어에는 최종 버전을 위해 계획된 모든 기능이 포함되어 있지 않을 수도 있습니다. [2] 일반적으로 오픈 소스 소프트웨어는 종종 공개적으로 사용 가능한 알파 버전을 가지고있는 반면, 독점 소프트웨어 에서는 알파 소프트웨어의 외부 가용성이 드문 경우가 있습니다. 알파 단계는 일반적으로 기능 고정 으로 끝나며 더 이상 기능이 소프트웨어에 추가되지 않음을 나타냅니다.

마일스톤 알파버전 체크리스트

  1. 구현하기로 했던 작업에 관한 기능적 완료여부 (TC)https://wordpress.com/posts/my/ftredblog.wordpress.com 참고
  2. 목표기능(콘텐츠) 적용(정상) 여부
  3. 탐색적 test
  4. 네트워크 test

※ 네트워크가 필요한 컨텐츠라면 갑자기 끊어졌을 때와 같이 네트워크상에서 일어날 수 있는 상황을 시나리오화 해서 몇가지 케이스를 테스트 하는 행동입니다.

QA 항목 설정 요령

품질 보증 ( QA )은 제조 된 제품의 실수 나 결함을 예방하고 고객에게 솔루션이나 서비스를 제공 할 때 문제를 피하는 방법입니다.

개발을 하다 보면 QA를 진행해야 하는 상황이 필수적으로 나타납니다.

그중에 탐색적으로 정해진 행동이 아닌 돌발행동을 했을 때 나타나는 현상들을 문서화 시키기 위해 지극히 주관적인 관점으로 설정한 항목을 정리한 문서입니다.

—————————————————————————————————————————————–

※ Client  : 만약 테스트 해야하는 클라이언트의 종류가 있다면 구분하기 위한 항목

※ Type : 발견하거나 발생한 현상이 버그인지, 이슈사항인지, 개선사항인지 등을 구분하기 위한 항목

※ Improvment : 해당 현상의 작업처리 우선순위를 선정하기 위한 항목

ㄴ 긴급 : 처리가 되지 않으면 진행되지 않는 수준의 현상

ㄴ 중요 : 구현방향에 따라 정상적으로 구현되지 않은 수준의 현상

ㄴ 일반 : 구현되지 않은 기능이 게임진행에 큰 영향을 미치지 않지만 작업이 안된 부분

※ 발생빈도 : 10회플레이 등 기준을 설정하고, 해당 현상의 발생빈도를 체크할 수 있는 항목

※ 발생조건 : 해당현상을 일으키기 위한 사전 행동들을 정리하는 항목

※ 개발 방향 : 해당현상을 구현하기로 했던 원래의 방향을 명시하는 항목

※ 개선방향 및 조치 : 해당현상에 관한 조치 및 개선방향을 제시하는 항목

※ 담당자 : 해당현상을 발견하거나 개선을 요청하는 담당자를 명시하는 항목(적어놔야 개발담당자가 궁금한 사항들을 물어보고 빨리 이해할 수 있음)

※ 처리상태 : 해당현상에 관한 상태

ㄴNew : 새로 등장한 상태

ㄴDoing : 버그수정 및 개선을 진행중인 상태

ㄴ Done : 버그수정 및 개선을 완료 한 상태

ㄴ Pending : 해당 현상의 구현이 어렵거나 개발방향에 의해 보류한 상태

※ 개발 담당자 : 수정 및 개선 담당자의  코멘트를 적을 수 있는 항목


 

위 항목들은 개발사나 개발구성원에 따라 달라질 수 있습니다.

게임 제안서 작성요령

제안서?

아이디어를 문서화 하여 왜 해야하고 어떤 것을 노려서 무엇을 어떻게 얻을 것인가를 대상에게 제안하기 위한 문서.

 

게임 제안서?

게임에 관한 아이디어를 표현하고 게임의 목적 및 효과를 전달하기 위한 문서

 

※ 제안서를 읽게되는 독자를 이해시킬 수만 있다면 충분한 문서입니다.
※ 정석이 없는 문서이지만 제가 습득한 요령 몇가지를 정리해 보겠습니다.

 

1. 제안서의 가장 중요한 요소인 목적에 집중 하는 글 (제목부터 목표가 명확하게 드러나면 집중도가 높아짐)
ㄴ 어떤물건을 만들어서 돈을 벌겠다와 약간의 시장, 타겟이 들어가는게 좋음
ㄴ 제목에서 명확한 목표가 설정된다면 일단 관심끌기 성공
ex>[온라인 상에서 혼자 플레이할 수 있는 경영시뮬레이션게임 개발 및 상용화]

2. 기승전결로 구성(목적에 대한 배경 >> 목적을 담은 제품 >> 판매전략 >> 목적 달성의 기준)
ㄴ단,추상적인 전개는 피하는게 좋음

3. 이유가 포함된 제안요소는 더욱 풍부함

4. 최대한 간단하게 작성 (짧고 명확한 용어, 확실한 방향과 표현)

5. 도표, 플로우차트, 스크린샷, 다이어그램, 예제로 시각적 효과를 극대화 많을수록 효과적

6. 읽는자를 고려한 서식의 배치

7. 질의를 시뮬레이션 하며 관련 된 응답용 페이지를 만들어 보기
ㄴ 무조건 쓰이지는 않지만, 이런 내용이었죠? 하며 답하는 것이 훨씬 심적으로 안정된 방법

Game QA 진행요령

Game QA ?

QA : 품질 보증을 뜻하는 Quality Assurance의 약어

게임 QA : 게임(클라이언트)의 품질보증을 뜻하는 언어

통상 만들어진 게임의 기능이 잘 돌아가는지, 예외처리에 대한 버그발생은 없는지 등에 관한 레포팅을 작성하는 작업

 

게임에서는 탐구적QA와 기술적 QA로 나뉨

 

탐구적 QA?

  1.  예상되는 유저의 행동을 미리 실행해 보는 QA
  2.  예상해보지 못하도록 돌발행동을 실행해 보는 QA

★  이런 저런 행동을 하거나 클라이언트를 탐험하며 만들어진 클라이언트를 고찰하는 QA

 

기술적 QA TC(test case) List

  1. 만들어진 클라이언트가 계획대로 개발되었는지 확인하는 QA

★ 정상적인 실행에 맞춰 해당 기능이 정상적으로 개발되었는지 확인하는 QA

해당 클라이언트의 TC(test case)를 만들어 작성하는 편이 빠짐없이 체크해 볼 수 있는 좋은 예

 

 

※ QA는 품질보증인 만큼 사용자의 환경도 고려하며 진행하면 더욱 버그나 예외처리에 관한 부분을 확실히 집어낼 수 있습니다.

웹용으로 개발한다면 웹을 구동시킬 수 있는 브라우저의 종류를 고려한다거나 모바일용으로 개발한다면 스마트폰제조사or 스마트폰 종류 or 패드지원 등을 고려한다거나 하는 사용환경을 고려한다면 보다 확실한 QA가 될것입니다.

검색엔진최적화 (SEO)

검색엔진최적화-SEO1

사이트를 세상에 알리는 방법으로 가장 첫번째이자 매우 중요한 것이 바로 검색엔진최적화(Search Engine Optimization).

테스트용 HTML5 퍼블리싱 사이트를 오픈하면서 SEO 셋팅이 제공되길래, 관련 공부가 필요할 듯하여 구글에서 제공하는 기본가이드를 공유.

search-engine-optimization-starter-guide-ko

검색엔진이라 함은 결국 구글을 말하는 것이고, 웹에서 진행하는 모든 서비스에는 기본적으로 필요한 부분이라 생각됨.

다음의 사이트에서도 쉽게 파악해 볼 수 있다.

검색엔진최적화(SEO)쉬운 가이드