-
（メール、マイクロブログ、手紙、読んでブログなどによる）業界のソフトウェアチームとのインタビューでは、彼らのソフトウェア開発プロセスを頼みます
-
グループディスカッション、
-
チームのタイプは、あなたは、グループのお気に入りの2人のメンバーに投票します
-
あなたはこのコースを取るべきであるタイプで最も議論
-
長所と短所を一覧表示します
-
教室は話すやブログを公開します
-
ソフトウェア開発プロセス
まず、最初に、プロジェクト計画を策定自然の中でマイルストーンを予定。あなたは、ウォーターフォールモデルの設定を押すことができ、ニーズ評価のための主要なマイルストーン、デザインレビュー、ユニットテストコードの開発と統合テスト、展開後、オンラインシステムは試運転期間を入力するために使用することができたときに（とも呼ばれることができる期待される平均的なユーザーのために準備しますユーザーテスト段階）。
1人のニーズ分析
（1）利用者のニーズのシステムアナリスト予備的な理解に関連しており、関連するツールを開発するためのシステムの主要な機能モジュール、より具体的には、いくつかのインターフェースに対する要求に関連する主要な各機能モジュール、小さい機能モジュールをリスト良好な界面の少数で定義することができ、この予備的なステップです。
（2）システムアナリストの洞察と分析ニーズ、彼らの経験やニーズに基づいて、その後の文書WORDや関連ツールを使用してシステムの機能要件の文書を作ります。この文書は明らかに少し機能モジュールの一般的な機能モジュールは、機能モジュールが持っているものを設定し、また、関連インターフェースおよびインターフェース機能の一覧を示します。
（3）需要のシステムアナリストは、ユーザーにもう一度確認します。
（4）需要の書き方をプロジェクトメンバーがビジネスを理解するために、この段階では、需要をどう分析し、研究と書かれた表現をどのように実行するか、文書編集機能を記述した業務フロー図をだけでなく、要件の多くを持つことができるならば、非常に重要です。一般的には「ユーザー要件仕様」および「要求仕様」に分け、小規模なプロジェクトは、「ニーズ分析」、「ユーザーの要求仕様」を書くことができ、ユーザーを許可する、ユーザーの言語で記述し、開発チームは、共通の理解に達するために必要があります「要求仕様」は、機能を持っているユーザーニーズの分析、システムの形成では、ユーザーは設計やコード開発の後半に重要なベースラインである真の相互運用性を文書を、提供することができます。
デザインの2の概要
まず、開発者はソフトウェアシステム、そのシステム設計の予備設計を実施する必要があります。概要設計、詳細設計ソフトウェアを提供し、設計を扱う基本的なプロセスフローは、システムの組織構造、モジュール分割、機能割り当て、インターフェース設計、操作デザイン、データ構造設計およびエラーを含むシステムにおいて考慮ソフトウェアシステムを設計する必要があります基盤。システム環境、言語、ネットワークのハードウェア要件で実行されているの発展のユーザと組み合わせ、全体的なシステムアーキテクチャ、、、要件フェーズ分析を通じてユーザーを分類し、開発ツール、アプリケーションシステムアーキテクチャ設計の関係を決定描画する方法を説明ユーザおよびサブシステムまたはモジュールのそれぞれ、および他のシステムとの関係の全体図。これは、システムを把握するために、国境問題です。建築設計における設計の高レベルな概要に加えて、我々は、ネットワークトポロジ図、および配置図を設計する必要があります。概要より重要な設計上のサブシステムがありますが、合理的な部門をモジュール。モジュールの名前が大きく、ユーザのメインメニューになり、ユーザーの視点で明確なサブシステムとモジュールを取得する方法が非常に重要です。
3詳細設計
アウトライン設計に基づき、ソフトウェア開発者の詳細な設計は、体系的にする必要があります。詳細設計では、特定のアルゴリズムは、関与するメインモジュール、データ構造を達成する記載、及び、各プログラムのすべてのレベルでのソフトウェア・システムの説明（各モジュールまたはサブルーチン）設計上の考慮事項階層関係クラスを呼び出しますコーディングとテストのため。これは、ソフトウェアのニーズは完全にソフトウェアに割り当てられていることを確認する必要があります。詳細設計十分な詳細は、詳細な設計レポートに従って符号化することができます。
4符号化
ソフトウェアコーディング段階では、「ソフトウェア・システムの詳細な設計レポート」データ構造、アルゴリズム、分析設計要件に応じて、開発者、およびモジュールは、特定のプログラミング作業の開始の他の態様を実施、それぞれ、ターゲット・システムを実現するために、各モジュールの機能を達成するために機能、性能、インターフェイス、インターフェイスの要件の観点。標準化された開発プロセスでは、プロジェクト全体の符号化プロセスが1/2の最大値を超えない、典型的には1/3時間の、いわゆる準備作業を早めることができる、優れた設計プロセスが完了すると、符号化効率が非常になり多くの大幅な増加、異なるモジュール間のスケジュール調整とコラボレーションが、全体の進捗に影響を与える可能性がある小さなモジュールのおそらく問題をコーディングする際に、非常に多くのプログラマは動作を停止して待つことを余儀なく注意する必要がありますあり、問題R＆Dプロセスが登場しています。決済の相互通信、緊急手段コードは永遠に、プログラマのためのバグが非常に重要な場合、あなたはこの問題に直面する必要はありません。この段階は、一般的にダウン世代の開発、モジュールの合理的な分割と同様ウォーターフォールモデルを改善する必要がある、テスト段階のコード開発マスタープランは、複数の期間に分割され、各期間は、コード開発、ユニットテストと統合を含みますテストは、この段階でも、変更管理のための需要を追跡し、需要がある場合に変更し、要件文書を配置する必要があり、設計文書は再追いつくあります。利点は、時間をコミットする不注意、開発段階を維持することです、ないタイムリーな自己検査は存在しないコードの開発に代わって落下し、いないユーザーが望んでいる、あなたが問題を望むものがない可能性があります。
5テスト
テストは、テストカバレッジ、時間、労力、経験すべての側面が、制約があるでしょうかテストが、どのように効果的にテストする方法を正確にテストするためにどのようにプロジェクト、、、の非常に重要な部分です。高度なテスターは、各テスト・ポイントシステムを分析することができ、我々は初期のテストケースを書くために、テストする方法を知っている、設計段階に関与する必要があります。良いテストシステムを書きます。ユーザーに、ユーザーの後に各機能の確認。多くのソフトウェアのテストがあります、試験側面に従って行わ内部および外部のテストに分けることができ、試験範囲に係る試験モジュールおよび全体的なFBIに分けることができ、テスト条件に応じて、テストは、テストの正常および異常な動作状態に分けることができます。テストの入力範囲は、完全なカバレッジは、試験試料に分割し、試験することができます。要するに、テストプロジェクトは、大規模なソフトウェアのための非常に重要な開発の段階では常に存在し、予期せぬ問題が発生しますので、外部テストの1年に3ヶ月は、正常です。テスト、および最終文書を完了するためにいくつかの助けの完全な受け入れが完了した後、全体的なプロジェクトは、我々は常にソフトウェアの操作を追跡する必要があり、当然のことながら、最終的には、将来のアップグレード限り、修理作業などは、ワンショット契約を介してお金を取得する必要はありませんが、終わりを考慮す状況を修理やアップグレードソフトウェアが完全に時代遅れになるまで続けました。
6ソフトウェア配信
ソフトウェアは、要件を満たすためにテストされているソフトウェアの後に（1）、ソフトウェア開発者は、ユーザーは、インストーラ、データ・ディクショナリのデータベース、「ユーザーインストールマニュアル」、「ユーザーズ・ガイド」、オンデマンドレポート、デザインレポート、テストレポートを提出する開発を目指すべきです契約に他の当事者は、製品に合意しました。
（2）「ユーザーインストールガイド」のインストール後にソフトウェアの動作環境、インストールソフトウェアの定義とコンテンツ、クライアントのインストール手順では、ミドルウェア・サーバ、システム構成をインストールするための詳細な要件です。
（3）「ユーザーズガイド」ソフトウェアプロセスの様々な機能の使用の側面を含める必要があり、必要なときに、手順、対応するビジネスレポート、ヒントや特別な注意も示す必要があります。
7受入
ユーザーの受け入れ。
8メンテナンス
ユーザが変更を必要とし、又は環境の変化、又は修飾された部分のアプリケーションのすべて。
二つのタイプの中で最も好きなチームの二つ
1つの エージェントチーム：ソフトウェアチームは、特別なスキルを持ったいくつかの専門家で構成され、いくつかの困難を解決するための責任があり、問題の緊急性があります。
2つの コミュニティモデル：多くのボランティアの参加は、彼らは、に興味のあるプロジェクトに関わるすべての人は、ほとんどの人は支払われませんに貢献します。
3つのほとんどどのタイプの過程で取られるべきです
ほとんどの薬剤は、このコースでは、チームの種類を取る必要があります。
利点：
（1）高効率
（2）ショットは他の人が解決できない問題を解決することができるようになります
（3）他の人ではない、非常に良好な技術スタッフのための一例であること、そして他の人が自分のスキルを向上させます
（4）自分の視野を広げる、いくつかの優れた技術を共有します
短所：
（1）知識要件のメンバーの多くの技術スタッフのために、ユニバーサルモデルすることができない、非常に広範です
調和をチームに（2）強いも受け入れることを拒否つながる少しの誇りと傲慢になり、ほとんどの人々の能力、一緒に人々のこのグループは、その後、有害
（3）このような強力なチームの能力、訓練するためにたくさんのお金を費やす生前、ポストは、高い賃金を支払うことをより多くの支出を持っています