掲示板お問い合わせランダムジャンプ



この広告は30日以上更新がないブログに表示されております。 新しい記事を書くことで広告を消すことができます。

Google広告

2012年08月30日
やはり企業ユーザーは"Microsoft Surface"を無視できない!
やはり企業ユーザーは"Microsoft Surface"を無視できない!

デスクトップ、ノート、タブレット、スマホ、仮想化デスクトップ、スカイドライブ、etc。相互運用性、シームレス運用、既存の情報資産の利用を考慮すると、マイクロソフトしか残らないから。

マイクロソフト純正タブレットの評価は多分このようなことで落ち着くだろう。

.*.
[ 投稿者:ISMSNEWS at 18:06 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ビッグ・データ
ビッグ・データ

普通のデータベースでは処理できないくらい大きいサイズのデータ。正規化されたデータと非正規ののデータが混在することもある。なかなか手に負えないデータ。それが少しずつ手に負えるようになってきて俄かにビッグデータの言葉があふれ出した。

.*.

ロングテール・ビジネスもビッグデータの一つではないかな。今まで諦めていた雑多なデータの再評価が可能になった。そういうことだろう。

.*.
[ 投稿者:ISMSNEWS at 18:03 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

Virtual Desktop Infrastructure
Virtual Desktop Infrastructure

VDI

これは何でしょうか?

発展したシンクライアントのコンセプトみたいですね。

デスクトップというかウインドウズは端末上にはダウンロードされない。単なる表示機に過ぎないのでしょうか。

となると通信俯瞰が大変ですね。

.*.
[ 投稿者:ISMSNEWS at 18:00 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

クラウドをビジネスに利用し始めた企業
クラウドをビジネスに利用し始めた企業

クラウドは負荷対応の弾力的運用という側面が評価されている。ミニマムのリソースで最大の効用を得ようというものだが、ぎりぎりで設計するとNTTの通信ダウン事故みたいに何度も失敗する。やはり余裕を持っていないと安心できない訳です。

クラウドのもう1つの側面はインターネット(イントラネットでも)の利用です。企業グループ内や、ビジネスパートナー、あるいはユーザー〜顧客との情報連携がしやすいということです。

これって必ずしもクラウドであることを要求するものでは有りません。ただ、不確定のニーズに対する備えとしてクラウドは取り敢えず有効であろうとの理解は得られます。

.*.

一方で、クラウドは幻滅期に入ったとする観測もある。

実際に、そんな余裕で幾つもサーバーを動かしていなければクラウドに変えるメリットは出ない。頻繁に設備増強に追い込まれるような急激な変化は、クラウドにしても容易ではあるまい。

クラウドにすることで、一部のトラブルが全体に波及するリスクもある。途上技術。

.*.
[ 投稿者:ISMSNEWS at 17:59 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ディザスタリカバリ
ディザスタリカバリ

DR:disaster recovery

災害復旧。南海トラフ広域地震の想定シナリオが発表されてしまったので、企業は無視できなくなった。つまり、今後の災害復旧プランはこの震災を想定に入れざるを得なくなった。大変なことです。

ISMSの事業継続管理も当然、この想定に引っ張られることになる。

取り敢えずは、社会インフラを担う企業の取り組みを診てからということで、待ちの姿勢になるでしょう。

.*.
[ 投稿者:ISMSNEWS at 17:57 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ソフトウエア開発における重要な活動
ソフトウエア開発における重要な活動

品質計画
製品ライフサイクル管理
開発標準に基づく開発
構成管理
差別化能力と訓練
機密管理
.*.
[ 投稿者:ISMSNEWS at 17:54 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

Service Level Agreements
Service Level Agreements

所謂SLA(エスエルエー)です。あまりしっかりしたSLAにはお目にかかれません。独立系のITサービス事業会社なら立派なSLAを持っているかもしれません。

それでも、保障《未達成はペナルティ)と努力目標(ペナルティなし)に分けて、妥協の産物になっているでしょうか。

.*.

会社内の情報システム部門の場合は尚更明確なSLAを設定しません。これはいけませんね。CIOとかをおく場合はしっかりこの辺は縛りましょう。

.*.
[ 投稿者:ISMSNEWS at 17:51 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

安全なウェブサイトの作り方
安全なウェブサイトの作り方

IPA(ここも天下り独立法人ですか?)がこのようなサイトを開いている。企業のWEB担当者は一応読んでおかないと説明責任を負えない。

http://www.ipa.go.jp/security/vuln/websecurity.html

.*.
[ 投稿者:ISMSNEWS at 17:47 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ISO/IEC 15408
ISO/IEC 15408

JIS X 5070:セキュリティ技術-情報技術セキュリティの評価基準

これは確か、商品自体の情報セキュリティ達成基準でしたよね。特に通信機器などでは重要とか。ソフトウエアでも関連するところは大事かも。

.*.
[ 投稿者:ISMSNEWS at 17:45 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

IT Service Management
IT Service Management

これは確か、規格がありました。

.*.

ISO/IEC 20000-1

.*.

ITIL (アイティル)

http://www.itsmf-japan.org/itil/

.*.

ITサービスが社会に与える影響が大きいことを踏まえ、より安定的にITサービスが提供されるように規格を定めている。と言うのが建前。ISMSでも全然問題ないが、議論が寄り適切にフォーカスされるためには、こっちの規格は有用。認証取得と勘違いしないこと。認証はISMSで充分。内容的に参照すべきと言うことです。


「サービスレベル管理」
「サービス記録管理」
「サービス継続性・可用性管理」
「サービス資源管理」
「容量能力管理」
「情報セキュリティ管理」
「顧客関係管理」
「供給者管理」
「インシデント管理」
「問題管理」
「構成管理」
「変更管理」
「リリース管理」

.*.
[ 投稿者:ISMSNEWS at 17:42 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

構成およびリリース管理
構成およびリリース管理

ここでの構成及びリリース管理は開発中の構成管理と異なり、市場に出ている商品の構成管理である。従って、関連する多くのスタッフ、協力会社、ユーザーなどと必要な範囲で共有できなければいけない。

再現性も保障されること。普通は怖いからオブジェクトコードのコピーを持ちます。再構成なんて最後の最後の切り札です。


.*.

リリースノートとは:

何を変更したのか。その他必要なことを記載。

.*.
[ 投稿者:ISMSNEWS at 17:39 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ソフトウェアライフサイクル
ソフトウェアライフサイクル


ソフトウェアの企画・構想から設計、開発、導入、運用、保守、破棄に到るまでの工程全体のこと。普通の商品・サービスの「ライフサイクルマネジメント」と基本的に同じ。

最初から捨てるときのことを考えて開発しなさいと。今では常識?。ソフトなら運用性、保守性を考慮して開発する。

情報セキュリティまで考慮する昨今は廃棄・サービス停止の時のことまで考慮することが求められる。

.*.

ISO/IEC 12207:2008(JIS X 0160:2012)

JIS X 0160:2012 ソフトウェアライフサイクルプロセス

6 システムライフサイクルプロセス 20

6.1 合意プロセス 20
6.2 組織のプロジェクトイネーブリングプロセス 27
6.3 プロジェクトプロセス 32
6.4 テクニカルプロセス 42

7 ソフトウェア固有プロセス 56

7.1 ソフトウェア実装プロセス 56
7.2 ソフトウェア支援プロセス

.*.

こういう標準が出来たんだね。今更もう間に合わないというか、役に立つことは無いだろうけど。

概ね50ページぐらいだろうからざっと読めばどういう機能配置が必要か分りそうだ。意識・無意識のうちにやっていることが大半だろう。

.*.
[ 投稿者:ISMSNEWS at 17:38 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

プロジェクトマネジメント
プロジェクトマネジメント

複数の人、部署、会社が共通の目的を達成するために協業するときは、何処にでも存在する役割。プロセス。権限を持たされた専門の部隊を置くケースから、兼務兼業でプロマネの一部を負担するケースまで、組織の状況により様々です。

データを集めて責任者に報告するだけのもの(事務屋の事務局タイプ)もある。

.*.
[ 投稿者:ISMSNEWS at 17:37 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ドキュメンテーション
ドキュメンテーション

ソフトウエア開発でいうドキュメンテーションとは、システムやソフトウエアと一緒に納品する文書類の作成のこと。或いはプロジェクト完了の要件として整備する文書類の作成のこと。

開発者サイドのドキュメント類は構成管理の一環として管理される。契約によっては、途中の変更過程全ての提出が求められる。というか、指定の構成管理ツールの利用が条件になっている。

一般的な場合、内容は、利用者マニュアル。取扱説明書。操作手順書。ヘルプ&トレーニングなど。

品質レベルを証明する記録類を整理したものもドキュメント類に入れるケースもある。契約による。

.*.
[ 投稿者:ISMSNEWS at 17:36 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

不具合管理
不具合管理

構成管理、テスト管理、との関連が強い。

テスト自体は問題を発見する手段でテスト担当者は減員分析とか改修とかには関わらない。開発側の仕事かといえば、問題を主リンクされる懸念もあるので、また別のチームなり部隊が両者と連携しながら担当する。

もぐらたたきの防止

回帰テスト(リグレッションテスト)はあるバグをフィックスしたときに、別の問題が生じていないか確認するテスト。バグの存在を前提に関連するモジュールが動いている場合は、バグが修復されるとそのモジュールは正しく動作しない。下手な作り込みをすると、バグが連鎖してもぐらたたきになる。

.*.

1件1件の不具合に対する確実な修復という視点の管理業務に加え、統計的な分析も必要。これらはテスト計画への反映されるものとなる。分析では、品質に問題の有る領域(ファンクション、モジュール、レイヤー、インタフェースなど)を特定する。

.*.
[ 投稿者:ISMSNEWS at 17:35 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

メトリクス
メトリクス

ソフトウエアメトリックスとはソフトウエア品質指標と思えばいい。

一番ポピュラーなのはテスト時間当たりの不具合発生件数。他にも有名な指標は沢山あります。コードレビューで発見できる不具合がコード行数当たり何個か。仕様変更数。変更修正に要する時間。性能。コード量〜プログラム規模。など。

メトリクス測定ツール

規模によっては測定ツールも必要になるかもしれない。測定ツールが悪さをするかも知れないので、嫌う人もいる。多分。開発環境の一環として提供される。

単に、メトリックスといえば只の指標、尺度。

尺度評価は、右上がり尺度、右下がり尺度、中央値尺度などいくつか考えられるが、単なるデータ収集でしかないもの(因果関係の不明確なもの)もあるので、惑わされないことです。

CMMIをメトリクスにするのはピンとこない。開発プロセスの品質レベルには違いないが、品質のばらつきとか、達成状況を計測する視点のものではない。

Capability Maturity Model Integration

.*.
[ 投稿者:ISMSNEWS at 17:34 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

テスト
テスト

ホワイトボックステストとブラックボックステスト

内部構造・内部仕様などを踏まえて行うのがホワイト、イン・アウトだけに着目するのがブラック。言葉が面白いだけで、詰まらない。前者は開発者視点のサイドのテスト、後者は利用者視点のテストと理解した方がわかりやすい。このカテゴリー分けは何も新しいものをもたらさない。

<開発部門>
単体試験
組み合わせ試験
総合試験

<第3者部門>
αテスト

<利用者側>
受け入れてスト
βテスト

テストフェーズをどのように区分するかは組織の決め事。

.*.

テスト環境の管理:
テストアカウント管理
テストデータ管理

.*.

不具合管理=これは構成管理の支援も必要。

単体・組み合わせで、スペックの不備まで引っ張り出しておかないと大変。総合試験より後のフェーズで問題が出ても、相性の問題、タイミングの問題などが入り込むと非常に厄介。

.*.
[ 投稿者:ISMSNEWS at 17:33 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

構成管理
構成管理

バージョン管理、リリース管理、インテグレーション管理、ビルド管理、、、。

.*.

地味な仕事だから、間に合わせ人材を入れて失敗することがある。

専用ツールは高い。

.*.

今は、開発プロセス全体から、ライフサイクル全体までを管理する役割を担う。とても重要。

.*.
[ 投稿者:ISMSNEWS at 17:31 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

開発環境
開発環境

各ベンダーが提供している。一度ベンダーが決まると変えたくなくなる要因。独立系の環境を利用したくなる。ハードウエアメーカーに縛られたくない。

.*.

Eclipse

Visual Studio, NET Framework

.*.
[ 投稿者:ISMSNEWS at 17:30 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

オブジェクト指向分析設計
オブジェクト指向分析設計


UML:聞いたことあるね。モデル表記法の標準仕様。

Unified Modeling Language

.*.
[ 投稿者:ISMSNEWS at 17:29 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

構造化分析設計技法
構造化分析設計技法

問題をクリアにするための方法論ですから、ソフトウエア開発に限りません。

「状態遷移図」とか「データフローダイアグラム」などは古くから利用されています。

E-Rモデル:

E:Entity:実態-R:Relation:関係モデリングは主にデータベース設計に利用される。

.*.
[ 投稿者:ISMSNEWS at 17:28 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

要件定義と要求分析
要件定義と要求分析

禅問答みたいな文字の並び。企業文化、技術者の美学の違いの程度と理解しておきます。別物とすると返って混乱します。

.*.

この用語においては実際には何をやるかを明確にしているかどうかが大事ですね。

.*.

「要件定義書」が取り敢えずの成果物。要件定義書策定マニュアルとか手順書が開発部門標準として用意されています。

QMSと同じく、最新版管理、周知管理が問題になります。

.*.
[ 投稿者:ISMSNEWS at 17:26 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ソフトウエア開発の方法論
ソフトウエア開発の方法論

◆ ウォーターフォール型

古典的な、しかし、今も主流のウォーターフォール型。大型プロジェクトはこの形になる。

矛盾する概念ではないが設計技法として:
構造化技法。プロセス分析技法の応用。どちらが応用したのか分りませんが。
オブジェクト指向型開発技法。

◆ プロトタイプ型

これも、必ずしも矛盾する概念ではないが、プロトタイプ型。アイデアの骨子を先ずモデル的に作り、主にユーザー視点から検証しながら要求仕様を確立しながら作り込んでいく。

.*.

プロジェクト全体の進め方はウォーターフォール型に沿い、個別のところの開発はそれぞれに適した手法が選択される。

.*.

◆ アジャイル型

アジャイルSW開発は、様々な変化への対応を柔軟に出来ることを意図して集積した方法論の総体。

品質の確保とスピードアップは常に課題であるわけで、アジャイルと名前を付けたら、そう都合よくものが運ぶわけではない。

.*.
[ 投稿者:ISMSNEWS at 17:25 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2012年08月29日
プログラミング言語
プログラミング言語

処理手順を記述するのがプログラム言語。どの装置、どの分野で利用するかによって様々です。

技術進化に合わせて言語も進化あるいは最適化されるため、ハードウエア環境の違いへの対応もあってプログラミング言語の数はきりがない。

.*.

http://www.mwsoft.jp/column/program_top10.html
素人が見ても分らないが雰囲気は伝わって来る。
Scala
JavaScript
Ruby
Perl
Objective-C
C#
Python
PHP(PHP(Hypertext Pre-processer))
C++
C
Java
Smalltalk
Assembly language
FORTRAN
COBOL
LISP
PL/1
Visual Basic
BASIC
.*.
HTML
XML
SGML
.*.

何がISMS?

ソース管理?
力量管理?
環境管理?
構成管理?
世代管理?

.*.
[ 投稿者:ISMSNEWS at 17:23 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ソフトウエア産業とは?
ソフトウエア産業とは?

これを如何に括るかは至難の技。それはソフトウエアの無い産業など一つも無いからです。

総務省統計局の分類は何か決めておかないと不便することを考慮して作ったものですが、一般的には殆ど価値が有りません。言い過ぎ?。組織が業態を名乗るときには必要でしょうが、外販しないで内部プロセスとして持つものも少なくない。情報部門を分離して別会社にしたら情報通信業となるが、会社グループとしては何も変わっていない。

http://www.stat.go.jp/index/seido/sangyo/19-3-1.htm

http://www.stat.go.jp/index/seido/sangyo/pdf/19san3g.pdf


大分類 G 情報通信業
中分類 37  通信業
中分類 38  放送業
中分類 39  情報サービス業
中分類 40  インターネット附随サービス業
中分類 41  映像・音声・文字情報制作業


391  ソフトウェア業
3911  受託開発ソフトウェア業
3912  組込みソフトウェア業
3913  パッケージソフトウェア業
3914  ゲームソフトウェア業

.*.

ISMSの勘所

人的リソース集約産業。知的産業といえば格好いいが人件費集約産業。

知的財産、人的資源、委託契約の関連は当然として、サービス/サポートフェーズまで考慮したライフサイクル管理の側面を見失わないことです。特に、弱小企業でも個人の力量に頼って重要なパートナーとなりますが、永続性が無いリスクをどのように管理しているかがポイントとなります。

.*.
[ 投稿者:ISMSNEWS at 17:22 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

ソフトウエア開発プロセスにおけるコンプライアンス
ソフトウエア開発プロセスにおけるコンプライアンス

ウォーターフォール型は、普通の一般的な商品開発・技術開発と同じ流れ。ライフサイクルで見れば似たような発想で理解できる。

コンプライアンス要求

<ソフトウエア開発プロセスに特徴的な要求>

「知的財産基本法」
「著作権法」
「特許法」

知的財産権(=知的所有権):特許権、実用新案権、育成者権、意匠権、著作権、 商標権その他の知的財産に関して法令により定められた権利又は法律上保護される利益に係る権利をいう。

ソフトウエア(成果物)に関するもの:プログラム、デザイン、アイデア。

<一般のプロセスと共通する要求>

その他のコンプライアンス要求は一般のプロセスと同様のもの。

とは言え、ソフトウエア業界では人海戦術がベースにあるため、派遣労働、業務委託に関する法令順守は重要なものである。公平な採用など。

従業員管理・労務管理に関する法令:
「労働基準法」
「労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律」(派遣法)
「個人情報保護法」
委託契約に関する法令:
「下請代金支払遅延等防止法」(下請法)
「役務の委託取引における優越的地位の濫用に関する独占禁止法上の指針」
防災防犯関連
「災害対策基本法」
「消防法」
「行政機関等による監視カメラの設置等の適正化に関する法律案」《これはまだ準備中!》
セキュリティ関連:
刑法
著作権法
電気通信事業法
電子署名及び認証業務に関する法律
電子署名に係る地方公共団体の認証業務に関する法律
電波法
特定電子メールの送信の適正化等に関する法律
不正アクセス行為の禁止等に関する法律
有線電気通信法
*参考* http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/kiso/k05.htm

<ISMS管理>

本社部門(法務、人事、総務など)が絡む場合はコンプライアンスに穴が開くケースは少ないが、部門に任されている場合は、本社からのマニュアルで作業するため、穴が開くケースが出る。本社(各機能統括部門)の常識が部署、特に別授業所、別地域に展開している先では要注意。

特に、部門による派遣従業員の採用、業務委託のケース。

.*.
[ 投稿者:ISMSNEWS at 17:21 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

2012年08月17日
LRM
LRM

コンサル会社の名前。何の略かは知らない。

http://www.iso27001.jp/




取得100%保障と記載されている。100%実績の記載もある。何かしら引っかかる表現です。勢い余ってかも知れません。









みんな若い。



.*.
[ 投稿者:ISMSNEWS at 17:19 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

株式会社クオーレ
株式会社クオーレ

http://www.cuore.jp/index.html

ISMSコンサルティング

手広く仕事をしている印象だ。ISMSはほんの一部。そのためか会社の方向性が今一分かりにくい。社長の挨拶は、しかし、クリアで好感が持てる。

.*.
[ 投稿者:ISMSNEWS at 17:17 | ISMS四方山話 | コメント(0) | トラックバック(0) ]

可用性の議論2
可用性の議論2

可用性の問題を如何に単純化するか

(1)アクセススピードはプロセスの要求によって決定される。一律に何時間、何日とやるのは意味が無い。
(2)最悪の状態をイメージしてみる。漏洩していないし、改竄されていないし、紛失していない(=アクセスできる)。

「アクセスできない。紛失の可能性がある。倉庫全部を探さないと分らない。棚卸しが必要。」

もしこうなったらどれくらいの損害が出るのか。アベイラビリティの喪失による損害額。この金額レベルを、例えば3段階で表現する。

プロセスの要求が当日中となっていて、当日中が実現できない場合、翌日にはアクセスできるかもしれないし、永久にアクセスできないかも知れないし、1週間以内とか色々なバリエーションを発想できる。でもこれは意味のない議論です。

問題はアクセス性が管理されているかどうかの二択問題なんですね。管理されていない場合の最大の損害額は紛失(漏洩では有りません)〜アクセス不可を前提に策定します。

.*.
[ 投稿者:ISMSNEWS at 17:15 | ISMS四方山話 | コメント(0) | トラックバック(0) ]