일반적으로 소프트웨어 개발 시 필요한 문서나 소스 관리 등에 대해 정리. 주로 소프트웨어 엔지니어링에 관한 내용이다.

FTP 서버 or NAS or 클라우드
회사 자료는 공개된 타사의 클라우드가 아닌 사내 파일 서버에 저장되는 것을 추천한다.

일관된 문서 작성을 위해 정해진 양식이 문서 종류마다 존재해야 한다.

누구나 열람하기 쉽고 편집하기 쉬워야 한다. 편집된 히스토리도 관리되는 것이 좋다.
위키를 사용하는 것을 추천하나 구성원 다수가 편집하기를 꺼려한다면 웹페이지를 사용한다.

특정 제품에만 적용되는 문서는 제품별로 문서 관리를 한다.
주요 내용으로는 매뉴얼, 개발 히스토리, 개발 내용, 개발 환경 등이 될 수 있을 것 같다.

그 외 관리되어야 할 문서들은 다음과 같다.

• 사내 개발 환경 관리
• 사내 서버 관리
• 사내 물품 관리
• 고객 관리
• 외주 관리
• 구매 관리
• 기타 등등

사내 문서는 반드시 주기적으로 백업한다. 또한 보안에 신경 쓴다.

여러 명이서 코드 작업을 할 때 서로의 코드를 이해하기 쉽도록 약속을 정해 놓는 것이다.
예를 들면 클래스명 앞에 대문자 C를 붙여라, 멤버 변수명 앞에 m을 붙여라 등이다.

UI 구성 방법에 대한 내용이다.
회사의 소프트웨어를 일관된 스타일로 만들기 위한 문서이다.
작은 회사의 소프트웨어엔 크게 중요하지 않는 것 같다.
Apple 이나 Microsoft 사의 UI 가이드라인을 참고한다.

줄여서 SRS or FRS라 한다.
소프트웨어의 스펙을 세세하게 정하기 위한 문서로 소프트웨어 개발 초기에 대단히 중요하다.
스펙이 바뀌면 코드 설계도 달라지므로 여러 번 생각하고 논의하도록 한다.

어떤 데이터가 필요한지 정리해둔 문서.

말그대로 클래스 관계도를 그린 그림.
코드를 설계할 때 메인이 되는 그림이다.
디자인 패턴을 많이 알아두면 좋다.

Function이 실행되는 과정을 그린 그림.

사용자가 프로그램 기능을 실행할 때 그 과정을 보여주는 그림.

소프트웨어 개발 일정을 한눈에 보기 위한 표 또는 그림.
엑셀로도 만들 수 있지만 마이크로소프트 프로젝트를 이용하면 더 쉽게 그릴 수 있다.
프로젝트 관리 툴에서도 대부분 지원한다.

소프트웨어 테스트를 위한 문서.
소프트웨어 기능 리스트를 나열하고 해당 기능이 잘 수행되는지 버그가 존재하는지 기록한다.
각 테스트 단계마다 문서가 업데이트 되어야 하고 해당 버그도 수정되어야 다음 테스트가 가능하다.

소프트웨어가 완성되었다면 매뉴얼은 필수.

반드시 소프트웨어의 버전 관리가 수시로 이루어져야 한다. 또한 언제든지 특정 날짜로 복구할 수 있어야 한다.
문서화는 따로 할 필요는 없을 것 같다. SVN 같은 툴에 간단히 메모 가능하니깐.
다만 고객에 의한 피드백은 문서로 기록되어야겠지?

소프트웨어의 UI나 코드 구조 등을 추상화하기 위한 툴.
코드 구조라 하면 앞서 언급한 Class Diagram, Sequency Diagram를 예로 들 수 있다.
UI 모델링을 위한 툴은 Pencil, Balsamiq 등이 있으며 코드 구조 모델링(or 설계) 툴은 StarUML 등이 있다.

코드 실행 전 코딩 에러, 메모리 릭 등의 문제를 해결하기 위한 툴.
Coverity(유료, 1억원대), cppcheck(무료) 등의 툴이 있다.

참고 : 코딩 스탠다드 점검 도구

코드에 특정 형식에 따라 주석을 달면 해당 내용을 문서로 만들어 주는 툴.
Doxygen이 대표적이다.

Mantis, Redmine 등

SVN or GIT or 기타

Trello(웹 기반), Jira 등

기타 자세한 내용은 Code Complete나 소프트웨어 공학 관련 서적을 참고한다.