BIcOding

**소프트웨어 개발 단계 >기획 단계 1. RFP(Request For Proposal) : 제안 요청 2. 프로젝트 계약 완료 3. SRS(Software requirements specification) : 프로젝트 큰 그림 설계 >분석 단계 : 사용자 요구사항 정의서 : 유스 케이스 명세서, 요구사항 추적표 >설계 단계 : 화면 정의서 : 테이블 설계서 : API 명세서 >구현 단계 **사용자 요구사항 정의서 >정의 : 고객의 요청 사항을 기반으로 SRS의 협의 내용을 적용하고 실제 개발에 적용할 수 있는 수준으로 요구사항을 재정의 한 것. : 표 형태로 시각화 : 기능적 요구사항과 비기능적 요구사항을 나누어 작성 //기능적 요구사항 : 실제 애플리케이션 동작을 수행하는 작업 //비기능적 요구사항 ..

**SRS >SRS 정의 : Software requirements specification : 프로그램 종합 설계도 >SRS Template 1. 소개 1.1 목적(Purpose) // 해당 애플리케이션 혹은 설명하고자 하는 부분의 시스템을 안내 1.2 문서 규칙 (Document Convention) // 텍스트, 주석 등 문서의 모든 표기 규칙을 안내 1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion) 1.4 프로젝트 범위 (Project Scope) 1.5 참조 (Reference) 2. 전체 설명 (Overall Description) 2.1 제품조망 (Product Perspective) 2.2 제품 기능 (Project Feature) 2.3..

**git flow >Git flow : 대규모 프로젝트에 적용하기 적합 //링크 //따로 추가로 정리할 예정이지만, 아래 링크가 아주 기똥차기 때문에 우선은 참고할 것. https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5 >merge -rebase and merge : 이건 커밋 기록이 다 남음 -squash and merge : 커밋 기록이 안남고 깔끔하게 다 합쳐지는?느낌 //링크 인텔리제이 깃 다루기 https://ddoriya.tistory.com/entry/Intellij-Git-%EC%82%AC%EC%9A..

**프로젝트 과정 >1. Github repo에 필요한 파일 -README.md : Markdown 양식의 파일 : 프로젝트 이름, 프로젝트 핵심 기능 소개, 팀원 소개와 같은 해당 Github repo의 안내서와 같은 역할을 함. -.gitignore : 말 그대로 git이 관리하지 않도록 무시하는 파일의 목록을 설정하는 파일 : 해당 파일에 설정된 파일 혹은 디렉토리 경로는 local repo에서 git으로 관리되지 않으며, push를 해도 github repo에 push되지 않는다. -LICENSE : 해당 코드의 라이센스를 표기 : 해당 코드를 public으로 공개할 경우에도 저작권은 존재하기 때문에 이를 라이센스로 표기하는 것임. : 오픈 소스 사용 및 배포 시, 지켜야할 규칙, 이용 방법, 조..

**팀 프로그래밍 >목적 -효율성 향상 -창의성 향상 -강력한 혁신 >성공적인 프로젝트 -Hard Skill : 사용한 개발 스택들이 현업에서 사용할 만한지 : 취업 시 경쟁력이 될 만한 가치가 있는지 : 매일 팀과 개인의 실패 혹은 성공 로그를 남겼는지 -Soft Skill : 프로젝트 도중 동료를 신뢰했는지 : 실패 혹은 성공 경험에서 무엇을 느꼈는지 : 프로젝트 중 본인이 충분한 노력을 했는지 >Soft Skill Details : 내가 먼저 신뢰할 수 있는 동료가 되자 : 경험에서 얻은 교훈을 발판삼아야 한다. 꼭 기록해라 : 노력을 해보고, 안해보고의 차이는 크다. 해봐라 **커뮤니케이션 >서로의 차이(존재) 인정 : 본인이 팀에 피해를 주려는 사람은 없다. : 모두 도움이 되려하지만 기여하려는..