ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

マイナンバーの広報用ロゴマーク

2014-05-31 13:14:50 | Weblog
ここ

マイナンバーの広報用ロゴマーク
http://www.cas.go.jp/jp/seisaku/bangoseido/logo.html


の「マイナンバーロゴマーク利用ガイドライン(PDF:976KB)
にあるんだけど、「マイナンバーロゴマーク利用規約」に書かれているつかっていい人に該当せず、いま書類も出してないので、ロゴマークを、文章で説明します。



うさぎさんの目が1、1、左手に赤で1


です(意味まったく通じないと思う。たぶん、想定の範囲外。気になる人は、以下のPDFを見てね)


マイナンバーロゴマーク利用ガイドライン(PDF:976KB)
http://www.cas.go.jp/jp/seisaku/bangoseido/pdf/logo-guideline.pdf


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

宇宙ロボットエレベーター ロボット競技会とか(教育ITソリューションEXPOの感想)

2014-05-30 16:07:14 | Weblog
そうそう、書き忘れていた。先週(5月23日)、教育ITソリューションEXPOに行って来た。

全体的な感想は、いつもやっているような内容が、小規模のなってやっている感じ。つまり、コンテンツのお話。LMS、電子黒板・・・いろいろあるんだけど、いままでみたいに、「どっか~んと何」というのではなく、小規模にいろいろあるかんじ・・・

新しいところでは、富士ゼロックスの反転学習、AmazonAWSを使ってLMSとかもあったり、Tincan(SCORMの次といわれる)の展示もあったり、 小型ヒューマノイドロボットのNAOによる学習もあったけど、全部小さい展示。

そうそう、ロボットというと、LEGO.ちゃんと出てて、いまそのパンフレットを見てる。
LEGO Mindstorms Education EV3はもちろん、
Story Starterっていうのがあるらしい
それと、

第二回 宇宙ロボットエレベーターロボット競技会
http://space-elevator.narika.jp/

のチラシもあった。11月23日開催らしいが、
宇宙エレベーターワークショップが6月15日レゴジャパン本社であるらしい
宇宙エレベーター実験キットというのが、レゴであるらしいよ(そのチラシの裏に書いてある)

それと、GAKUENというのが、大きく出てた。

こんなかんじかな・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アシュアランスケースとその表記法のGSNのチュートリアルを聞いてきた

2014-05-30 13:19:34 | Weblog
KBSEのチュートリアル、
アシュアランスケース演習   ~ ツールを使って書いてみよう!! ~
http://www.ieice.org/~kbse/tutorial/tutorial-20140530a.html
を聞いてきた。その内容をメモメモ




アシュアランスケースの必要性
リスク:障害、怪我→どのくらいの確率で起こるか

1.はじめに
・マクドナルドコーヒー訴訟
 コーヒーをこぼしてやけど→訴訟→勝訴

1.アシュアランスケースの必要性
 リスクの構造と
 それに対する安全性の主張の必要性
 主張する際のポイント

アシュアランスケース

(安全性の)主張
  ↑
  説明←アシュアランスケース(主張するための手段)
  ↑
 エビデンス

欧米では、アシュアランスケースは安全分野で

1.0事例から得られる示唆
・マグドナルドコーヒー訴訟の事例を考えると
事前準備
  ・発生割合
  ・温度などに対するリスク
プロセス
  ・提供する仕組みに不備
  ・クレームの発生しないシステム
  ・クレームの対応
その後
  ・どのように対応(発生防止)

・トヨタ 大規模リコール(プリウス)
 何も問題はないか?
  ・電子スロットに欠陥がないことを証明する
    →難癖をつける人に証明できるか?

訴訟だけでなく、お客さんの不安に証明できるか?

1.1 リスク発生条件と対処法
リスク
  前提条件が成立:システムが正常運用
   ↓(そうでない)
  想定している例外条件:想定された事項を実行
   ↓(そうでない)
  想定していない:運用プロセスでシステム機能回復

リスクの対処方法
1.リスクの識別
   網羅的、
2.リスクの対処策の考案・選択
   適切な対処
3.リスク対策の実施確認
   証拠が必要
それでも、想定外のトラブルがおこる。そのとき運用で対応

1.2 システムリスク管理のための開発活動
・V字開発
  要件定義         システム試験
   外部設計      結合試験
    内部設計   単体試験
      プログラミング

想定できることはV字で開発できる
想定外:運用保守工程

1.3 システムリスクの対応・主張方法
・イプシロンロケット 打ち上げ中止
  地上装置
  搭載検査機
   →0.07秒はやかった

確認問題 ワークシート
  問題
  理由
  対処

1.3 システムリスクの対応・主張方法
 主張
 |-前提
 |-説明
 証拠

Toulminの論証構造
  →クリティカルシンキング

2.2 アシュアランスケースの表記法
  GSN
  CAE
  ARM

・astah GSNで作図

・木構造になっている
 説明をいれて主張

・主張は最終的にundevelopか証拠で終わる

・→に2つ(astahは自動的に色を変える)

主張:S+Vの命題(命令や挨拶でない)
説明:分割するときの議論の仕方
証拠:ドキュメント

前提:システムの運用環境、定義など
・ディペンダビリティ→たよりがいがある
・語彙の定義

ゴールの分割
  システムの構成要素ごとに分解
  機能による分解
  属性構造による分類

間違いやすいポイント
・説明戦略とゴールと取り違い
・主張が実行文になっている

Q;構成要素に分割する→独立を保障しないといけないのでは?
A;→独立でない場合、相互作用のゴールを入れる

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

プロジェクトマネジメントのリスク管理法にケプナー・トリゴー法があるのは、わかった

2014-05-29 16:23:01 | Weblog
昨日、トップエスイーの

サイエンスに基づくプロジェクトマネジメント・コース
http://topse.or.jp/2014/04/2196

2日目
プロジェクトのリスクマネジメント法と意思決定法
に行って来た。そのときのメモメモ




Kepner-Tregoe法の改良

PMBOK-プロジェクトマネジメント、フレームワーク、資格あり

PMBOK:リスクマネジメント6つのプロセス
(1)リスクマネジメント計画
(2)リスク識別
(3)定性的リスク分析
(4)定量的リスク分析
(5)リスク対応計画
(5)リスク監視

今回は(2)と(3)

リスク洗い出し

木野先生(IBM→筑波)
 識者へのインタビュー
 ブレーンストーミング
 チェックリスト

PrestonG Smithら
・スケジュール
・開発プロセス
・失敗要因
・助言リスト

ここでは、チェックリスト法のひとつ
・ケプナー・トリゴー法を改良

・ケプナー・トリゴー法
心理学者:ちゃーるずけぷなー
社会学者:べんじゃみんとりごー
4つの手順
  ・問題分析
  ・決定分析
  ・潜在的問題分析
  ・状況分析
ケプナー・トリゴー法の潜在的問題分析
 →セミナーやっている会社:1週間くらいで30万
(1)目標の明確化
(2)計画の確認
(3)重大領域の確認
(4)重大領域に沿ったリスクの洗い出し
(5)リスクの洗い出しに漏れがないことを確認

(1)目標の明確化
 何を、いつまでに、どの程度

(2)計画の確認
 将来のリスクを想定するために、プロジェクトの計画内容について確認

(3)重大領域に沿ったリスクの識別
・実施計画の達成に悪影響をもたらしそうなキケンなところ
 1.未経験
 2.必要な資源が足りない
 3.時間的制約
 4.環境変化
 5.複数の部門が関与
 6.責任の所在が明確でない

(4)重大領域は、問題の発生確率の高い箇所を中心にリスクを洗い出す
  →発生確率は低いけど、被害が大きいものも追加
   できるだけ、多くのリスク

(5)漏れないこと確認

【実験】
・ブレスト(カードBS法は一人でできる)、オリジナルなKT-PPA、今回の方法を比較
正解データA+C
手法Xで生成されたデータB+C

適合率P=C/B:手法X
再現率R=C/A:本来のもの

【注意】
・プロジェクトに対して行う
産業能率大学でけぷなーとりご法の翻訳本がでている(うえのさん)

---------------

MUST/WANT分析を用いた定性的リスク分析法

コンテンジェンシープラン:発生時にどうするか

どれを優先的に対処するか

関連研究
・発生確率・影響度マトリックス
・けぷなーとりご法
・すみすらの方法

一般的に
・プロジェクトの確認
・リスクの確認
・リスクごとに被害の大きさと発生確率を見積もる
・優先順位決定
・リスト作成

見積もり
2変量、3変量→誤差が増えるので2変量
3値、5値、10値、何値でみつもる→4値
  普通を入れると、普通が増える
  適度な粗さがないといけない

定性的リスクの優先順位
  KT-DA:AHPにない、絶対目標、希望目標がある
        →MUST/WANT分析

MUST/WANTステートメント作成
リスクごとにMUST/WANT事象に分類
優先順位→MUSTは絶対なので1にする
WANT事象の発生確率と被害の大きさ→4値で
優先順位:発生確率X被害の大きさが大きいほう、同値ならS優先
ワークシート

分類基準を出題者が示すと良い

プロジェクトマネジメント支援ツール
要求抽出作業を誘導する方法

ソフトウエア構成論

要求仕様書:漏れ、誤りがない
→支援できないか?
お客様に聞く
→インタビュープロセスにおける初心者と熟練者の相違を実験によって明らかにする
話題の遷移方法
初心者:順番ない
熟練者:パターンある
  親しい場合:予算→機能→非機能
  ふつう場合:機能→予算→非機能
  疎遠な場合:機能→非機能→予算
機能要件
・What
・Example
・Why
・現行システム

熟練ほどWhy→相手の考え方

予算

非機能
 ・せいやく
 ・ポリシー
 ・条件

2階層モデル
・顧客回答が有限個になるまで絞り込む

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

SVGが得意なD3.jsをChromeで、RDF検索のSPARQLをサイトでお手軽に楽しんできた

2014-05-29 12:24:47 | Weblog
5月29日、先端IT活用推進コンソーシアムの

D3.jsでオープンデータをビジュアライズしてみよう!(ハンズオン勉強会)


にいってきました。




前半はd3.jsの使い方で、
まず、
1.以下の内容を"sample01.htm"として保存
<!doctype html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>Sample 01</title>
<script src="http://d3js.org/d3.v3.min.js"
charset="utf-8"></script>
</head>
<body>
<p>A</p>
<p>B</p>
<p>C</p>
</body>
</html>

2.Chromeでひらく(A,B,Cという文字が見えるだけでOK)
3.Ctrl + Shift + I(Windowsの場合)でデバッグモード、ESCを押してコンソール出す

4.コンソールに
d3.selectAll("p").style("color", "red")
などと、命令をいれる


これで、

d3.selectAll("p")
.data([1,2,3]).transition()
.duration(1000)
.delay(function(d, i) { return i * 1000; })
.ease("cubic-out")
.style("font-size", function(d) {
return d * 12 + "px";
});

とか実行して、文字の大きさを変えるアニメーションをしたり
(ちなみにfunctionの引数、dには、.data[]のデータが、iには順番が入る)
そのほが、SVGでグラフを書いたり、円を書いたりしました。


後半は、LODとSPARQL。

公共施設情報
http://lodcu.cs.chubu.ac.jp/SparqlEPCU/project.jsp?projectID=publicFacilityInfo

にいくと、「SPARQL検索」ということろがあるので、そこでコマンドを入れて、「検索実行」をクリックすると、検索できます。
select * where {?s ?p ?o} LIMIT 100
とはいってます。それを実行すると、表示されます。
くわしくは、
以前の資料 http://cloud.aitc.jp/20131221/

とのこと。

d3との連携は、d3.jsonを使ってSPARQLを投げるみたい。

自分のところで、SPARQLやるので、RDFのサーバーをたてるには、

Apache Jena
http://jena.apache.org/

を立てるらしい。

以下、メモメモ




可視化については、

エンジニアのためのデータ可視化実践入門

という本は、参考になる。

D3.jsでグラフを書こう
D3.js Data-Driven documents

何するもの?
Data駆動ドキュメント

SVGの描画が目立つが、任意のDOMを使用可能
データとドキュメントをバインド氏、宣言的に記述する。簡潔、パワフル
どう表すかの手順ではなく、何を表すか

D3,jS APIドキュメント

------------------

LODに触れてみよう

LOD:Linked Open Data
RDF:トリプル
SPARQL:RDFを検索する
 SELECT * WHERE{
?s ?p ?o
}
→全件返す。?は変数
ドットを付け忘れると動かない。セミコロンにも注意

d3との連携d3.json

Apache Jena
RDF:分解してRDB




FaceBookにはD3の参考書として

インタラクティブ・データビジュアライゼーション ―D3.jsによるデータの可視化
http://ja.d3js.info/alignedleft/tutorials/d3/

が載ってました。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

高速開発ツールを最大限に活かす!

2014-05-29 09:00:12 | Weblog
5月26日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

最後は

高速開発ツールを最大限に活かす!
~市進が取り組んだ基幹システム開発事例~

をメモメモ



1.なぜ高速開発ツールを選んだのか
2.開発概要

・会社概要(ビデオで)

・なぜ高速開発ツールを選んだのか

旧システムの問題点

コンペしました
・N
・F ぶひんか
・K
・FS
・I
・NI
・ITF社 ちょっと声を毛型

ITフロンティア→Genxas
 データとプログラムを自動生成する
  ネットで検索:悪口ほとんど出てこない
  コンサルタント:けっこういい
  ウルグアイ:農業の国

事例
 書籍M
 コーヒーD
 トライアル開発
 直接話し聞く。小田原:内製化してます

どうも本当らしい
  →やってみるか
  →塾業界初めて、大丈夫?
  →信じてやってみよう

画面数490
成績表SGS
開発期間18ヶ月、ピーク時11名半分以下と思う
GeneXusのメリットを活かす
・アジャイル開発:実際の画面を見て開発
 →イテレーション開発

・できるだけ標準仕様で開発しよう
 →カスタマイズは最小限に
 →修正の圧倒的な速さを確保
 →Webパネルの中で

・業務の変更にシステムを合わせよう→システムの内製化
・常にシステムが頻繁にタイムリーに追随する
ベンダ→ユーザー

終わりに
・一期一会
・乾坤一擲

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

BRMSの次に期待されるレッドハットが提供する次世代PaaS実行環境

2014-05-28 18:58:50 | Weblog
5月26日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

つぎは

BRMSの次に期待される
超高速開発環境「DevOps」に迫る
~レッドハットが提供する次世代PaaS実行環境
 JBoss xPaaSとその価値を紹介~

をメモメモ



RedHat JBoss Middleware
→BRMS:2013年度 シェアNo1を獲得
・ルールエンジン
  後ろ向き推論 NowDSBのみでなく、後ろ向き推論できる
  プランニング
→BPMをよりシンプルに

ベストプラクティス その1
・「ビジネスルールは常に変化する」を前提とする
  ルールとプロセスをわける
  変更はルールで吸収
 アプリケーション
   プロセス→データ→ルール

ベストプラクティス その2
 ルールの抽出、デザインは専門家に任せる
 保守工数が上がる

DevOps
  小さな変更を頻繁にリリース→超高速開発

レッドハットが提供するPaaS-OpenShiftの戦略
  OSSコミュニティ
  パブリッククラウド
  プライベートクラウド
JBoss xPaaSで高度なアプリケーションに対応
OpenStack RHEL7,Dockerに最適化
→OpenShift Dockerで
 Jenkinsが組み込まれている
一歩先行くPaaS基盤
  OpenShift+JBoss=JBoss xPaaS
   BPM PaaS
   Real Gear プッシュ
  JBoss Fuse

JBoss XPaaSで実現できること

BRMS
・変化を受け入れる
・専門家による支援

PaaS
・OpenShift

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

エンタープライズモバイルアプリは超高速開発に向かう

2014-05-28 15:58:10 | Weblog
5月26日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

つぎは

エンタープライズモバイルアプリは超高速開発に向かう
~モバイル事例で見る開発ツールの進化と真価~

をメモメモ




イスラエル
マジックソフトウェアエンタープライズ
サピエンスと兄弟外車(親会社一緒)

800社のパートナー

・Magic xpa:きょうこっち
・Magic xpi<-EAIツール

モバイルアプリ開発
・BYOD
・Webアプリは遅い、使いにくい
・OSが変わるたび
・要求仕様がまとまらない
・ユーザーからいろいろ要求
・サーバー側にリソース

利益 < コスト

業務アプリのための開発環境の条件
・ワンソースマルチデバイス
・早く作れて、即座に変更
・基幹システムに耐えうる機能性、信頼性
・デバイス側のアプリ開発では不十分

モバイルアプリ開発は氷山の一角
  ・UIクライアント側ロジック
   通信→xpa
   データ管理→xpa
   サーバー側ロジック→xpa
   データ連携→xpi

業務処理の定義
Magic Engine

開発環境
  DB設定
  画面
  ロジック:10種のコマンド
→XMLのアプリケーションメタデータ
 コンパイル不要、即実行

3種類のアプリケーションを構築可能

リポジトリを定義する
  モデルリポジトリ  :カラムの定義
  データリポジトリ  :テーブル設計
  プログラムリポジトリ:
 クロスリファレンス
  コールしているプログラムリスト
    →影響範囲がわかる

保守、メンテナンス

開発プロセスの違い

アプリケーション更新プロセス

優れた拡張性・可用性
・容易にスケールアウトできるサーバーアーキテクチャ
  →標準で入っている

Magic xpaの真価
・機械的、低レベルのコーディングを排除
・カスタマイズ/保守コスト軽減
・アプリケーションの移行が簡単
  Magicが吸収
・業務アプリケーションしか作れない
  →作り方が決まっている
・アジャイル開発が得意

事例
・パッケージソフト.com
・富士通テン
・紙→タブレット
Magicで開発すると
・全部1人で開発できる
・お客様と一緒に前向きに取り組める
バックエンド連携:学研SAP

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ITゼネコンの食い物にならないための、産総研包括フレームワークを利用したシステム構築-札幌市

2014-05-28 12:57:41 | Weblog
5月26日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

つぎは

長期間にわたりメンテナンスしやすいシステムの実現を目指す
札幌市基幹系システム再構築におけるグラスボックス化のとりくみ

をメモメモ




長期間にわたりメンテナンスしやすいシステムの実現を目指す
札幌市基幹系システム再構築におけるグラスボックス化のとりくみ

・はじめに
・変化に強いシステム実現のポイント
・業務とシステムをつなげる利点、大変さと工夫

変化につよいシステム
・札幌市が考える「メンテナンスしやすいシステム」
・保守開発の高速化
  重複して作らない
  互いに影響させない
  業務とシステムをつなげる
   +α(新しく広く普及した技術)

再構築対象システム(現行)の概要
現行システムで起きていたこと
  ITがビジネスの変化を阻害する状況に
  自治体がITゼネコンの食い物に

規模間とスケジュール
  Javaによるフルスクラッチ、事業基幹は6年
  発注:専任72名

産総研包括FWの採用とその構成要素
  産総研包括フレームワーク
   →グラスボックス(要件と実装のつながりで中身が見える)
     共通のものさしに

・1.重複して作らない
  似て非なるもの→共通化をどのタイミングで誰が判断

・2.互いに影響させない
  データ連携基盤
  インフラ、ミドルウェアの入れ替えやバージョンアップの影響
    O/Rマッピング
・3.業務とシステムをつなげる

・業務とシステムをつなげる利点
 産総研包括FWの成果物標準
   →BPNMににたようなもの
 業務と論理的

・大変さ
  品質
   切り出しかた
   濃さ
   洗い出し漏れ、関連性漏れ

・やり方しだいで品質、生産性は大きく変わる 


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

サピエンスによる開発生産性向上事例

2014-05-28 10:31:41 | Weblog
5月26日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

つぎは

サピエンスによる開発生産性向上事例

(注意!サピエンスの人では「なく」
  サピエンスを使ってシステム構築した会社の人が話した事例)

をメモメモ




サピエンスによる開発生産性向上事例
・会社概要
  リクルートの総務部門から→コスモスライフ

・サピエンス導入の経緯
   日経コンピューターの記事
   センチョラ=SQLWindow→サピエンス
    クラス指向

・対象システム概要
  スクラッチ再開発
  パッケージなし
  スピーディー
  外部監査
  開発変更体制
 規模
   テーブル180
   画面  209
   帳票   28 (SVF)
   バッチ  40 (RPG/CL)

・注目した特長
  プロトタイピング&スパイラル
  自動ドキュメンテーション
  プログラムレス(知識ベース)

・VB.NETとサピエンス比較
 ZenApp(メタフレーム)
  ・開発生産性
  ・ナレッジ:統合環境

・内製を考えたが、外製を選択
   人を抱えると→キャリアパス、抜けた穴
   簡単に開発→外製でよりスピードアップ
   ドキュメント:外部→監査会社
   作って提供するでなく、サービスを提供

・成果
  正解:VB.Netでは難しい



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

戦争を考えると、中国製PC,サーバー、クラウドはやばいか?

2014-05-27 19:39:19 | Weblog

中国当局、IBMサーバー撤去を国内銀行に迫る-関係者
http://headlines.yahoo.co.jp/hl?a=20140527-00000030-bloom_st-bus_all


あ~、日本とアメリカは大丈夫だけど、
日本と中国もやばいよね!

中国と日本の関係が悪くなれば、中国当局が日本のサーバー撤去を求めるのみならず、日本から、中国企業も撤退・・・となると、中国製PC,サーバー、クラウドを使っていると、サービス停止とか・・

アメリカ製、国産のほうが、戦争リスクを考えると安全か?

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

情報システム刷新の主流となる手法

2014-05-27 15:56:09 | Weblog
昨日、
超高速開発リノベーションフォーラム2014
に行って来た!話の続き

つぎは

情報システム刷新の主流となる手法
システム・リフォーム

なんだけど・・・(以下内容のメモのあと、一番最後に感想)




1.会社紹介
・リフォームの報道
・急速に広がっているリフォーム
・日本に来た経緯

2.巨大開発の問題
・既存システムの状況
   初期開発
   ブラックボックス→莫大のロジック
 開発になると
   ユーザー要望を押さえ込む
   業務カイゼンを考える余地がない
   開発の失敗は日常茶飯事
・企業ITの新の需要は
   業務カイゼン→世界標準でやってください
     2つ機能+技術

3.システムリフォームのプロセス概要
   現行システム
    1.スリム化
    2.移行
    3.仕様書再生
    4.新案件取り込み
   刷新システム

移行のプロセス
  ・変わるところを気にする
    ソースを仕様書/ソースに変える
  ・パイロット移行検証で、品質と納期を確実に
    フェーズ1:パイロット移行検証
    フェーズ2:本移動
  ・多用な変換パターン
    ツールとミックス
    人は2ヶ月あれば読める

既存システムをベースに改善(新要件取り込み)
  ・業務プロセス分析
  ・データ分析
  ・業務ヒアリング

既存AP資産のスリム化・移行前の見える化
  ・ログ分析:ツールにかける
     ユーザー:この機能は使っていない
       →実はバッチで使っていた!
  ・PGM→PGM連携分析(画面/バッチフロー)

リフォームの品質
・納品後バグ密度
  (JUAS換算欠陥数) JUAS標準目標:0.25
・コスト
  JUAS新規開発平均86.8
・オフショア保守
  システム更新
  COBOL→JAVA

事例
・パッケージは意外とたかい:10年使ったりすると
・業務を理解しているわけではない




で、システムリフォームって、なに?

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

超高速開発の体系化とアジャイルとの関係

2014-05-27 12:01:22 | Weblog
超高速開発の話をきいてきて(これからいろいろ披露しますが)、
どうも、超高速開発は4つに分かれる話をひとつにまとめてしまうから、
まゆつばに聞こえるように思えた。

1つ1つの話は、以下のように全うな話。

1.MVCにおいて、モデルを3つ、ルール・データ・プロセス?にわけ、
  ルール部分を、可視化し、ノンプログラミングにする→BRMSの分野

2.MVCにおいて、MCを自動化し、てきとうな(適切ではない)Vをつける
  →いわゆるRails、マジック、GeneXusなど

3.1.2が動作する環境の提供、自動化など
  →DevOpsやクラウドなど、RedHatのOpenShiftなど

4.その他(開発方法論など)
  →産総研包括フレームワーク?

それぞれをみると、既にあるもので、実績を挙げているものなので、
そんなに不思議な話ではなく、うん、そういくだろうな・・・
と思うんだけど、これらをごちゃ混ぜにして、日経BPが
「超高速開発」というと、あやしくなる。

で、これらは、アジャイルそのものではなくて、
アジャイルを行ううえで便利なツールになるということですね
(アジャイルでなくても使える)

ただ、これで進化が終わりではない。
結局Vの部分がいいかげんなものをつけてしまうので、
すべてに応用できない。

今後は

・MCをRESTで提供し、Vの部分は、一応作るけど、いろんなツール
  を使い、AJAXで連携することができる

・その上、ルール部分はBRMSと連携可能

というツールができれば、完璧

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

超高速開発リノベーションフォーラム2014-まずはBRMSの話

2014-05-27 09:42:09 | Weblog
昨日、
超高速開発リノベーションフォーラム2014
に行って来た!

その内容をメモメモ。まずは、はじめのお話

双方向判断機能で乗り越えるBRMSの落とし穴
~なぜ独自BRMSを開発したのか~

から。




BRMSの苦手なところ→独自開発
ライセンス提供可能

1.会社紹介
 ITプロデュース部
  SOA,仮想化、WebSocket,BRMSなど

2.BRMSとは
 アプリケーションからビジネスルールを切り出して、
 実行・設計・管理

目的
・守りの目的:システム開発、メンテナンスコスト
・攻めの目的:インテリジェンス

BIWARD
 BI:双方向
 WARD:forward,backward

BRMS:保険業界多い
→一部のインプット固定
銀行:対面型事務→双方向
  前進判断:条件→結果
  後進判断:結果→条件
ほとんどのアルゴリズム
  Tree構造で判断分岐→逆方向:実現が難しい
→Network構造アルゴリズム
  前も後ろも関係ない
ルール:独自のルールエディタ
  ディシジョンテーブル
  条件をいれると→なにをしてくれとでてくる
 XMLでできている

ルール作る
ルール直す
エラーになる→想定するところがエラーになるか?
エラー部分の修正
  XML→Scala(すから)→JAR

対面業務のBRMS活用には注意が必要
NoWDSB:双方向
BRMSは保守性向上に大きなメリット
  →新規開発時に楽になったわけでない
  →保守:ルール側かアプリ側かがわかる
提案型BRMSへの挑戦

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

サービスの視点から、保守の見積もりを考えてみよう

2014-05-26 15:53:52 | ネットワーク
5月22日にSERCフォーラム(さーくふぉーらむ)という、ソフトウェアの保守関係をやっている人のあつまりのフォーラムに行って来た。その内容をメモメモ。

第三弾(これでおしまい)は、基調講演「サービスの視点から、保守の見積もりを考えてみよう」

について



サービスの視点から、保守の見積もりを考えてみよう

1.自己紹介

2.はじめに
・IT企業とは:ここでは、下請けの保守会社を考える
・保守とは:ここでは、ソフトウェア保守を考える
・素朴な疑問
  見積もり?年間の契約工数内の調整?

・新規開発→規模見積もり

3.見積もりの定義
・契約前、着手前に適正価格を算定し、受注・発注の可否を検討できる資料
・期待値

4.保守の現場で聞かれる声

5.研究の進捗報告
 →見積もりの研究が進んでいない

6.SERCでいろいろ勉強した
 保守開発をサービスと考えてみよう
 →ITIL,ISO20000説得できる材料

7.サービス視点のこと?
サービスマーケティング
・エクスターナル
・インターナル
・インタラクティブ=ここ?
→ソフトクリーム思考法
・代替案、改善効果を提案する

8.ささやかな改善策
 ・トライアングル思考法
 ・保守をファンクションポイント
 ・品質管理を保守でも

9.今後勉強すること

10.最後に

Q&A

・リスクの共有
 →新規でもできない

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする