![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>高度午前 - 開発技術]] *目次 [#l34a441c] #contents *概要 [#rc4809d3] システム開発技術 *詳細 [#fdd7ad02] **システム要件定義 [#v1ca90ac] ***プライバシデザイン [#rc6add1e] 個人情報が適切に取り扱われるよう考慮したシステム設計をすること。 ***アジャイル開発 [#vb12f6b1] -INVEST（インベスト）~ ユーザー・ストーリーの評価の６つの観点 --Independent（独立している。）~ ユーザー・ストーリーが独立しており、任意の順序で作業できる。~ 先行するストーリーが完了してないと始められない、など他の影響を受けない。 --Negotiatable（交渉可能である。）~ ストーリーが具体的なタスクに落ちすぎておらず、~ 顧客やプロダクトオーナーとプログラマが協働して実現方法を決められる。 --Valuable（価値がある。）~ ストーリー単独で顧客にとっての価値があること。 --Estimatable（見積もり可能である。）~ ストーリーを実現するのにかかる時間が見積もり可能である。~ （他ストーリーとの相対時間は）優先順位を決めるのに役立つ。 --Sized Right (Small)（適切な大きさである。）~ 小さく適正でスコープを把握し易い。 --Testable（テスト可能である。）~ そのストーリーが完了したかどうかをテストできること。 受け入れ条件が明確になっていること。 **システム方式設計 [#l2d07b0d] ***機能要件・非機能要件 [#q51da205] -機能要件~ 業務の観点からソフトウェアが何をするか。 -非機能要件~ 性能面やセキュリティ面等において実現するべき要件。 -利用者要件~ 利用者の観点から、ソフトウェアに対するニーズ。~ この要件は、機能要件と非機能要件の両方が対象になる。 ***システム開発におけるテスト [#kaafce4c] 共通フレーム 2013 JIS X 0160:2012のシステム開発におけるテスト |システム方式設計|ソフトウェア方式設計|ソフトウェア詳細設計|h |システム結合テスト|ソフトウェア結合テスト|ソフトウェアユニットテスト| ***システム開発プロジェクトのライフサイクル [#ad450cb3] デマルコが提唱したシステム開発プロジェクトのライフサイクル ←予算・スケジュール┐┌物理的要求→（ハード調査）──ハード───┐ ↑↑ │ ↓ →ユーザの要求→（調査）→フィジスタ→（構造化分析） │システム （システム開発）→システム ↑↓ ↓構成データ ↑ ───→ユーザの要求┘└構造化仕様書→（構造化設計）─設計・テスト┘ **ソフトウェア要件定義 [#y5146e13] ***論理データモデル作成 [#o8daa43d] -トップダウン・アプローチ~ 企業の情報戦略に基づきTO-BEを検討しつつ論理データモデル作成 -ボトムアップ・アプローチ~ AS-ISを集めつつ改善を加え論理データモデル作成 -最終的に、~ 業務に必要な属性を備えた正規化された論理データモデル~ が作成されるのは、トップダウンでもボトムアップでも同じ。 ***階層化されたDFD [#nec1709f] -構造化分析設計読んだ方がイイ。 -子プロセスは親プロセスと入出力の数が同じである必要がある。 -DFDの書き方は簡単だが、以下の様なプロセスは記法に誤りがある。 --データの入力が無い --データの出力が無い ***UML図（UMLのダイアグラム） [#ab50aec1] -UMLを齧っておいた方がイイ。 -クラスの書き方 --上から ---クラス名 ---プロパティ一覧 ---メソッド一覧 --一覧の可視性 ---（＋）：Public ---（－）：Private ---（＃）：Protected ---（～）：Package(internal) -クラス図の書き方~ 関係の書き方はER図ライクだが、~ データの関連に留まらず、以下の点が異なる。 --インスタンスレベルの関係 ---リンク~ オブジェクトのインスタンス間の関係 ---関連~ オブジェクトの参照 ---集約~ データの関係で部分を表す。 ---コンポジション~ 集約と同じだが、部分の共有が不可能である点が異なる。 --クラスレベルの関係 ---汎化・特化~ クラスの継承関係 ---実現~ 抽象クラスやインターフェイスの利用 --一般的な関係 ---依存~ インスタンスへの変更が、他のインスタンスへ影響を与えることを示す。 ---多重度~ ER図と同じだが、データだけでなく参照の多重度でもある。 -各種、UML図（UMLのダイアグラム） --構造図 ---クラス図 ---オブジェクト図 ---コンポーネント図 ---パッケージ図 ---配置図 ---複合構造図 --振る舞い図 ---ユースケース図 ---アクティビティ図（フローチャート ---ステートマシン図（状態遷移図 --相互作用図 ---シーケンス図 ---コミュニケーション図（コラボレーション図） ---相互作用概要図 ---タイミング図 ***CRUD図 [#q7c27f73] -エンティティのライフサイクル分析 -機能の過不足を確認できる（例えば、削除機能が無いなど）。 ***SysML [#l3a42bc7] -SysML : Systems Modeling Language -システムズエンジニアリングのためのドメイン固有モデリング言語。 -(UML)のサブセットにUMLのプロファイル機構を使って拡張したもの -各種システムやSoSの仕様記述、分析、設計、検証、評価に使う。 -SoS (System of System)~ 複数のシステムを組み合わせて全体で一つとして利用者に提供されるシステム -特徴 --パラメトリック図を使用して、~ システムの要素間のパラメタについて、~ その制約条件を数式で表現すると言った事が可能。 --アクティビティ図を使用して、~ 連接、反復、選択の記述パターンで処理の流れを視覚化する。 --内部ブロック図を使用して、~ ソフトウェア構造を視覚化する。 **ソフトウェア方式設計 [#if5fb39c] ***品質特性 [#k59caa36] JIS X 25010:2013 で定義されており、以下のものがあるが、 -機能適合性 -性能効率性 -使用性 -信頼性 -保守性 ***UIフレームワーク [#y1f08aa1] -コンポーネントベース＆イベント・ドリブン~ １画面１モジュール、複数イベント・ハンドラとカッチリ決まる。 --コンポーネント ---View（画面） ---Codebehind（イベント・ハンドラ） ---業務ロジック、データアクセス --フレームワーク ---JSF ---Web Forms ---Windows Forms -MVC~ Controllerをデータに対応させるか、~ 画面に対応させるか。自由度が高い。 --コンポーネント ---Model~ Model → ViewModel(POJO, POCO)~ 業務ロジック、データアクセス、引数・戻り値 ---View ---Controller --フレームワーク ---Struts ---Spring MVC ---ASP.NET MVC ***ソフトウェア詳細設計 [#e1aeae7b] ***モジュール化 [#l5a2ad74] -分割技法~ 業務系は、業務側がSTS分割（縦）＋TR分割（横）、~ 基盤側が、共通機能分割みたいな感じで設計してるな...。 --データの流れに着目 ---STS分割~ Source（入力）、Transform（変換）、Sink（出力）~ と、DFDと親和性の高そうなモジュール分割技法 ---TR分割~ トランザクション単位にモジュール分割する。~ トランザクションごとの処理が異なる場合に適する。 --データの構造に着目 ---ジャクソン法~ 入出力データの構造に着目して機能分割を行う方法の1つ。~ 入力データの構造と出力データの構造の関係からプログラムの構造を導き出す。 ---ワーニエ法~ 入出力データの構造に着目して機能分割を行う方法の1つ。~ モジュールと言うより、データ処理の制御構造をプログラム構造に反映させる。 -結合度の評価尺度~ 結合度の低い順（結合度は低い程、良い） --データ結合（引数） --スタンプ結合（構造体引数） --制御結合（制御に関する引数） --外部結合（グローバル変数） --共通結合（グローバル構造体） --内容結合（内部データを参照...言語的にはサポートされていない） -強度の評価尺度~ 強度の高い順（強度は高い程、良い） --情報的強度（データでまとめたインスタンス・メソッド） --機能的強度（１つの機能を実現するためのクラス、メソッド。） --連絡的強度（逐次的であることは問題、業務、データ、機能に関連している） --手順的強度（手順的であることは問題、業務に関連しているタメ） --時間的強度（時間的であることは何かしら関係がある可能性がある） --論理的強度（類似機能をまとめたスタティック・メソッド的な） --暗号的強度（定義不可なまとまり） ***[[デザイン・パターン>https://techinfoofmicrosofttech.osscons.jp/index.php?%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%BB%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3]] [#l12bf505] ***ソフトウェア・レビュー手法 [#h20a186f] 多くの場合、レビューはインスペクションを指す。 -インスペクション~ --責任のあるプロジェクトメンバー以外の第三者が参加し、~ 評価基準に基づいて仕様書やソースコードなどの成果物に~ 潜在的な不具合や問題点がないかを検証する会議。 --以下が、他のレビュー手法と比べて特徴的。 ---責任者としてモデレーターが任命され、インスペクション作業全体を統括する ---検出した欠陥をログに保管し、修正が行われたことを追跡調査する -ウォークスルー --レビューを希望する成果物の作成者が、チーム内で、~ 必要な数のレビューアを招集し、成果物の内容を説明する。 --元来は、プログラムの机上チェックで、これがドキュメントチェックに拡張された。 --第三者が参加しない非公式な打ち合わせで、ピアレビューの同義語としても使われる。 -ラウンドロビン・レビュー --レビュー会議の参加者が説明や発言を持ち回りで行う方法。 --参加者の専門性のレベルが同程度のときに有効とされる。 -プロトタイピング~ レビューを減らすことはできるが、~ 観点の異なる専門家を招いたレビューの実施等は必要。 **ソフトウェア構築 [#d4181aa0] ***コーディング標準 [#q1ac2983] -C言語 > MISRA-C :自動車産業関連 -参考 --各プログラミング言語のコーディング規約まとめ - Qiita~ https://qiita.com/moaible/items/134329123074337913fb ***デバッグ手法 [#i73f04ad] -マイコンのデバッグ~ どうも基板上に乗せるマイコン・コンポーネントの~ デバッグ（電子回路の検査）を行うコンテキストらしい。~ マイコンのデバッグはオシロスコープやロジックアナライザといった~ 「針(プローブ)」の測定器を使うことで回路上の信号を測定して行う。 --ICE（インサーキット・エミュレータ） ---これまではICEが広く用いられてきた。 ---ICEはマイコン（MPU）のエミュレータ ---ICEを基板上に乗せて回路上の信号を測定。 --バウンダリスキャンテスト（BST）~ ---マイコン（MPU）の小型化・集積化で回路上の信号を測定が難しくなってきた。 ---ICの端子に埋め込まれた「テスト用回路」を使って、ICの端子の状態を調べたり、~ 入出力する値を変更するBS技術が開発され、これがテストに応用され始めた（BST）。 ---日本では、ディジタルのI/Oしか検査しかできなかったため流行らなかったとされる。~ 海外では、エンドユーザ主導で、効率良くBSTできるソリューションが提供されている。 **ソフトウェア・テスト [#zdadca77] ***用語 [#b058d174] -静的テスト / 動的テスト -ホワイトボックス・テスト~ [[カバレッジ(網羅率)分析>#ecede349]] -ブラックボックス・テスト~ [[限界値（境界値）分析、同値分割>#d3ba6099]] -ボトムアップ・テスト -トップダウン・テスト -ドライバ / スタブ、~ 検査/ 被検査モジュール（テスト対象） ***カバレッジ(網羅率)分析 [#ecede349] -ISO 26262（自動車分野の機能安全規格）で定義されるテスト指標 --C0（命令網羅）~ 通過したステップ --C1（分岐網羅）~ 通過した分岐 --C2（条件網羅）~ 通過した分岐の組合せ（≒条件） --その他 ---経路網羅 ---入口/出口網羅 --RC0（差分 命令網羅）~ 修正後、通過したステップ --RC1（差分 分岐網羅）~ 修正後、通過した分岐 --RC2（差分 条件網羅）~ 修正後、通過した分岐の組合せ（≒条件） >RC0対応ツールを触った感じ、ステップや分岐を修正すると、~ 対応するコード、コード・ブロックのカバレッジがクリアされる感じだった。 -ソート処理のカバレッジ率を上げるテストデータの問題~ 挿入個所に、右端 / 中間 / 左端 が登場するデータセットを選択。 ***限界値（境界値）分析、同値分割 [#d3ba6099] 少ないテスト回数でより広い範囲をカバーするためのテストケース作成手法 -限界値（境界値）分析 --出力が同じになるような入力をそれぞれグループにまとめ、~ グループが隣接する境界付近の値を入力としてテストを行なう方式。 --出力が変化する境界付近では条件式の記述ミスや設計書の解釈の誤り~ などによりバグが頻発するため、その付近の値を重点的に調べる。 -同値分割~ 出力が同値となるグループの中から~ 適当に選んだ代表をテストデータとして取り上げる手法。 **ソフトウェア詳細設計 [#f9d7ed60]
