ステキな一日

IT技術やトレンディな話題を中心に個人的なメモを書き綴っていきます。

サイクロマティック複雑度で、外注したプログラムのソースコードの品質を判定する方法

サイクロマティック複雑度をご存知でしょうか。この記事でご紹介するのは、サイクロマティック複雑度を使った、ソースコードの品質測定についてです。

たとえば、取引先に製造を依頼したプログラムの品質を判定するには、このサイクロマティック複雑度と他の管理手法とを組み合わせると良いでしょう。

【広告】  

サイクロマティック複雑度(循環的複雑度)とは

プログラム中の、IF、for、switchのcaseなどの分岐経路の数を数えることで、プログラムの複雑度を計測する方法です。

この方法で導き出された複雑度は、プログラムの可読性についての指標ともなります。

また、計測した複雑度から以下のように判定する目安もあります。

循環的複雑度 複雑さの状態 バグ混入確率
10以下 非常に良い構造 25%
30以上 構造的なリスクあり 40%
50以上 テスト不可能 70%
75以上 いかなる変更も誤修正を生む 98%

出典:https://jp.mathworks.com

 詳しくはWikiで確認してください。

循環的複雑度 - Wikipedia

 サイクロマティック複雑度の計測ツール

フリーソフトの lizard というものがあります。

lizardは、python上で実行できるフリーのツールです。

インストールなどは以下の記事に詳しく説明があります。ただしMacOS向けの内容ですので、Windowsの場合は少し異なる部分があります。

qiita.com

 

ソースコードの品質判定

最近のシステムは大規模なものが多く、全てのソースコードを目視確認するわけには行きません。 上記で説明したサイクロマティック複雑度を用いて、ある範囲のコードに絞りこんで目視検査します。

ツールを使って、複雑度が25を越えるようなソースがあれば、そのソースコードを目視確認する。という判定でよいかと思います。

単純な方法ですが、これは有効なものです。

 

以上、「サイクロマティック複雑度で、外注したプログラムのソースコードの品質を判定する方法 」でした。

【広告】  

ムームードメインで取得したドメインをはてなブログで使う方法

ムームドメインで取得したドメインをはてなブログに設定する方法のメモです。はてなブログで独自ドメインを設定するにはPROに契約する必要がありますので、PRO契約が完了していることが前提となります。

(1)ムームドメインでドメインを取得します。

まずは、ムームードメインのサイトでドメインを取得します。手順としては自分の希望するドメインを検索して購入可能なドメインを購入することになります。その時に、会員登録とクレジットカードの情報も合わせて必要になります。また、ドメインの維持にはお金がかかりますので、何年かのプランで購入するとちょっとお得な価格になりますが、毎年更新にしても良いかも知れません。

ドメインの購入が完了するとムームードメインからメールが届きます。内容としては、契約完了のお知らせと、2週間以内にドメイン情報認証をする必要があるという内容のメールが届きます。

ここでは仮にhogehogeunk.com を取得したものとします。

【広告】

(2)ムームーのコントロールパネルでDNSの設定をします。

ムームードメインでドメインの購入が完了したら、ムームーのコントロールパネルでDNSの設定をします。手順は以下の通りです。

  1. ムームーのサイトにログインします。
  2. ドメイン管理にある、「ムームーDNS」をクリックします。
  3. 右側に取得したドメイン(例 hogehogeunk.com )が表示されるので、「変更」をクリックします。
  4. 設定2セクションの表部分に以下の情報を入力します。 サブドメイン:サーバー名というか、取得したドメインの前に設定する名称になります。(例)www 種別:CNAME 内容:hatenablog.com ←かならずこの内容を入力します。hatebloo.jpとかを入力するとうまくいきません。
  5. セットアップ情報変更ボタンをクリックします。

(3)はてなブログの詳細設定をします。

はてなブログにログインして、以下のように設定します。

  1. ダッシュボードの[設定]をクリックします。
  2. 右側に設定が表示されたら、[詳細設定]タブをクリックします。
  3. 独自ドメイン[PRO]欄に、次のように入力します。 サブドメイン.取得したドメイン (例)www.hogehogeunk.com
  4. 画面最下部にある[変更する]ボタンをクリックします。

以上です。ここまでの手順が完了したら、取得したドメイン名でブログにアクセスして正常に表示されることを確認します。

例: www.hogehogeunk.com

 

(4)うまくいかないときの対処

ムームードメインの設定が間違っていると、取得したドメインにアクセスしたときに、元のはてなブログのアドレスにリダイレクトされてしまうことがあります。この場合は、ムームードメイン側の設定を正しく設定し直した後に、いったん、はてなブログの独自ドメイン[PRO]欄を空欄に設定して[変更する]ボタンでクリアしてから、もう一度、独自ドメイン[PRO]欄を設定し直すとうまくいく場合があります。

 

 

w2uiでGridを作ってみる

w2uiでグリッドを作るのはとても簡単。

まずはw2uiを使用する準備ですが、googleのCDNとw2uiサイトのsrcをheadタグ内に配置します。 ※環境によってはjQueryとw2uiのjs,cssをダウンロードして使用してください。

    <link rel="stylesheet" type="text/css" href="http://w2ui.com/src/w2ui-1.4.min.css" />
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
    <script type="text/javascript" src="http://w2ui.com/src/w2ui-1.4.min.js"></script>

次に、グリッドを配置したい場所に以下のようにdiv要素を配置します。

<body>
    <div id="myGrid" style="height: 450px"></div>
</body>

javascriptは以下のように書きます。

$('#myGrid').w2grid({ 
    name   : 'myGrid', 
    columns: [                
        { field: 'fname', caption: 'First Name', size: '30%' },
        { field: 'lname', caption: 'Last Name', size: '30%' },
        { field: 'email', caption: 'Email', size: '40%' },
        { field: 'sdate', caption: 'Start Date', size: '120px' },
    ],
    records: [
        { recid: 1, fname: 'John', lname: 'Doe', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 2, fname: 'Stuart', lname: 'Motzart', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 3, fname: 'Jin', lname: 'Franson', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 4, fname: 'Susan', lname: 'Ottie', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 5, fname: 'Kelly', lname: 'Silver', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 6, fname: 'Francis', lname: 'Gatos', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 7, fname: 'Mark', lname: 'Welldo', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 8, fname: 'Thomas', lname: 'Bahh', email: 'jdoe@gmail.com', sdate: '4/3/2012' },
        { recid: 9, fname: 'Sergei', lname: 'Rachmaninov', email: 'jdoe@gmail.com', sdate: '4/3/2012' }
    ]
});

records で指定しているrecidはグリッドデータの主キーになる部分です。このrecidを用いてgrid内のデータにアクセスしたり、データを更新したりします。 上の例はレコードを直書きしていますが、json形式でサーバーから受信させる場合にもrecidは指定する必要があり、recidが重複すると、エラーは出ませんがグリッドの動作がおかしくなりますので注意が必要です。

以上、「w2uiでGridを作ってみる」でした。

【広告】

明日から迷わず行動するために(なぜなぜ分析)

今回のなぜなぜ分析は、ヒューマンエラー(人為的ミス)の再発防止策を導き出すためのメソッドです。ちまたには、沢山のなぜなぜ分析手法がありますが、こちらで紹介する方式は特に分かりやすく、効果が高いものと思います。

【広告】

なぜなぜ分析の目的

なぜなぜ分析の目的は明日から私たちはどのような行動をすれば同じミスを繰り返さないかを導き出すことです。そのために、私たちは使命を大切にします。私たちの使命は現場作業をうまく回すことなのか、それとも管理者として仕組みを作ることが使命なのか。使命に基づいて再発防止策を導き出しましょう。

なぜなぜ分析の手順とポイント

 

追求すべき事象の選定

なぜなぜ分析を始める前に、追求すべき事象の選定をし見極めます。どのような事態が発生したかを具体的に把握し、追求すべき事象を見極めます。例えば、「伝票が入力されていなかった」と言うのはダメな例です。良い例としては「100枚の伝票があるうち1枚だけが入力されていなかった」さらに「それは60番目の伝票だけが入力されていなかった」とします。 この事象の選定が非常に重要なポイントとなります。何を分析するのかの的が外れてしまっては良い分析ができません。 なお、分析対象の事象が複数ある場合は別々に分析を行います。

いきさつフロー図の作成

なぜなぜ分析をする前に「いきさつフロー図」を使い、原因追求の対象を整理して把握します。発生した事象に至るまでの経緯を時系列に細く書き出します。誰からどういう手段で情報伝達をされどういう行動したか何があったかなどです。 これは情報収集の作業です。左から縦軸に日時、その隣に関係者を並べたフローチャートを作成します。

時系列に、行なわれた作業と、誰から誰へ、どのような手段を使って、どの様な情報を伝達がされたかという事をフローチャートとして書き出します。作業には順番に1番、2番というように番号を振っておくと、後からの作業に役立ちます。

前提条件の把握

次に前提条件を把握します。それは、いきさつフロー図から議論する必要のない部分で、それらを除外していきます。例えば、「忙しかった」「寝不足だった」なども前提条件とします。 前提条件というのは直接原因ではなく、排除できるものです。ただし確証の取れるものをリストアップするようにしてください。対象全てを除外するわけではありません。これらはなぜなぜ分析シートの前提条件欄にリストアップしておきます。 これはどういうことかと言いますと、「忙しくても」「寝不足でも」問題を発生しない対象を導き出すということになります。

なぜを抽出します

分析対象の実事象に対してなぜと問いかけてなぜなぜ分析を始めます。 この時、分析対象の事象を現時点として、なぜ、なぜ、と掘り下げるごとに、過去に遡っていくように分析します。この作業には調査した時系列のいきさつフロー図が役立ちます。

なぜを抽出するには5つの要素が重要になってきます。 (1)主語をはっきりさせること。 (2)具体的にわかりやすく出すこと。 (3)時間軸を分かるように記述すること。 (4)ポイントとして「~に気付かなかった」という言葉を入れること (5)分析の目的をはっきりさせること。現場ですぐ使える対策案を出すのか、それとも 経営に関係するところまで分析するのか、それは冒頭で述べた「私たちの使命」に基づいた分析目的とします。

なぜを抽出する段階で、前提条件が出てきたら、それは「なぜ」には入れずに前提条件に入れるようにします。「疲れていた」「本人の意識が低い」などの問題は前提条件として、「疲れていても」「本人の意識が低い状態でも」同様の問題を繰り返さないためにはどうすれば良いかを導き出すのが目的です。

整合性の確認

「なぜ」を全て出し切ったら、逆読みして筋が通っているかを確認します。分析シートを右から「〇〇だから、〇〇」と読み返します。「ボタンを押し間違えた、だから、エレベーターが違う階で止まった。」などというように、参加者全員で読み返して、意味がわかるかを確認します。

狙いは再発防止策を出すこと

なぜなぜ分析で導き出した「真因」から、暫定処置、再発防止策、を導き出します。暫定処置はともかく、最終的には再発防止策を導き出すようにします。

再発防止策とは

①発生しないように、または発生しにくくしてしまう ②発生しても被害が出ないうちに間違いに気づいて、正しく処置を施せるようにしておく

対策案はすべてを同時に実行するのではなく、対策案を評価して、どれから手を打つのかということを検討します。評価としては、必要性、効果、コスト、実行難易度、総合評価、優先順位から行います。

なお、再発防止策については「周知する」や「徹底する」という言葉が出てきたら、それは間違いです。周知や徹底というのは再発防止になりません。仕事のやり方、手順に反映するような再発防止策を出すことが重要です。

以上、「明日から迷わず行動するために(なぜなぜ分析)」でした。

【広告】

ソフトウェア開発で失敗を繰り返さないためのレビュー技術

ソフトウェア開発において、レビューは品質確保においてとても重要なものです。しかしながら、実際の開発現場では疎かになってしまっていることが往々にしてあります。今一度レビューの重要性について理解しましょう。

【広告】

レビューとは

レビューは各工程で作成された成果物が要件を満たしたものであることを確認するための行為です。レビューにより品質状況を把握して、次工程へ進んでよいかを見極めます。

レビューをすることにより、成果物の正しさを組織へ証明し、間違いを修正することができます。また、レビューされる人の育成をする場としても有効です。

なお、成果物の正しさを証明するという事は、作成者が証明しやすいように作る必要があります。それによって、成果物の理解性や保守性が向上し生産性が良くなります。

レビューの観点

レビュー対象物は、文体、仕様、構造の三つの観点からレビューを行います。

文体 書式や形式についてレビューします。ドキュメント規約などに基づいて正しく記述されているかどうかを確認します。

仕様 前工程で定義された要件や機能をレビューします。前工程で定義された外部・内部要件が当工程の成果物に漏れなく、余分なく反映されていることを確認します。

構造 開始・終了処理、正常・異常処理などの対称性や、同様な処理についても同じような構造で記述されているかを確認します。

また、組織独自に過去の事例から、必要な観点があれば追加して確認を行います。

レビューの種類

レビューの種類を効果のある順序で紹介します。

(1)自己レビュー 作成者自身がレビューを行います。本人のスキルアップ、ケアレスミスの修正を目的とします。自己レビューで9割がたのケアレスミスを減らすことができます。

(2)ピアレビュー プロジェクトチーム内など、同じような立場の人たちでレビューを行います。これにより、思い込みや間違いを修正できます。

(3)対面レビュー ベテランと若手、上司と部下など、レビューを受ける人とレビューアーが対面してレビューを行います。レビューを受ける側のスキルアップ、別の視点からの指摘を受けることができます。

(4)会議レビュー 関係者を集めて、会議形式のレビューを行います。複数の目で見た多様な観点でのレビューになり、コミュニケーション、教育の場となる。しかし、工数が多くかかったり、参加者のスケジュール調整が難しいという欠点もある。

(5)回覧レビュー レビュー対象物を回覧してレビューしてもらう。回覧で回ってきた人は、自分の作業より優先度が下なので、ろくに見ないケースが多いので、あまり当てにならない方法で効果は薄い。

レビューの実施

レビューは随時行う方法と、一括で行なう方法があります。

随時レビュー 各工程の途中で随時実施して、問題点の早期発見と手戻りの削減を目的として行います。

一括レビュー 工程の最後に実施し、次工程へ進めるかどうかを見極め、成果物を凍結します。

レビュー結果の記録と品質管理

レビューを実施したら、必ず結果の記録を行います。 レビューの実施時間、指摘事項の内容、件数などを記録してください。こうして記録した内容は、プロジェクトの品質改善のための貴重なデータとなります。 品質管理部門では、プロジェクトの規模とレビュー実施時間、指摘事項件数などから、プロジェクトの健全性を評価することができます。具体的には、プロジェクトの規模とレビュー実施時間に対して、指摘件数が多すぎる、少なすぎるといった所で一次判定を行い、内容を精査するトリガーとする場合があります。

最後に

品質管理をしていて特に目につくのは、不具合の原因を作りこんだ工程が、要件定義や設計段階だという事が多いことです。また、その原因として多いのがレビュー不足です。プロジェクトの上流工程での不具合は大きなインパクトのある不具合を発生させます。 時代の流れとして短納期の開発が求められ、常に時間に追われる開発者の気持ちも分かりますし、また、自分の作成した成果物に自信があるのは大いに結構です。しかし、レビューを疎かにしたことによって後で飛んでもない時間ロスを招いているケースが多く目立ちます。ぜひとも計画段階でレビュー工数をきちんとスケジュールに明記して、レビューをしっかりとするようにしましょう。

こちらの記事も合わせてお読みください。 www.sutekina121.com

ヒューマンエラーを防止するためのなぜなぜ分析のについても、合わせてお読みください www.sutekina121.com

以上、「ソフトウェア開発で失敗を繰り返さないためのレビュー技術」でした。

【広告】

サロゲートキーによるDB設計について

サロゲートキーによるDB設計について。データベースを物理設計する段階で、主キーが複合キーとなってしまう場合に、どうするかを検討したことがあるだろうか?

私の周りでは、何の気なしに複合主キーを用いた設計が氾濫している。 たしかに、業務上でユニークなキーを使って論理設計をしているものだから、そのまま実装するのが余計な時間もかからないし、誰が見ても(?)わかりやすい実装になるかも知れない。

しかし、複合主キーが氾濫していると、SQLが複雑になり、それがバグの温床になったり、更には、ひとたび業務変更がおきると、対応のために複雑なSQLを解析したり、DBに大幅なデザイン変更が発生したり、と後々のメンテナンスには目に見えない大きな影響を及ぼしたりする。

【広告】

実際の開発現場ではサロゲートキーが有利な場面が多い

「サロゲートキーを使うのは議論のあるところ」みたいなのをよく目にしますが、実際の開発現場ではサロゲートキー(代替キー)を用いた設計の方が圧倒的に有利な場面が多いのは間違いないでしょう。
以降にサロゲートキーを用いた設計手順と、複合主キーとの比較例を合わせて説明します。そもそもサロゲートキーを使ったことが無いという方は一度チャレンジしてみていただきたいと思います。なお、近年のフレームワークではそもそもサロゲートキーとしてid項目を実装するのを前提として開発されているものが多く、知識としても知っておきたい事項であることも事実です。

サロゲートキーを用いた設計手順

さて、実際のサロゲートキーを用いた設計方法について手順を追って説明したいと思います。
まずはモデリングを行います。まずは論理モデルとしてサロゲートキーを意識せずにモデリングをしてください。(これは説明するまでもありませんね。)
論理モデルが出来上がりましたら、次は物理モデルとしてサロゲートキーを検討していきます。複合主キーとなるテーブルの親テーブルに、id という項目を新規に追加して、これを主キーとします。もともと、主キー候補だった項目にはユニーク制約インデックスを作成します。次に複合主キーとなっていた子テーブルからはそれらのキー項目を削除して、代わりに 親テーブル名+"_id"という名称の項目を追加します。この項目は親テーブルのidと同じ属性です。

論理設計の例:

物理設計の例:

ポイント
(1)外部キーとなる項目は親テーブル名+"id"というルールにする。厳密にする必要はない。たとえば、ユーザーid を用いる場合にテーブルに複数のユーザー_idを持つ場合などは困るから。

(2)サロゲートキーの採番は、自動インクリメントでもよいが、個人的にはUUIDを推奨する。これは他のテーブルのキーと比較した場合でも一意を保証されるからである。

(3)クラスター化インデックスは、サロゲートキーではなく、業務上で塊になっていてほしい項目を用いたインデックスにした方が良い。

(4)業務上でユニークとなる項目を使ったユニーク制約インデックスを作成する。

複合主キーとサロゲートキーの実装例

以下に簡単な例を挙げてみよう。

複合主キーのSELECT文の例:

このとき、データ一覧を出力する際に、このようなSQLなどになるだろう。

SELECT 製品名称,親部品名称 ,部品名称,必要数量  
from 製品マスタ  
<span style="color: #000000;">inner join 構成マスタ  on 製品マスタ.製品番号 = 構成マスタ.製品番号 and 製品マスタ .製品型式 = 構成マスタ.製品型式  </span>
inner join 部品マスタ  on 構成マスタ.部品番号 = 部品マスタ.部品番号  
where 製品マスタ.製品番号= 'NNN-NNNNN' and 製品マスタ.製品型式 = 'X';  

では、サロゲートキーに置換した例も見てみよう。

サロゲートキーに置換したSELECT文の例:

SELECT 製品名称,親部品名称 ,部品名称,必要数量  
from 製品マスタ  
<span style="color: #000000;">inner join 構成マスタ  on 製品マスタ.id = 構成マスタ.製品id</span>  
inner join 部品マスタ  on 構成マスタ.部品id = 部品マスタ.id  
where 製品マスタ.製品番号= 'NNN-NNNNN' and 製品マスタ.製品型式 = 'X';  

JOINのキーがすべてテーブルのIDで結合しているのがわかるでしょうか。

UPDATEの比較

に構成マスタの必要数量に1をセットするUPDATEを比較してみましょう。それぞれ主キーでレコード選択をします。

複合主キーの例:

    UPDATE 構成マスタ  
    SET       必要数量 = 1  
    WHERE  
        製品番号= 'NNN-NNNNN'  
        and 製品型式 = 'X'  
        and 部品番号 = 'YYYYYYYY'  

サロゲートキーの例:

    UPDATE 構成マスタ  
    SET       必要数量 = 1  
    WHERE  
    id = '550e8400-e29b-41d4-a716-446655440000'  --UUIDを使った場合の例  

業務変更時の比較

それでは最後に、業務変更があって、部品マスタに輸入と国産の区別が追加された場合を考えてみます。

複合主キー:

SELECT 製品名称,親部品名称 ,部品名称,部品マスタ.国産輸入区分,必要個数  
from 製品マスタ  
inner join 構成マスタ  on 製品マスタ.製品番号 = 構成マスタ.製品番号 and 製品マスタ .製品型式 = 構成マスタ.製品型式  
inner join 部品マスタ  on 構成マスタ.部品番号 = 部品マスタ.部品番号 and 構成マスタ.国産輸入区分 = 部品マスタ.国産輸入区分  
where 製品マスタ.製品番号= 'NNN-NNNNN' and 製品マスタ.製品型式 = 'X'  

サロゲートキー:

SELECT 製品名称,親部品名称 ,部品名称,国産輸入区分,必要個数  
from 製品マスタ  
inner join 構成マスタ  on 製品マスタ.id = 構成マスタ.製品id  
inner join 部品マスタ  on 構成マスタ.部品id = 部品マスタ.id  
where 製品マスタ.製品番号= 'NNN-NNNNN' and 製品マスタ.製品型式 = 'X'  

いかがでしょうか?このように業務に変更があった場合でもテーブルやSQLの変更が少なくて済みます。

まとめ:メリットとデメリットを比較

簡単ですが、メリットとデメリットを比較してみます。

メリット デメリット
複合主キー  ・テーブルをそのまま見たときに、業務的なデータが見られる。 ・何がキーなのかわかりやすい。  ・SQLの結合がバグの温床になる。 ・主キー検索で複数対象の値指定ができない。 例:pk in ('a', 'b')のような使い方ができない。 ・アプリケーション上でユニーク値の保持処理が煩雑になる。 ・コード値の構成変更などの業務変更に弱い。
サロゲートキーを使った単一キー  ・テーブル間の依存関係を弱めることができるので、仕様変更に強くなる。 ・テーブル結合SQLが簡単になることで、バグが減り、コードを速く書ける。 ・フレームワークでよく使われている。  ・論理設計上に必要ない項目を設計する必要があり、扱い方を理解するのに少し時間がかかる(?)。 ・外部参照している場合は、結合しないと関連が分からない。 ・余計な項目が増えてディスク容量を圧迫する。(ホントかいな?実際にやって見るとわかるけど、複合主キーをサロゲートキーに変換すると各エンティティで保持する項目が少なくなる事が多い。)

以上、「サロゲートキーによるDB設計について」でした。

【広告】

効率的な設計レビュー方法

ソフトウェア開発で設計レビューをしているが、やり方が人それぞれバラバラで効果がよくわからない。ということはないだろうか。せっかく時間をかけてレビュー会をやっているのに形式だけになっているのならば、戦略的なレビューを実施することで、効果のあるレビューにしたい。

【広告】

レビューの目的とは

  • 工程の漏れや間違いを見つけ、後工程での修正コストを少なくすること。

以上

つまり誤字脱字系の軽微な間違いは後で直してもたいしたコストはかからないが、設計の漏れや間違いは後工程になればなるほど修正コストが増大する。最終的にリリースした製品に発生した不具合は修正コストもさることながら損害賠償問題にまで発展すれば経営にインパクトを及ぼすような膨大なコストとなる。

事前準備

  1. プロジェクトリーダーが「見逃し問題リスト※1」から、過去の類似案件の指摘事項や、レビューをすり抜けてテストや本番で大きな手戻りが発生した内容を洗い出して、今回のレビューで使用するチェックリストを作成する。
  2. プロジェクトリーダーがレビューでどんな問題種別を検出すべきかを考え、その要点をまとめたシナリオをいくつか作成する。(1~2Hで作成する)
    1. システムに求められる性能や機能、メンバーの状況などから考えられる問題種別
    2. 今回のプロジェクトと類似の案件で、過去に大きな手戻りが発生しているような不具合から考えられる問題種別
    3. 上記の問題種別について、どの部分をどういった観点からレビューするのかがわかるようにシナリオを作成する。 例:「アイテムアクセスのセキュリティの機能に漏れがないかどうかを調べるために、アイテムのセキュリティに関連する設計をチェックする。たとえクライアント側でのセキュリティチェックをすりぬけたデータがあっても、サーバー側で正しくチェックされていることを確認する。」 例:「各機能間で受け渡しされるデータに不整合がないかどうかを調べるために、CRUD図をチェックする。入力はされていないのに、読み込みされているデータや、入力のみで読み込まれないデータが無いことをチェックする。
  3. レビュアーは今回のプロジェクトの分野に詳しいか、レビューのスキルが高いメンバーを割り当てて、上記で作成したシナリオをそれぞれに割り当てます。一人のレビュアーには2~3個のシナリオを割り当てます。そうすることでレビュアーはそれぞれが違った箇所を精査することができます。
  4. ドキュメントの事前レビューを行う。レビュー会前に対象ドキュメントをレビュアーに配布して事前チェックを行う。 レビュアーはシナリオとチェックリストを元に事前レビューを行う。
  5. レビューの指摘事項にレビューアーが深刻度をつける。軽微なものはレビュー会でとりあげずメモを渡すようにする。 深刻度は後行程で大幅に工数がかかるものやトラブルになりそうなもの度

レビュー会

  1. 事前レビューでみつかった指摘事項のうち、深刻度の高いものから取り上げて議論する。
  2. 誤字脱字系や記票ルール系の間違いはレビュー会でとりあげない。(メモを書いて渡す。)
  3. グランドルールとして以下のルールを守ってもらう。
    • 個人攻撃をしない。あくまでも視点はドキュメントに絞る。
    • 議論が脱線したら、内容を新たな課題としてホワイトボードに記録して別の会議を設けることで本題に戻す。
  4. レビューで指摘した事項は指摘者が責任をもって解決するまでフォローする。

プロジェクト完了後の見直し

プロジェクトの完了時にテスト工程や稼働後に発生した不具合を洗い出して「見逃し問題リスト」を作成する。

※1 見逃し問題リスト 問題の混入工程や修正工数も付記

No. 見逃し問題 処置内容 発見工程 混入工程 修正工数
1 属性の異なる同意フィールド(商品番号)がありエラーとなった。 属性を同じに合わせ、修正後に単体試験からやり直した。 結合試験 設計 24H
2 登録画面で参照するマスターの設定画面が無かった。(笑) 要求仕様書からやり直した。 結合試験 要求仕様 50H
3 項目の桁数が多く画面からはみ出した。 項目の配置を変更した。 製造 設計 3H

こちらの記事も合わせてお読みください。 www.sutekina121.com

以上、「効率的な設計レビュー方法」でした。

【広告】

wi-fi アプリで無線LANの電波状況を確認して改善しよう

【広告】

無線LANが突然遅くなったり、LANがつながらなくなったりすることがある。

これは、近くにある他の無線LANと混線しているのが原因の場合がある。

無線LANには”チャネル”という1~13または14のチャネル番号のどれかを割り当てて使用しています。

複数のアクセスポイントが設置されている環境などはこのチャネルが重なって電波干渉をおこすことがあります。そういった場合には、使用する無線チャネル番号が干渉しないように変更します。

使用しているwifiの電波状況の調べ方

無線LANの混雑状況はwifi Analyzerというアプリで確認することができます。 このアプリはiOS、android、windowsそれぞれに同じようなアプリがあります。

アプリを起動すると下の図のようなグラフで電波の強弱と使用しているチャネルが表示されます。自分が使用しているチャネルと他のアクセスポイントのチャネルとが重なっている場合は電波干渉によりwifiのスピードが落ちている可能性がありますので、このグラフを参考にして無線ルーターのチャネルを変更します。

以上、「wi-fi アプリで無線LANの電波状況を確認して改善しよう」でした。

【広告】

格安SIMでスマホ料金を大幅に節約する方法

格安SIMスマホ料金を大幅に節約する方法

毎月のスマホ料金が結構高い。最近は音声通話はほとんどゼロで、SNSでのメッセージでのやり取りやLINEでの通話が普通の世界になった。そして、格安SIMで音声通話もできるようになった。こうなってくると格安SIMプロバイダに完全に切り替えてスマホ料金を大幅に節約したくなりますね。 そして、格安SIMでもDocomoLTE、3G回線を使っているので品質的には問題がないことも分かっています。

私の求める条件

私の場合は以下の条件を満たせばOKだと考えています。

(1)緊急時を考えるとやはり音声通話は確保しておきたい。

(2)通常は音声通話は使うことは無い。

(3)一日のデータ使用料は意外と少ない。(SNS、メール、ちょっとしたWeb検索)

(4)山や海に遊びに行くので通信できる範囲が広いと嬉しい。

そしてチョイスしたのは

私が今回選んだのは OCN モバイル ONEの1日110MBプラン。音声通話可能で月々1600円(税抜) 私の求める条件をきっちり満たしていると思う。

(1)緊急時を考えるとやはり音声通話は確保しておきたい。

音声通話可能。110、119など緊急電話も可能。

(2)通常は音声通話は使うことは無い。

音声通話料金は30秒で23円なのだがほとんど使わないので自分には許容範囲。

(3)一日のデータ使用料は意外と少ない。(SNS、メール、ちょっとしたWeb検索)

一日110MBを超えると速度が落ちるが、翌日になるとまた110MBまでは高速に戻る。

(4)山や海に遊びに行くので通信できる範囲が広いと嬉しい。

Docomoの回線を使用しているので通信可能範囲は広い。

OCN モバイル ONEは格安SIMの実績としても申し分ないし、設定も簡単。

MNPの場合の注意点

MNPで契約変更するときには、注意点があります。

(1)MNPで転出する際に、10000円(税抜)近い契約解除料金が徴収される場合があります。

これは、契約満了月とその翌月を選べば契約解除料の支払いは回避できます。 (携帯電話会社に問い合わせると教えてもらえます。)

(2)MNPの転出手続きに2~3000円(税抜)と移転先での事務手数料3000円(税抜)がかかります。

乗り換え費用の合計は以下の通り

(1)契約解除料有の場合 3000円(MNP転出)+9500円(契約解除料)+3000円(移転先事務)=15500円(税抜) (2)契約解除料無の場合 3000円(MNP転出)+3000円(移転先事務)=6000円(税抜)

これだけの初期費用を考慮して乗り換える必要がありますので、月々の支払の差額に加えてキッチリ計算してから乗り換えてくださいね!