EDITORIAL
ソフトウェア工学を研究する学期の後、彼は結び目アジャイル開発プロセスを完了し、3サイクルをプログラミングします。このブログでは、私は勉強の1学期のために要約したと答えた彼の元疑問のために作られました。
学期コースブック鄒衍教師「建築法」を読んで必要であり、ソフトウェア工学の研究の一定量、いくつかの問題を提起する前に、私が開始する必要があります。これはブログのあるリンク。
また、当社は、ペアプログラミングの添付ブログのリンクやチーム開発チームのブログディレクトリを。
質問に答えるために、
研究の学期の後、理論と実践的な側面からの著者は、ソフトウェア工学の発展のために学習されました。学期の初めによって提起された問題のいくつかについても徐々に自分自身の答えを持っています。以下は、これらの問題に関する筆者の見解です。
- 個人的な開発プロセス（パーソナルソフトウェアプロセス）自身の時間のオーバーヘッド？ボーダーの様々な段階を定義しますか？
ソフトウェア開発プロセスの定量的評価のための問題は非常に重要です。しかし、各ステージの時間発展を計算するために、著者の前の開発経験で正確にそれは非常に困難である-開発プロセスの多くの時間は、設計、開発、テスト期間のクロスオーバー方式です。同時記録時間でこの結果は忙しいトラブルになります。
ペアプログラミング、個人的な開発プロセス上の専用の著者は、定量化したとき。コースの要件では、時間のオーバーヘッドの必要性はPSPのすべての段階において必要とされる初期の開発の先頭にあることを、との時間の後に、開発のさまざまな段階で計画どおりに作業を開始することが期待されます。開発プロセスの間に、支出制限時間のPSP計画のおかげで、ツイニングプログラムの各段階について、特定の時間内に著者の目的は、コントロールの上に置かれています。期待された時間内に作業を完了するようにしてください。分析は、その後、実際の使用時、より良いから逸脱することができます。
戻るの質問に、どのように私たちはより良い、より良い、それを開発するために、時間のコストを定量化するために、各ステージの境界を定義することができますか？結び目開発のほとんどが私のドライブで初めから行われているために計画するとき。すなわち、作業の段階の完了に専念する時間の、限られた期間です。あなたが計画策定（最良の場合）に従って完了している可能性がある場合、その計画は、最終的な個人的な開発時間のオーバーヘッドです。もちろん、ペアプログラミング、著者と彼のチームメイトの過程で、私は、スケジュールされた時間のすべての段階を、多くの予期しない問題が発生し、完全に完了しなかったてきました。例えば、時間がスケジュールされた時間とそれが開発し、予定時間より少しをテストするのにかかる時間未満の設計に費やしました。ベンチマーク用を微調整するには、この時点で、唯一の時間オーバーヘッド計画。
全体的に、個人的な時間のコストは、私は、開発プロセスの全体的な進捗と時間を制御するためのより多くを持っているように、開発プロセスを定量化するだけでなく、生成された偏差の各段階で自分の問題を反映することができるようにします。
- 最適化と一般化のタイミング。
コードを最適化する場合？コードの場合は抽象的一般化？場合に応じて二つの質問は、私はまだ、非常に正確ではない答え、またはのみを持っています。
著者ペアプログラミングは、より最適化されている基本的には一般化していません。これは、ペアプログラミングは、需要の変化の多くに直面する必要はありませんで、すべての要件を最初に同定されている主な理由です。その上、作業効率上のプログラムの要件が高いです、あなたはそれ以外の場合は非常に最後の最適化の結果に影響を与え、コードの最適化を始めている必要があります。
開発チームの間に、状況は全く逆です。そのため3回の反復を必要とするため、急速に変化するニーズの顔は、プログラムは、より高い延性を持っている必要があります。彼は抽象的機能、対応する共通機能モジュールの準備によると、先に一般化する必要がありました。そして、多くの収入を持っていない可能性が途中で最適化します。
- 結び目分割二つのプログラミングの回転効率。
この問題に関しては、ペアプログラミングの過程で著者がで遭遇します。取り決めの性質と2時間上のサブ問題の開発に、著者と彼のチームメイトは、独立した開発の方法を取ると一緒にプログラミングを取ります。労働力と効率の分割のためのプログラミングサイクルの接合要約で著者は、自分の意見を得ました。
プログラミングと開発部門など結び目シングルスレッドおよびマルチスレッド。各モジュールの大きい作業タスクの量および開発タスクはサブタスクに並列度の高い分解することができる場合、それは、開発効率が高くなる「マルチスレッド」労働者の非常に明確な部門です。再び1に基づいて、作業負荷の大きな課題に直面して、ペアプログラミングは難しく、開発の進捗状況を進める上で表示される可能性があります。私の初期ペアプログラミングでは、2つのプログラミング効率がより重要である、とすぐに基本的な機能を完了しました。しかし、その後のテスト、最適化、回帰テスト、GUI描画などが表示され、プログラムの進捗状況を前進させるためにタスク少ない豊かな結び目を困難にするために時間を過ごしました。彼らは最終的に私は、タスクのタスクの一部は、タスクの接合部に圧力を緩和、分業の進展だっただろう。
ペアプログラミングは、人々の開発のための方法です。しかし、すべては私たちが実際の状況を選択する必要があり、すべての状況下でペアプログラミングには適していません。開発モードの選択に発生した費用のために推定する必要がある、我々は分業を決めます。予想される効率は、他の開発モードに不十分な缶考慮事項である、または直接、政策展開を変更した場合。
- アジャイル開発のミッション計画と事前の問題。
チームの開発プロセスでは、彼はαの繰り返しでプロジェクトマネージャー（PM）の役割が、支援プロジェクトマネージャーを果たしていませんでした。そして、「法の構築、」同じの話本は、スクラムは、共同チームの各部分ことを確実にするために、全体的に情報を送信するために主に各メンバー主導型、およびプロジェクトマネージャによるイニシアチブです。計画作業のために、そしてもっと一緒に完了するために、チームメンバーが議論されています。この場合、1は、より完全な計画を達成することができます。しかし、タスクを中継する際に発生するエラーを回避するために。問題を促進するためのプロジェクトのために、イニシアチブの各メンバーが、また、プロジェクトマネージャーに基づいて、真の各メンバーの間で通信を行います。私のチームでも、非常に体調不良となって協力を行い、プロジェクトの進捗に影響を与える、などの虚偽の報告の進捗状況を、高めるためにはない困難がありました。
すべてのすべてで、最も重要なことはコミュニケーションである私たちが議論することができるように、問題は、テーブルの上に置かれています。ミッション計画やプロジェクトに参加するすべてのメンバーは全員の参加と取り組みを促進し、改善するためにしてみましょう。
- 個々のパフォーマンスのチーム開発の評価。
この学期は、彼女が2人のチームでソフトウェアの開発に参加しています。各グループは、個々のパフォーマンスを評価する別の方法があります。実際には、性能を評価するための何の最善の方法はありません。グループでは、誰もが評価を受け入れることができるように良い方法です。グループコースは、現像前に、個々のパフォーマンスを評価するために、各グループは、評価方法がメンバーとして受け入れられることを保証するために検討された方法が必要とされなければなりません。
ソフトウェア開発プロジェクトの概要
私たちは、作者のこの部分におけるソフトウェア技術開発の6つのフェーズからの経験を総括します。
需要分析 - 分析枠組みNABCD
ニーズの分析フェーズでは、書籍「法の構築は、」NABCDは、ユーザー、競合他社とのプロジェクトは、分析を必要とする促進するための5つの方法の利益のために練習を取る、元の要求から、分析の枠組みを提案しました。プロジェクトチームプロジェクトの後、5つの方向に従って、各グループはNABCDは、プロジェクトのニーズのための調査を実施しました。この方法では、より包括的なニーズ分析プロジェクトの目標を測定するだけでなく、そのようにプロジェクト開発の焦点はより明確に、発生する可能性のある潜在的な障害物にします。たとえば、プロジェクトチームの著者の分析の後に最大の困難は、プロモーションにあることがわかりました。だから、チームはグループの使用の確立と推進のためのより多くの経験を必要とします。
デザイン - 仕事の前に完全な文書を形成するために、
ニーズの分析を完了した後、最も重要なことは、オンデマンドで、完全な実行可能な文書を形成することです。この点で、私は深い感情であると言うことができます。αの初期段階でのチーム、デザインインタフェースの文書中に生成多少の誤差が生じ、フロントとバックエンドの開発経験のある特定の不足、（作者含む）チームメンバーは、文書の形成に多くの欠陥があるため。これは、後半インタフェースのドキュメントで開発頻繁にリモデリングプロセスにつながる最後の文書全体が廃棄されていてもに、必要とされます。これは、大幅に開発の進捗状況の著者チームに影響を与えました。
設計段階で抽象需要、洗練後の文書を書き込む機能、フロントとリアエンドインターフェースのドキュメント、およびように。これらの文書は、プロジェクトチームのメンバーのための契約と同等であり、後の段階で主導的な役割を果たしました。また、文書は、テキストの理解に偏りを避けるために、より簡潔な記述する必要があります。議論は完璧な文書を形成する前に、チームの作業が必要です。
実現 - 常に文書に従って設計に従ってください
要求分析と設計が完了した後、チームの各メンバーは、それぞれのタスクを設定します。実施段階では、各メンバーはしばしば、それぞれの任務の境界を議論することは困難であるが、各タスクは全体自己にドッキングさせることができることを確実にするために文書の設計段階に応じ。したがって、実施段階では、非常に重要な文書の開発に関する契約に厳密に従ってインチ ときに反復β及びγ段階、バックエンドの開発タスクとして別のチームに移動します。交渉さインタフェースフォーマットの真ん中のフロントエンドの開発の初期段階のスプリントの作者とメンバーのα相のレッスンに感謝します。ちょうどそのインターフェースに厳密に従って前後端には、コードを書くために、私たちは、前端と後端の最終的機能の一貫性を確保し、開発中の不要な議論の多くを排除することができます。
テスト - 完全なテストが鍵
テストフェーズ中に、著者は、バックエンドコードのユニットテストに責任があります。「建設法の」本はつまり、テストコードの前にユニットの設計段階を達成するために、テスト駆動開発の方法を述べました。私は、開発中のこのような方法で開発してみました。このようにコードを書くことは、その正しさの完了を保証するだろうが。また、カバレッジテストは、私はまだテスト段階では、「法の構築、」話してブックに従って試験しました。完全なテストは、高品質のソフトウェアを生成するための基盤です。プロジェクト内の各モジュールについて、多くの場合、あなたはそれをテストするために、より多くのコードを使用する必要があります。
リリース - 可能な最小の初期バージョンをリリース
アジャイル開発は、主要な機能はすぐに特定のバージョンを使用することができます開発チームを必要とし、迅速な反復、です。これは、アジャイル開発チームは、ソフトウェアの1時間の最終版を与えるために必要とされていないことを意味します。本の中で、チームは「法の構築」を与える必要の各段階のためのソフトウェア要件は、以下の説明があります。
アルファ段階：第一は、試用版の主な機能の統合を指します。いくつかの小さな機能は、このバージョンでは実装されていません。実際には、ソフトウェアの多くのアルファ版は内部でのみ使用されます。外部のユーザーへのアルファ版はように、例えば、より多くの素晴らしい名前を果たしテクニカルプレビュー（テック-nicalプレビュー）、およびます。
ベータ相：完全な基本的な機能、アルファバージョンよりも高い安定性は、ユーザーがベータ1、ベータ2、ベータ3 ......持つことができ、実用的な作品で、小さな範囲を使用することができます
ZBB段階、例えば（前のmakeのある日バージョン：（ゼロバグビルド） 48時間前）解決されるバグを記録しました。
RC段階（リリース候補）：リリース候補、RTMまでRC1、RC2 ......、間隔のバージョンが短くなっています。
RTM段階（メーカーへのリリース）：最終リリース版。RC版のいずれかが大きな問題ではない場合、これはRCの最終バージョンになり、通常の状況下では、ソフトウェア会社の最終版と別のチーム（マヌー-facturer）に関連する文書やその他の情報は、意志パッケージに、リソグラフィCD。AppStoreの/ Marketplaceの時代に、我々は適切なRTM（市場へのリリースを）持っています。
RTW段階（ウェブへのリリース）：RTMと同様に、ネットワーク・アプリケーションのために、我々は、流通チャネル「メーカー/市場」CD-ROMオーサリングソフトウェアや管理ソフトウェアに依存しませんが、私たちの最終版を公開する「ウェブ」に依存します。ときにシステム一緒に運用チームとR＆Dチーム（とソフトウェア製品は、Webサービスの場合、一般的に管理するために、サイトの運用チーム（運用チーム）に転送されます、また、RTO（操作にリリース）と呼ばれるこのリリースでは、ライン上で決めました）ライブ行きます。それぞれのアプリケーションストアに提出ソフトウェアは、ストアにリリース呼び出すことができます。
チームの開発では、私はα、βおよびγの段階を経験しました。アルファ段階でどの、チームは後にほぼ月の時間は、プロトタイプソフトウェア、基本的な機能といくつか与え、まだメインランイン期間である「キラー機能を。」既存の問題を修正し、必要に応じて機能を追加：ベータ版の段階では、それは完璧に既存のプロトタイプです。ガンマステージは、改善するための目標と仕事を仕上げるためのソフトウェアの基本的最初の2つの段階RTM段階に似ています。
各フェーズのこの時間は、それがユーザーのために、できるだけ早く利用可能なバージョンをリリースすることを目指して、十分な長さではありません。ユーザーのみが、実際には最も現実的なフィードバックを得ることができるようにソフトウェアを使用しています。これは、研究方法を達成することはできませんアンケート調査です。
メンテナンス - ユーザーからのフィードバックにタイムリーに対応
ソフトウェアのリリースバージョンが利用可能になった後、チームのメンテナンスチームは、ユーザーからのタイムリーなフィードバックを得る実際の需要の変化を監視するだけでなく、応答部にソフトウェアを変更する必要があります。ステージγとき、私はチームに参加し、学校外でのソフトウェア開発のための要求を受信しました。ソフトウェアの後ユーザーテスト中に放出され、すぐにすべての面で機能するようにUIからのアドバイスをカバーし、ユーザーからのフィードバックをたくさん受けました。フィードバックの要約した後、チームのメンバーは、選択をお勧めしますし、すぐにソフトウェアが更新されました。
ユーザーからのフィードバックに基づいてタイムリーなメンテナンス、ソフトウェアがより密接に、ユーザーの実際のニーズを作ることができます。また、維持期では、時間から検索し、隠された問題を解決することができるソフトウェアをテストする時間に、ソフトウェアの寿命を延ばします。
学期レビュー
研究ソフトウェア工学の学期では、私は、総反復時間と3ペアプログラミングのチーム開発を経験しました。ソフトウェア開発プラクティスの様々なを通じて、ソフトウェア開発手法やプログラミング機能および他の著者は、収穫がたくさんあります。
プログラミング能力で、アルファ段階後の移動の結果として、著者は3つの環境での開発作業の合計を行いました。ペアプログラミングの間に、著者は、プログラミング言語C ++としてチームメイトを使用しています。そして、チーム開発の際に、著者はLaravel PHPフレームワークとPython Djangoフレームワークを研究しています。また、それはまた、開発言語の前部を持ち上げました。これは、大幅に開発が終了する前と後の著者の開発技術・スタック、濃縮されたパターンとスキルを豊かにします。それにもかかわらず、著者はバックエンドのコードの操作機構、バックエンドのデータの抽象化、フロントエンドの配信にバックエンドので、より深い理解を持っているため、バックエンド部分の開発を担当しています。
ソフトウェアエンジニアリングのために、最も深い理解の著者は、プロジェクト全体の純粋なプログラミング作業が最も重要ではないです。特に、チーム開発、非プログラミング作業は、多くの場合、ソフトウェアの開発に重要な役割を果たしているとき。開発チームは、著者と彼のチームメイトは、研究、議論、通信、デザインなどの仕事に多くの時間を費やしていたとき。仕事は、開発のための基盤です。これらの非プログラマは非常によくやっている仕事にするとき明らかにあなたが感じることができる、それは非常に簡単になります開発作業を推進しています。アルファステージは、からこそコミュニケーションや他の作業の著者のチームが、最終的な開発の問題につながる、不十分行われた場合。けれども過程で多くの問題や挫折に遭遇したが、私は深く獲得。この学期に取り組んで、我々はより深く、様々な段階での作業、ソフトウェアエンジニアリングの開発のために理解しています。