開発アプローチ

ＵＭＬ(Unified Modeling Language)

オブジェクト指向のソフトウェア開発における、プログラム設計図の統一表記法である。

構成図	クラス図	システムを構成するクラス（概念）とそれらの間に存在する関連の構造を表現する。
	オブジェクト図	クラスを実体化して生成されたオブジェクト同士の関係を表現する。
	コンポジット・ストラクチャ図	クラスやコンポーネントの内部構造を静的に表現する。
振る舞い図	ユースケース図	システムに要求される機能を、ユーザの視点から示したものである。業務システムを単純に表現する。
	シーケンス図	オブジェクト間のメッセージの流れを時系列で表現する。
	コミュニケーション図	オブジェクト間のメッセージの送受信関係を相互の関連に着目して表現する
	アクティビティ図	設計対象の業務手順を表現する
	ステート・マシン図	オブジェクトの状態遷移を記述する
	タイミング図	システムの動作を、時間と共に記述する
	インタラクション・オーバビュー図	システムの相互作用の流れを表現する
実装図	コンポーネント図	オブジェクトやコンポーネントの物理的な配置関係を記述する
	配置図	コンポーネントが実行時にどう構成されるかを静的に表現する

過去問題 平成14年度 1次試験 第12問 平成15年度 1次試験 第14問 平成17年度 1次試験 第13問

アジャイルソフトウェア

　アジャイルソフトウェア開発（-かいはつ、agile software development）は、ソフトウェア工学において迅速かつ適応的にソフトウェアを開発する軽量な開発手法群の総称である。
　 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (Extreme Programming:エクストリーム・プログラミング)などがある。XPは次のような特徴を持つソフトウェア開発手法である

1. 計画ゲーム(The Planning Game)
   ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。
   
2. 小規模リリース(Small Releases)
   シンプルなシステムを早急に生産に投入する。また新バージョンを非常に短いサイクルでリリースしていく。
   
3. 比喩(Metaphor)
   どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)を メンバーが共有することで全ての開発を導く（ガイドする）。
   
4. シンプルデザイン(Simple Design)
   いつでもシステムは出来る限りシンプルに設計されるべきだ。余分 な複雑さは見つけ次第取り除かれる。
   
5. テスティング(Testing)
   プログラマは継続的にユニットテストを書く、それは開発を続けるために 完全に動かなければならない。顧客は、機能の開発が終わったことを 示す機能テストを書く。
   
6. リファクタリング(Refactoring)
   ２重コードを取り去り、コミュニケーションを改善し、単純化し、柔軟性 を加えるために、プログラマは、システムの動作を換えることなくシステ ムを再構成する。
   
7. ペアプログラミング(Pair Programming)
   ２人１組で実装を行い、１人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。
   
8. ソースコードの共同所有権(Collective Ownership)
   誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。
   
9. 継続的インテグレーション(Continuous Integration)
   システムを一日に何回もインテグレードしビルドし、テスト を 100%パスさせる．
   
10. 週40時間(40-Hour Week)
    週４０時間以上仕事をしてはいけない
    
11. オンサイト顧客(On-Site Customer)
    現実のユーザをチームに加えて、フルタイムで質問に答えられるようにする
    
12. コーディング標準(Coding Standards)
    プログラマは、コーディング標準に従って全てのコードを書く

過去問題 平成16年度 1次試験 第10問