Webベースのアプリケーションでのエンドツーエンドのソフトウェア開発サイクル？

Question

私たちは、適切な文書化を通じてソフトウェア開発プロセスをさらに改善する方法を模索しています。しかし、ドキュメントであるため、これらのドキュメント/仕様は、オープンして読むたびにのみ利用可能です。

たとえば、URS、SRS、ERD、DBダイアグラム、クラス図、ユースケース、テストスクリプト、ユーザーマニュアルおよびトレーニング資料は、通常は別個のドキュメントです。

これは誰でも1つのWebベースシステム内で実行していますか？

システムのすべての要件をキー入力することから始まり、簡単にURSを生成することができます。要件が変更された場合は、システムに入力する必要がありますが、簡単に生成することができます。

最も重要な部分は、トレーサビリティです。そこでは、要件が最後までどのように実装されているかがわかります。時には、彼らはURSにありますが、手作業で比較/検査するのは難しいため、途中で欠落しています。非常に頻繁に別の人が別々のプロセスを行っているので、事故が誤って省略されることがありますたとえば、システムおよびテストスクリプトには機能が存在する可能性がありますが、ユーザマニュアルには存在しません。

私は完全に実装されていないプロセスのどの部分でも変更を想像しています。したがって、アクションをとることができます。

ありがとうございます！

Answer 1

Rational/IBMのRequisite Proを見てきましたが、私たちの会社は要件管理スイートを探すプロセスを経て、最終的に選択されました。最終的には、すべての文書にWikiを使用し、すべてのフィーチャを番号付けしたマスタースプレッドシートと、その機能をバグカウントに照らし合わせて焼き付けるアクセスDBを実装しました。かなり手作業ですが、プロジェクトマネージャー誰が何らかのコーディング経験を持っていた。

Answer 2

Sphinxを使用します。

ドキュメントは、コードとともにリポジトリにあります。

ドキュメントには、Sphinx .. addmoduleコマンドによるコードリファレンスが含まれています。

Answer 3

XPlannerを使用します。主にXtreme Programmingの反復を対象としていますが、要件計画ツールとしても使用しています。フリーフォームの注釈を、単にwikiページ（添付ファイルに加えて）である「記事」（= XPの機能）に追加することができます。時間を見積もり、タスクなどを作成することもできます。

または、単にwikiを使用できます。その中にはたくさんのものがあります。とにかく特定のワークフローをしっかりと実行していないことが多いため、特定のワークフローを提供/強制するものに対してwikiのような「自由形式」を好むでしょう。 （それが良いか悪いかは別の問題です...）

Answer 4

アジャイル方法論では、CollabNetのTeamForgeが役に立ちます。 URL：http://www.collab.net/downloads/ctf/

TeamforgeはバックボーンとしてSVN上に構築されており、アジャイルプロジェクトで探している多くの機能を備えています。

Answer 5

文書化のために多くのWikiシステム（通常はトラッカーで収集）のいずれかを使用することをお勧めします。良い例は、Trac、Redmine、（商業）FogBugz、Jiraです。

あなたは、このように

• 簡単に情報の流れを可能にチケットからのWiki参照することができます。スペック - >実装チーム
• 検索機能
• 文書のバージョン管理
• ...

をこれらのソリューションオンライン、特別なローカルソフトウェアなし必要です。

関連するチケットID参照で、仕様の明確化と変更要求を追跡できます。後でを確認するのが簡単ですなぜいくつかの変更が導入されました。