기본적으로 PHP로 개발되었으며 또 다른 일반 웹 응용 프로그램 인 웹 응용 프로그램을 완성했습니다. 일반적으로 최종 프로덕션 릴리스를 제공 할 때 코드 문서와 아키텍처 정보를 클라이언트에게 전달합니다. 그러나이 특정 프로젝트의 경우 고객은 프로젝트에 대한 완전한 인 / 아웃 데이터를 보유해야합니다.

그래서 궁금합니다. 코드 및 아키텍처 문서와 별도로 고객에게 제공 할 수있는 필수 기술 문서와 비 기술 문서는 무엇입니까?

(또한 프로젝트에 대한 다양한 통계 및 데이터에 대해 고객을 공격하면 실제로 관련된 작업의 양과 제품이 실제로 얼마나 멋진 지 알 수 있습니다.)

목록에 다음이 포함되어야한다고 생각합니다.

• 비 기술적 요구 사항 (이러한 문서가 있었습니까?)
• 기술 요구 사항
• 일부 결정이 다른 결정에 대해 작성된 이유를 설명하는 "결정"문서 (있는 경우). 이미 다른 요구 사항 또는 아키텍처 문서에있을 수도 있지만 일반적으로 큰 결정을 위해 별도로 수행합니다.
• 코드 및 기타 리소스 (이미지 파일, CSS 등)
• 데이터베이스 모델 (다이어그램, 문서 등)
• 데이터베이스를 작성하는 DDL
• 데이터베이스를 시드 할 DML
• 응용 프로그램 설정 및 기본 문제 해결을 설명하는 문서입니다.
• 중요한 사용자 이름 및 비밀번호 목록 (관리자 계정)과 비밀번호 변경 방법에 대한 지침. 이상적으로는 처음으로 웹 사이트를 설정할 때 새 관리자 암호를 입력하라는 메시지가 표시되지만 이는 아키텍처에 관한 것입니다.
• 시스템 요구 사항 및 웹 앱의 경우 최소 호스팅 요구 사항 (앱에 MySQL 또는 PostgreSQL이 필요합니까? RAM 용량은 얼마입니까? 등)

이 모든 것들이 모든 프로젝트에 이용 가능하거나 필요한 것은 아니지만, 이것이 좋은 일반 안내서라고 생각합니다.

FrustratedWithFormsDesigner의 정말 좋은 대답 외에도 비 기술 문서에 포함 된 내용에 대해 말하고 싶습니다.

• 분석 데이터 : 요구 사항에 대해 처음 이야기했을 때 고객이 무엇을 말했습니까?

• 당신이 만든 제안 :

  • 제품 요구 사항 문서
  • 기능 사양서

  이는
  개발 시간 동안 예상 시간과 비용뿐만 아니라 고객 이해야 할 일과 고객이 무엇 을 제공 할 것인지에 대한 일종의 계약 역할을합니다 .

• 검토 프로토콜, 사용 사례 및 테스트 계획, 테스트 결과를 포함한 사양

• UML의 디자인 및 모든 해당 문서

• 소스 코드 문서 (산소 또는 기타)

• 매뉴얼 및 설치 지침

• 프로젝트에 사용 된 최종 실제 자원량 (시간 및 비용)으로 송장을 작성할 수 있습니다.

• 일부 고객은 회의 프로토콜도 원합니다.이 프로토콜은 위에서 언급 한 "결정 문서"의 확장입니다.

그것이 당신이 찾고있는 희망입니다.

다음 중 프로젝트에 적용 할 수있는 문서를 따르십시오. 이미 일부 문서가있을 수 있습니다.

기술 문서:

• PHP에 대한 세부 사항 및 프로젝트에 유용한 방법에 대한 정보
• 백엔드에 대한 세부 사항 및 프로젝트에 유용한 방법에 대한 정보
• 데이터 흐름을 나타내는 적절한 그림과 함께 데이터베이스 연결에 대한 정보
• XML, HTML 등과 같은 프로젝트에 관련된 다른 프로그래밍 언어 또는 응용 프로그램에 대한 정보
• FAQ 도움말 파일

스크린 샷이 포함 된 문서를 준비하고 다음에 대한 관련 코드 (필요한 경우)를 강조 표시하십시오.

• 개체 또는 컨트롤, 개체 속성 등과 같은 프런트 엔드 응용 프로그램에 대한 정보
• 데이터베이스 쿼리에 대한 정보 (아직없는 경우)
• 기본 키, 외래 키 등과 같은 데이터베이스 속성에 대한 정보와 데이터 일관성 및 정확성을 보장하는 방법
• 유사한 종류의 데이터 또는 화면을 논리적 순서로 반복하지 않고 샘플 데이터로 실행 한 후 프런트 엔드와 백 엔드를 모두 사용하여 가능한 모든 종류의 스크린의 스크린 샷을 사용하여 프로젝트 전체에 대한 자세한 가이드.

• 유효하지 않은 데이터를 입력하고 프런트 엔드 및 백엔드에서 데이터 유효성 검사를 수행 했으므로 불가능한 것으로 표시합니다.
  /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

• 관련 코드를 설명하여 서버 나 클라이언트 시스템에 갑자기 오류가 발생하면 프로그램에 오류가 없거나 데이터에 불일치가 없음을 보여주십시오.

• 프런트 엔드를 통해 샘플 데이터를 제공 한 후에는 서버에서 데이터를 직접 검색 할 수 있도록 샘플 쿼리를 백엔드에 포함하고 데이터의 중요한 통계를 준비하는 데 도움이되는 샘플 DML 쿼리도 포함 할 수 있습니다.

고객이 샘플 데이터로 데모를 요청하는 경우 프로젝트가 실제로 어떻게 작동하는지 보여줄 수 있도록 문서화하기 전에이를 직접 확인해야합니다. 또한 프런트 엔드 코드에 적절한 주석 행이 있는지 확인하십시오.

• 마지막으로 총 코드 줄 수, 프로젝트에 소요 된 총 일수, 프로젝트를 확인한 총 횟수, 사용 된 모든 응용 프로그램 목록 및 기타 기술 및 비 기술 정보와 같은 통계로 결론을 내립니다.

  
  비 기술 문서 :

• 해당되는 경우 프로젝트의 라이센스 세부 사항.
• 해당되는 경우 프로젝트의 상업적 측면.

조심하세요

클라이언트에게 줄 수 있는 잠재적 인 문서 는 사실상 끝이 없습니다. 아직 가지고 있지 않은 문서를 생성하는 데 필요한 추가 시간은 무료입니다.

클라이언트가 왜이 문서를 원하십니까 (소스 코드 이상)? 그것으로 무엇을 할 것인가? 누구를위한 것인가?

이러한 질문에 대한 답변은 무엇을 제공 할 것인지를 좁히는 데 도움이됩니다.

제공 할 문서와 추가 노력의 보상 여부에 대해 귀하와 고객이 동의하는 것이 중요합니다.

추측 게임을하지 마십시오. 대부분의 기술 문서는 일반적인 (기술이 아닌) 클라이언트에게는 쓸모가 없습니다.

아마 이것을 몇 가지 문서 범주로 나눕니다.

가이드 :

• 설치 안내서, 서버에서이를 설정하는 방법
• 최적의 성능을 위해 응용 프로그램을 구성하고 실행하는 방법에 대한 관리자 안내서. 보안은이 응용 프로그램이 가지고 있고 실행하는 데 사용하는 암호를 알 수 있도록 여기에서 다루는 것입니다.

지원하다:

• 문제가있는 경우 어떤 종류의 절차를 제안 하시겠습니까? 일정 기간 동안 지원을 제공하고 있습니까? 아마도이 분야에서 여전히 가이드를 하나 또는 두 개 줄 것이므로 다른 사람이 서비스를 다시 시작하거나 서버를 재부팅하는 등의 쉬운 일을 알 수 있습니다.

통합 포인트 :

• 이 응용 프로그램에 코드 이외의 다른 공급 업체를 사용하도록하는 타사 통합 지점이 있습니까?