1

次のシナリオで何を提案しますか。

複雑なシステムを構築および設計するには、多数の開発者が必要です。この設計は、将来の開発者のために文書化する必要があり、設計上の決定に注意する必要があります。これらのレポートは、約 2 か月ごとに作成する必要があります。私の質問は、このプロジェクトをどのように文書化するかです。

2つの可能性が見えます。各開発者は、設計と統合に役立ったことについて書き、1 人がこれらのドキュメントを 1 つにまとめます。すべてを組み立てる任務を負っている担当者は、すべての部品を調整する時間があまりないため、最終的なドキュメントはおそらく一貫性がなかったり、冗長になったりすることがあります。

各開発者からのドキュメント パーツが締め切りの数日前に届くとします。締め切りの数日前まで読むものがないため、共同システム (つまり wiki) は適切に機能しません。

それとも、チームの残りのメンバーが実際のシステム開発に取り組んでいる間に、少数の人 (2 ~ 3 人) がドキュメントの作成を担当する必要がありますか? 開発者は、設計上の選択と結論をテクニカル ライターに伝える方法が必要です。これを効率的に行うにはどうすればよいでしょうか。

4

5 に答える 5

1

RUPスタイルのアプローチを使用して、2つの側面からこれにアプローチします。最初のケースでは、提供するものの設計を大まかに説明する責任を負うドメインエキスパートがいて、必要に応じて開発者が参加します。2番目のケースでは、テクニカルライターを使用します。彼らはアプリケーションを文書化するので、アプリケーションがどのように連携するかをよく理解している必要があり、設計と開発のプロセス全体に関与します。この場合、彼らはデザインを磨き、それが彼らが開発されていると思っていたものと一致することを確認するのを助けることができます。

于 2008-12-13T21:09:21.967 に答える
1

代替案 2 は、プロジェクトの新しい段階を意味するため、アジャイル性が低いと思います (ただし、テストと並行している可能性があります)。

アジャイル モデルの場合は、ドキュメントを (ガイドラインに従って) ストーリーとして追加するだけです。
段階的なアプローチをしている場合でも、開発者には、いくつかのガイドラインに従ってドキュメントに取り組み、設計とコードに沿ってそのドキュメントを確認するように依頼します。最終的には、テクニカル ライターが適切な英語ですべてをレビューするようになるかもしれませんが、それは一種の「リリース」作業になります。

于 2008-12-13T21:05:32.193 に答える
1

合流点 (アトラシアンの wiki のようなもの) を使用し、あらゆる種類のさまざまな「もの」を文書化します。開発者は継続的にそれを行っており、私たちはお互いにドキュメントを求めています。必要なものは仲間の圧力に任せています。新しい人がやってくるたびに、彼/彼女はすべてを読んで、まだ正しいものを見つけることを任されています. この結果として、誤った内容が削除または更新されます。削除できると嬉しいです ;)

このプロセスの良いところは、関連するものは残され、無関係なものは削除されることです。私たちは、「彼ら」が必要とする場合、彼らが望む単語文書をいつでも作成できると主張することで、より形式化された要求から常に「逃れました」。「彼ら」は決してそれらを必要としませんでした。

于 2008-12-13T21:01:45.103 に答える
0

Sand Castle を使用してプロジェクトを文書化できると思います。

見てみな

マイクロソフトのサンドキャッスル

于 2008-12-13T20:55:49.763 に答える
0

これは完全なドキュメントではありませんが、Doxygen スタイルのコメントを使用してインターフェースなどにコメントを付けるようにすることは、コードを書くこととそれをドキュメント化することをより緊密にすることを意味します。

そうすれば、開発者は何をするかを文書化する必要があります。アーキテクトによるレビューは、一貫した品質を保証するために必要だと思いますが、人々が行っていることを文書化することは、彼らがアーキテクチャに従っていることを保証するための最良の方法です.

于 2008-12-13T21:01:39.283 に答える