1
私は保険会社に勤務しています。私たちは私たち自身の開発部門を約150人で構成し、いくつかのプロバイダ（アウトソーシングとカスタムアプリケーションはかなり作っている）を持っています。私たちのチームでは、私たちのチームは非機能ロジックライブラリと呼ばれるものを作ってきました。つまり、私たちの部門のすべての開発チームにとって水平なものを扱うためのソフトウェアライブラリです。セキュリティ、Webサービス、ロギング、メッセージングなど。ほとんどまたはこれらのツールは、デファクトスタンダードのスクラッチまたはアダプテーションから作成されます。たとえば、LoggerはLog4Jに基づくアペンダで、ログメッセージをDBに保存します。また、アプリケーションで使用するライブラリ（Webサービス用のフレームワークなど）も定義します。私たちは、すべての組織（いくつかのWebsphere Application Serverを使用）でJavaEEとOracle ASを使用しています。ソフトウェア環境ドキュメントチェックリスト
これらのプロジェクトの多くは、そのアーキテクチャが文書化されており（ユースケース、UML図など）、一般的に生成されたドキュメントが利用できます。 私たちが見てきたことは、ユーザーにとって、時々私たちが提供するライブラリを使用することが難しく、常に質問しているか、単にそれらを使用していないということです。
私たちはそれらのためのよりフレンドリーなドキュメントを生成することを計画していますので、私の質問は ですか？ソフトウェアドキュメントにはどのようなベストプラクティスまたはチェックリストが必要ですか？
何かが私の心に来る：
- APIリファレンスガイド
- クイックスタートチュートリアル
- API生成されたドキュメント。
- は、それが他に何を持っている必要がありWebアクセス