ソフトウェア開発時の見積もりに関して
少し今回はインフラぽくない話を。
普段機会がないのですが、ソフトウェア開発における見積もり技法に関して
触れる機会があったので、その際の情報をまとめておく。
普段サーバ構築等しかしないので、実はとても新鮮という。。。だめだとは思いますが。
■見積もり技法
■類似法
過去の類似Ｐｒｊを参考にして見積もる方法。
ちゃんと類似のＰｒｊを参考にすれば、実績と見積もりの差が乖離はしにくい。
ただし、客観性が乏しい。
■積み上げ法
開発しなければならない成果物の構成要素を洗い出し、
それぞれの作成に必要な工数を積み上げる方法。
ソースコードの行数や、各工程の工数を足してくのがこれに該当。
■パラメトリックス法
必要工数を目的変数として、入力値に開発規模や特性をいれることで
数式的に算出する方法。
例としてSLIMとか。
今回は、定番である積み上げ法に関して。
■LOC(Lines of Code)
開発モジュールのステップ数を算出
一人当たりの生産性ステップ数/月で割り算してコスト・必要人数を算出。
ただしソースコードのカウントの仕方（コメント、ヘッダ含めるか）とかは事前に
どのようにカウントするか決めること。
また、人によりステップ数のカウントの仕方はことなると思うので、
そのあたりの統一も難しい。
当然、要件が未確定の段階ではソースコードの行数など正確にだすのは難しいので、
見積もり制度としても低くなることがよくある。
ＬＯＣ法はこのあたりがあいまいなので、規模尺度法の要件を満たしていない。
※規模尺度法・・・ＩＳＯがソフトウエアの規模の測定尺度のために策定
参考にソフトウエアの生産性は、1MMで1000ステップ前後と言われているとかどうとか。
参考：
http://monoist.atmarkit.co.jp/mn/articles/1108/23/news003.html
http://monoist.atmarkit.co.jp/mn/articles/1109/14/news011.html
■FP法
ＦＰ（ファンクションポイント）・・・仕様をベースにして、言語や設計方式に依存せず、
開発対象となるシステムの機能規模をＦＰという単位で計測する。
ＦＰはデータ要素をもとに計算するので、内部のロジックの複雑性は考慮していない。
なので数値計算プログラムなどには不向きでビジネス系のシステム向け。
また、ＦＰ法には複数の種類がある。
■IFPUG法
これが全部入りのフルバージョン。
システムの扱うデータ、入出力データ、参照データすべてが計算対象
■ＦＰ概算法
ＩＦＰＵＧの簡略版。
■ＦＰ試算法
最も簡易版。概算の見積もりの時はこの手法が利用される。
以下、ＦＰ試算法の計算方法をざっくりメモする。
ＦＰとはデータの種類・数から開発規模を推定している。
よって、対象システムのデータとファイルを決めれば見積もりが可能。
アルゴリズムとかは一切関係ない。
流れは下記の通り。
内部ファイルの数をカウントして、x35
外部インターフェースファイルの数をカウントして、x15
上記2つを合計したものが総ＦＰ数となる。
総ＦＰ数から使用する言語のステップ数に換算が可能。
参考：
http://monoist.atmarkit.co.jp/mn/articles/1110/13/news007.html
http://monoist.atmarkit.co.jp/mn/articles/1111/16/news008.html
■最後に
IPAがSEC BOOKSとして、事業成果をまとめています。
その中に、ソフトウェア開発データ白書というのがあるのですが、
様々なＰｒｊとの見積もり等、実績が載っているので参考にしてみるのがいいかと。
PythonでWMIの内部を覗く
Windowsといえば、ブラックボックスだのと言われることも多いかと思いますが、
その中でもとりわけ見えてこない項目としてWMIがあります。
なにせMS最大の秘密とも言われるようですので。
WMI(Windows Management Instrumention)の詳細な説明は下記のサイトに譲りますが、
WBEMのMS実装版で、Windowsの管理情報にアクセスして情報を取得したり
変更することが可能なインターフェイスを提供してくれます。
Windows Management Instrumentation (WMI) の概要
WMI スクリプト入門 : 第 1 部
突き詰めると、WMIを通してWindowsの様々な情報を取得することが可能であり、
管理者としてはお世話になることもあるかと思います。
ですが、WMIでどのような情報を取得できるのか？
というところが漠然としていたので、
Pythonで覗いてみましたというのが今回のお題です。
具体的に今回やったことは、
PythonからWMIを叩いて取得したオブジェクトの中身を見ることで、
どのような情報を取得できるのかを確認したところまでです。
Pythonには様々なモジュールがありますが、下記を利用しています。
下記のようにコマンドを発行することで、WMIインターフェイスへの入り口を作れます。
import wmi c = wmi.WMI()
この「c」の中にWMIの情報が詰まっているのですが、
それを覗くのにPythonのinspectモジュールを利用してみました。
これは、モジュール内のクラスの一覧などを出力してくれるモジュールです。
これにより「c」の内部を覗いてみます。
inspectモジュールを使って、モジュール内のクラス一覧を得る - Mattari Diary
import inspect inspect.getmembers(c)
記載しませんが、大量に出力されます。
_classesの部分が、我々としては大事です。
どのclassの値を参照すれば、我々が望んでいる情報を取得できるかが決まりますので。
例えば、「Win32_Service」というclassがあるかと思います。
このclassからどんな情報が取れるのかと気になったら、
更にこのclassの内部を検索してやればよいのです。
inspect.getmembers(c.win32_service)
こうやっていけば、どの情報を取得できそうかあたりがつけられるかと思います。
このレイヤーまで掘れば、変数名からどのような情報が得られそうかというのが想像できます。
参考:
WMI Fun !! 〜 WMI (Windows Management Instrumentation) に興味がある方・システム管理者必見！ 〜
https://msdn.microsoft.com/en-us/library/windows/desktop/aa394582(v=vs.85).aspx
この本が気になる。WMIというとあんまり情報がなく。。
SphinxでWord(docx)文書を出力してみた
自分はあまり、Office製品が好きではありません。
(Office365契約しているけど。。。）
便利なのですよ。便利なのだけど、お節介が過ぎるところがあるので。MSのOffice製品は。
そこで今回は依然から気になっていたSphinxを使ってみることにしました。
特に、Sphinxからdocxを吐き出せないかと試していたのですが、はまりポイントがあったのでご紹介。
環境は以下の通り。
・Python 2.7 (32bit)
・Sphinx 1.3.5
・sphinx-docxbuilder(コミット 83a8d13 2012-06-05)
haraisao / sphinx-docxbuilder — Bitbucket
Sphinxでdocxを出力する際に利用するモジュールは、
「sphinx-docxbuilder」というものを利用しているのですが、
見ての通り、更新日が4年前になります。
自分の環境では、コンパイル中にエラーが出力されました。
tree = inline_all_toctrees(self, set(), master, tree, darkgreen) TypeError: inline_all_toctrees() takes exactly 6 arguments (5 given)
明らかに関数の型がおかしいとのことで、
ちょっと調べてみると、Sphinxが提供している
「inline_all_toctrees」関数の型が変更されているのが原因に見えます。
取り急ぎ、下記のように変更すればコンパイルは通ります。
sphinx-docbuilder/builder.py 60行目
・Before
tree = inline_all_toctrees(self, set(), master, tree, darkgreen)
・After
tree = inline_all_toctrees(self, set(), master, tree, darkgreen, [])
参考:
futurismo.biz
【Office365】Office365を試す(ディレクトリ同期で同期される属性値)
最近、Office365を契約してみました。
というのも下記のアドベンドカレンダーの様々な記事を見ることで興味が湧いたこと、
個人でもビジネスプランを契約できるということで試して見ようと思い。
Office365を普通に利用するだけなら契約するだけで終わりですが、
エンジニアとしてはただ利用するだけでは楽しくありません。
せっかくビジネスプランを個人でも契約できるので、
エンタープライズ向けの機能も試してみたくなります。
ということで、ローカルADとのディレクトリ同期です。
ADとOffice365のディレクトリ同期ですが、
様々なサイト・blogで構築手順等も紹介されています。
が、古い情報もあったり情報が錯綜している部分もある気がします。
ひと昔前ですと、Dirsyncどうディレクトリ同期ツールを利用していましたが、
昨年にAzure AD Connectがリリースされており、今後はこのツールが基本となるかと思います。
MSが公開している自習書も2012年のもので、Dirsyncが前提になっています。
ですので、2016年2月時点で自分が構築した際の流れを一度まとめてみようと思います。
(構築手順まとめは、後日upします。。)
今回の記事は、ディレクトリ同期で同期される属性値に関してです。
Office365ではどのような属性値を同期しているのかなというのがセキュリティ的にも気になりました。
一応、下記サイトに公開されているみたいで、
「UserPrincipalName」、「mail」などそうだよねというものも含め結構あります。
https://support.microsoft.com/ja-jp/kb/2256198
ページ下記にも記載がありますが、下記情報を保持するユーザオブジェクトは同期されないみたいです。
パッと見る限り、ADのシステム系ユーザなど明らかに不要そうなものは除外してくれているようですね。
mailNickName が "SystemMailbox{" で始まる
「mailNickName が "CAS_" で始まる」 および mailNickName が "{" を含む」
「sAMAccountName が "CAS_" で始まる」 および 「sAMAccountName に "}" が含まれる」
sAMAccountName が "SUPPORT_388945a0"
sAMAccountName が "MSOL_AD_Sync"
sAMAccountName が存在しない
isCriticalSystemObject が存在する
msExchRecipientTypeDetails == (0x1000 OR 0x2000 OR 0x4000 OR 0x400000 OR 0x800000 OR 0x1000000 OR 0x20000000)
各ブラウザ(IE,Google Chrome,Firefox)でのCookie確認・編集の方法
今回は、各種ブラウザでのCookieの内容確認の方法、編集の方法をまとめておく。
■IE
■方法1:デフォルトの機能でCookieデータをエクスポート・インポート
IEにはデフォルトでCookieの内容をエクスポート・インポートする機能がある。
「Alt+F」でファイルメニューを表示後、「インポートおよびエクスポート」を選択すればよい。
対象に「Cookies」を選択すれば、テキストファイルとして内容を取得可能。
また、変更したテキストファイルを同様にインポートも可能。
■方法2:専用のアプリケーションを利用
専用のアプリケーションを利用して、IEのCookieを確認できる。
おすすめは、「IECookiesView」。起動して確認と編集が簡単に可能。
www.nirsoft.net
■Google Chrome
■方法1:拡張機能「Edit This Cookie」を利用
この拡張機能を入れれば、訪問中のサイトのCookieを表示・編集可能
chrome.google.com
■方法2:Cookieファイルを直接参照
Firefoxでもだが、CookieファイルをSQLite形式で保存している。
よって、SQLiteのDBを操作できるアプリケーションから参照可能。
自分は、下記を利用している。
SQLite Studio
SQLiteStudio
参考:SQLiteの開発ツール
SQLiteの開発ツール - 流れ着いたら。。。
■Firefox
■方法1:アドオン「Firebug」を利用
非常に有名なアドオン「Firebug」でもCookieを参照可能
addons.mozilla.org
■方法2:Cookieファイルを直接参照
これはGoogle Chromeと同様。
セキュリティが強化されたWindows FW 「接続セキュリティの規則」について
WindwosのFW機能の内、接続セキュリティの規則に関して簡単なメモ。
WindowsのFW機能は、たくさんあってわかりずらい。
WindwosのFW(正確には、セキュリティが強化されたWindows FW)には
「接続セキュリティの規則」というものが存在する。
通常FWとは、その機器上で単体で稼働して、
届いた通信に対してポート指定、パケットの内容などで通信許可の判断を下す。
※セキュリティが強化されたWindows FWでは「受信規則」、「送信規則」に当たる
「接続セキュリティの規則」は少し異なり、通信相手と、自分自身それぞれで
相応の許可設定が入っている必要がある。
本機能は、通信開始前にお互いのPCを認証して、IPsecで暗号化した通信を行うことができる。
「接続セキュリティの規則」では、規則の種類が下記4つから選択できる。
・分類 ・・・ドメイン参加のコンピュータのみ接続可能
・認証の除外・・・指定したPCを認証対象から除外
・サーバ間 ・・・指定したPC間の接続を認証
・トンネル ・・・外部ネットワークを介する、PC間の接続を認証
・カスタム ・・・カスタムの規則を作成可能
参考:
接続セキュリティの規則の作成
そんなにたくさんあるFWの規則だが、どのような順番で適用されるのかに関しては、
TecNetに記載があった。
【未確定】フラッシュドライブ利用時のフォーマット形式はexFatにすべき？
WindowsでUSBメモリや、SDカードを利用する際のフォーマットに関して。
既定では「exFat」になっているはず。
調べてみると、いろいろ記事がある通りUSBメモリに向いているのはexFatみたい。
特に、速度がNTFSと比較するといいらしいのだけれども、
実際に試してみるとそれほどの有意な差はなかった。
ドライバも最新なはずだしなー。
USBメモリーを高速書き込みフォーマットに変換（exFATに変換）
USBメモリのフォーマットと速度 | いまと違うところへ
利用したメモリは、Team社製の「TFXC128UHS01TG」というモデル。
余談だけど、TSUKUMOで4,600円くらいで128GBを購入できた。
これをSurface Pro3のmicroSDカードスロットに刺して利用している。
今回はこの1モデルだけの検証になるが、下記のようにNTFSのほうが若干良いくらい。
他にも機会があれば試してみようかな。
■NTFS
