品質について改めて整理②

品質を高めるために行うことは


予防 

検知


1.まずいかにして不具合を入れないようにするかを考え(標準化)

2.次に不具合を入れないための対策がちゃんと機能しているかチェックしながら(レビュー)

3.成果物が出来たら本番稼動前までに不具合を可能な限り見つけては解消し(テスト)

4.本番稼動後はシステムが問題なく動いているかのチェックを日々行う(監視)



以下それぞれについて簡単にまとめ



1.

標準化の目的は成果物に作業した人による個人差が出ないようにすることで、作業の進め方(手順書の作成やツールの導入)や成果物(ドキュメントやソース)の中身についてルールを設ける。



2.

レビューの確認内容は検証(前工程と現工程の成果物の整合性)と妥当性の確認(ユーザの要求通りかの確認)で、目的はユーザの承認を得ることと不具合をいち早く検出することで手法は様々である。

特に会議体の場合、何のためのレビューかをはっきりさせないと、参加者の時間を無駄に奪うだけなので、何のためのレビューかをまずはっきりさせてから行う


アドホックレビュー

目の前の課題について周りのメンバーと非公式に相談する


ペアプログラミング

厳密にはアジャイルの開発手法だが、2人で1つのプログラムに取り組むことで、レビューで得られるような効果が得られる。技術や知識に差がある2人で行うなど


ピアデスクチェック

成果物の作成者とレビュアーの2人で完結する


ピアレビュー

解釈や定義は様々あるが、同じ得意分野の同僚によるレビューの意味で使われることが多い


パスアラウンド

成果物を回覧して多人数でレビュー。会議を設定して集まるより、各々のレビュアーが各自内容チェックすることが多い


チームレビュー

作業のキリの良いところで集まり、情報共有などを目的に行う。内容は教育や欠陥の発見など目的に応じて臨機応変に決める


ウォークスルー

成果物を作成した人が会議に参加した人に説明をして意見を求めたり、問題点をあげ、解決策を出してもらったりする


インスペクション

会議体で作成者、進行役、記録係、レビュー役を決め、各立場の参加者が集まり、成果物が標準化されているか?顧客の要望を満たしているか?前工程の成果物と矛盾がないか?などを正式に確認する



3.

テストの目的は欠陥の発見!手法はテストケースの作成方法、テストの実施方法それぞれで数多く存在する。


同値分割法

仕様から同じフローで同じ結果となる入力をリストアップして、出力を確認。正常系と異常系それぞれ考える


境界値分割法

同値分割法で分けた入力出力から結果が変わる境界となる値の上下のケースでテストを行う


異常値特異値分割法

仕様の点から特別なフロー対応が必要なケースのテストを行う


制御フローカバレッジ

主にツールを使って各フローを通る確認


データオブジェクトカバレッジ

プログラム中のオブジェクトの各状態(初期,参照中,削除後など)で正しい動作する確認


論理組み合わせテスト

複数入力パターンの組み合わせを考えてテスト。デシジョンテーブルなどを利用


状態遷移系テスト

有効な状態遷移、異常な状態遷移が正しく行われる確認。状態遷移図などを利用


その他

タイミングテスト

並行処理テスト

非機能要件のテスト

サンプリングテスト

探針テスト

統計的テスト

経験によるランダムテスト


尻切れトンボになってしまったが以上。


4.

監視は日々の業務が正しく行われていることを保守担当者がチェックシートなどにより確認したりと異常時に関係者にアラートが飛ぶように事前に設定しておく両面から確認


参考サイト

https://www.ipa.go.jp/files/000005144.pdf






























Spring frameworkの基礎

Javaフレームワークの主流の1つSpring framework


DI (依存性の注入)

AOP (アスペクト指向)


などが大きな特徴。


■DI (依存性の注入)で実現できることは


1画面表示,画面遷移を行う部品

2業務処理を行う部品

3データベースの読み書きを行う部品


を分けて管理


*それぞれの独立性を高めて、例えば2の業務処理の仕様を変えたいときに2だけ直して2だけテストすれば大丈夫、このとき3はmockと呼ばれるスタブのようなダミーの部品を利用する

EJBみたいなコンポーネント化して連携するより1と2、2と3をどうやって連携するかの仕組みをあまり考えなくてよい

*Singleton(オブジェクトが1つしか作られない)なので、同じ部品を同時に別のとこからも呼ばれたらどうしよう?とか心配しなくてよい


とかが便利なところ


interfaceクラスと実装クラスを作って、お互いの実装クラスは見えないようにすることで独立性を高める



AOP (アスペクト指向)で実現できることは


Javaオブジェクト指向では役割の塊ごとにオブジェクトという単位で分割してまとめるが、各機能を横断して共通して付与しなければいけない役割がどうしても残ってしまい、分割してまとめることが不十分

各機能を横断して付与したい役割を外出ししたのがアスペクト指向


*決まったとこでログに書き込む

*利用者の権限によるアクセス制御

トランザクション管理の標準化

*例外処理の標準化


などが主な例


これを実現するための方法が


アドバイス(外出しした横断して共通の処理をする部品)

ポイントカット(各機能でアドバイスを呼ぶ所)


を実装すること

Spring frameworkでは主にアノテーション(@〜をクラスやメソッドの前に記述)でこれを実現



Spring frameworkが備えている機能


DIやAOPを実現するだけなら他のフレームワークでも可能

Spring frameworkで用意されている機能はDIやAOPだけでなく他にもたくさんの機能が用意されている


IDE

  Spring Tool Suite(STS)

RAD

  Spring Roo

Starter

  Spring Boot

Web

  Spring Data Rest

  Spring Mobile

  Spring WebFlow

  Spring MVC

Security

  Spring Security OAuth

  Spring Secrity

Big Data

  Spring XD

  Spring Hadoop

Data Access

  Spring Data MongoDB

  Spring Data JPA

Batch

  Spring Batch

Enterprise Integration

  Spring Integration

Sosial

  Spring Social Github

  Spring Social Facebook

  Spring Social Twitter

Core

  Spring DI

  Spring AOP

  Spring TX

...


■Spring  Bootで簡単にSpring framework


開発者は各フレームワークの各機能を組み合わせてシステム開発を行っていたが、部品の選定や環境の設定などで開発者にはそれなりの知識が要求された

Spring Bootではあらかじめ一通りの機能が標準で盛り込まれており、面倒な準備をせず簡単に動くシステムを作れる

コンパイル、ビルド、デプロイというステップを踏まずに手軽に開発環境で動作の確認ができるのも利点


初めてのキャッシュフローゲーム

ちょっと友達に誘われて投資の勉強会?的な集まりでキャッシュフローゲームをやってきました。

 

キャッシュフローゲームとは?

 

金持ち父さん貧乏父さんの著者ロバートキヨサキ氏が考えたボードすごろくゲーム

人生ゲームとか桃鉄とかいただきストリート的なゲーム

 

キャッシュフローゲームの流れ

 

BS(貸借対照表)とかPL(損益計算書)をまず書いて

 

サイコロを振って

 

給料日のマスを通過すれば給料が貰えて

 

投資イベントのマスに止まったらカード引いて、株や不動産などをカードに書かれた価格で売買できる(けどしなくてもよい)

 

BSやPLは都度書き換えながら、手持ちの資産を増やしていくゲーム

 

■ゴールは2つ

 

最初の目標は不労所得(自分が働かなくても勝手に入ってくるお金)が支出を上回ること

働かなくても生きていける状態

 

次の目標は最初に決めた人生の目標に必要なお金が手元にあること

お金がないからやりたいことを我慢しなくていい状態

 

■やってみた感想

 

ゲーム自体は自分の普段の行動とかが如実に現れて色々気づかされることも多いので、チャンスがあればやってみたほうがよいと思う。怪しい投資話とセットで開催されることも多いらしいので、騙されやすい人断れない人流されちゃう人は止めておいたほうがよさそう。

 

投資話は金額が小さいより大きいほうが断然有利(ローリスクハイリターン)。現実世界の投資でも元手が大きいほうが有利なのは世の中見てても同じだと思う。ゲーム内だとプレイヤーがお金出し合って有利な大きい投資ができる。現実世界でも同じようにできればと思うけど、詐欺とか持ち逃げとか心配だから、よっぽど信用し合ってないと難しいかな?

 

ゲーム内だとこの投資話はどのくらいリターンがあるとか株価はいくらぐらいで推移するとか書いてあってリスクとリターンが分かりやすい。思ったのは、意外と現実社会もちゃんと勉強して経験積んで見る目を養えば同じなんじゃないかな?実際のお金が絡むと冷静な判断できなくなるので、みんな損するけど。

 

なんだかんだでいろいろ勉強になりました!

 

品質について改めて整理①

システム開発で大事なことは?


と聞かれたとき、見る角度や立場から様々な意見があると思いますが、間違いなく必要なものの1つは


「品質」


であるというのは間違いないと思います。


他にも「コスト」「納期」とありますが、お互い影響したり、トレードオフの関係だったりする。



■品質とは?

JIS規格によれば6つの品質特性と27の品質副特性


1 機能性 

   合目的性,正確性,相互運用性,セキュリティ,

2 信頼性

    成熟度,障害許容性,回復性

3 使用性

    理解性,習得性,運用性,魅力性

4 効率性

    時間効率性,資源効率性

5 保守性

    解析性,変更性,安定性,試験

6 移植性

    環境適応性,設置性,共存性,置換性


※それぞれの意味は割と言葉通りの意味。



■品質の良いシステムとは?


ちゃんとお客さんの要望通りの機能が全て盛り込まれてて、

業務が絶対滞らないレベルでシステムが稼働し続けて、

お客さんが操作しやすくて、

裏ではマシンの性能を効率良く引き出していて、

システムの保守や移行が可能な限りスムーズに行えるシステム。


裏返すと


■品質の悪いシステムとは?


お客さんの要望通りの機能になっていなくて、

すぐシステムが停止したり、意図しない動作をして、

お客さんが使い方を理解しにくくて

マシンの性能通りの性能(レスポンスなど)が満たされていなくて、

システムの保守や移行が行うのが大変なシステム。


■品質は100%実現しなくてはいけない?


そもそも人によって認識が違ったりするので100%の判断が難しい。

また品質100%のシステムを実現するのは、いくら開発関係者が優れていても、コストや納期の制約などもあり難しいことが多いので、

・品質をどこまで高めるか

・品質のどの部分を高めるか

はシステムの特徴や特性を見て判断する。


1つの指標として4段階の信頼性要求水準

・人命に影響、甚大な経済損失

・社会的影響が極めて大きい

・社会的影響が限定される

・社会的影響がほとんどない

などがある。


開発技術やマシンの性能、利用者数、世の中の求める基準などは時代とともに目まぐるしく変化しているので、その時代に応じた見極めが必要。



■品質が悪いとどうなるか?


発覚するのが

本番稼動前であれば、追加のコストが発生したり、スケジュールの遅延が発生したり、

本番稼動後であれば、システム利用者/利用会社の業務などに支障をきたし、損害が発生したりする。



■品質の向上のためにどう取り組むか?


品質が悪い=不具合がある


という前提で考えると


1そもそも不具合を作らない。

2不具合を見逃さない。なるべく早く見つける。


方法としては


1予防活動

2検知活動


の2つを開発の各工程(要件定義 基本設計 詳細設計 プログラミング テスト)において行う。


続きはまた改めて


参考サイト:

高信頼化ソフトウェアのための開発手法ガイドブック

https://www.ipa.go.jp/files/000005144.pdf







順を追ってイテレーションからラムダ式、ストリームAPIまでを理解

0)最初は昔の書き方

まずList型の場合、繰り返し処理は
for (int i = 0; i < string_list.size(); i++) {
    String str = string_list.get(i)
    System.out.println(str);
}
って書くけど、この書き方はもう古い

 

1)まずはイテレーション

ずばりイテレータを使ってこう書く
for(Iterator<String> i = string_list.iterator(); i.hasNext();){
    String str=(String)i.next();
    System.out.println(str);
}

 

2)ジェネリックスを使ってみる

さらにジェネリックスを使うとキャストしなくてよくなって
for(Iterator i = string_list.iterator(); i.hasNext();){
    String str = i.next()
    System.out.println(str);
}
となる。

 

3)拡張forを使ってみる

さらに拡張forを使うと
for(String str : string_list){
    System.out.println(str);
}
と書けるとのこと。なるほど!少し楽!

このように、イテレータを取得して、操作して、イテレータを実行するような処理を「外部イテレータ」と言うらしい。
ここで終わりではなく、さらに覚えなくてはいけないのが...
・内部イテレータ
ラムダ式
・Stream API

 

4)外部イテレータから内部イテレータに書き換え

上記外部イテレータを内部イテレータに書き換えるとforEachを使って
string_list.forEach(
    new Cunsumer<String>(){
        public void accept(String str){
            System.out.println(str);
        }
    }
);
となるらしい。なんか長いし難しい... 
これだと並列処理とかもできたりするみたいけど、もう少しすっきりしないだろうか?

 

5)ラムダ式を使ってみる

上記の内部イテレータを、ラムダ式を使って書くと
string_list.forEach(
str -> {
    System.out.println(str);
});
となるとのこと。なんかすっきりした!

1行だと{}を省略して
string_list.forEach(str -> System.out.println(str));
でも可!

ラムダ式の本体を省略して、メソッド参照なんかを使うと
string_list.forEach(System.out::println);
まで省略できるとか。

色々省略しすぎて逆に良く分からなくなってきた。

 

6)最後にStream API

上記のラムダ式をStream APIを使って書くと
string_list.stream().forEach(str -> {
    System.out.println(str);
});
となるらしい。

Stream APIは中間操作と終端操作というのがあって、
string_list.stream()
    .filter(str -> str.length <= 5)
    .forEach(str -> System.out.println(str));
みたいに書くと5文字以下のstrだけSystem.outするみたいなこともできるっぽい!便利!

中間操作と終端操作は色々種類があるから、使いこなせれば記述もすっきりして便利だけど、馴染みのない人にはフルにラムダ式やStream APIまで使いこなしているコードは理解するのにも一苦労しそう。

 

最後)まとめ

単純なfor(...){}から始まり → 0)
Iteratorを使うようになり → 1)
ジェネリックスで型変換を省略するようになり → 2)
拡張forで記述を省略し → 3)
外部イテレータから内部イテレータになり → 4)
ラムダ式になり、 → 5)
最後はStream APIになる。 → 6)


順を追っていくといろいろ進化してるんだな。。。

【読者メモ】図解 大学受験の神様が教える記憶法大全

最近めっきり記憶力が低下してるので読んでみた。

■PART1 記憶のメカニズムを知ろう

- 年をとると物覚えが悪くなるは思い込み。
単純な丸暗記は子供のほうが得意だが、大人は経験や自分なりの理解を加えて覚えることができる。

- 記憶とは「覚える(記銘)」「覚えたことを保つ(保持)」「思い出す(想起)」の3ステップで考える。
想起には勝手に思い出す「再生記憶」と意図的に思い出そうとする「再認記憶」があり、いわゆる記憶力は「再認記憶」がうまく機能するかどうかにかかっている。

- 記憶のポイントは1.すぐ忘れないように繰り返しインプットすること、2.必要なときに情報が取り出せるよう定期的にアウトプットすること。

- 記憶は起きている間どんどん上書きされていくため、必要な情報が想起しにくくなる。
これを軽減する方法は1.一気にではなく数回に分けて覚える、2.繰り返し記憶する、3.余計なことは覚えないこと。

- 社会人になっても学生時代と同じ記憶法は可能だが、効率よく記憶するためには、1.覚える目的をはっきりさせることで、2.関心興味がわいて、3.自然と注意力が働き脳が勝手に必要な情報を集めはじめる。

- 寝ている間脳は日中働いていた脳の修復をしたり、日中記憶したことを定着させることをしているため、個人差はあるものの一般的には6〜7時間の睡眠をとることが必要。

- 記憶の効率を高めるこつは「イメージづけ」と「関連づけ」1.五感、2.誇張、3.リズムや動き、4.色、5.数字、6.記号、7.順番とパターン、8.魅力的なイメージ、9.ユーモア、10.ポジティブなイメージを活用する。


■PART2 仕事に活かせる!社会人のための記憶術

いくつか抜粋
・目的を明確にいかに関心や好奇心をもつか
・むやみやたらと暗記するより理解して覚える
・書く書く書く、もしくはSNSで情報発信
・メモはポイントやキーワードを矢印や囲みで整理
・復習復習復習、1日後1週間後半年後
・ストーリーで覚える
・音読音読音読、目で読み声に出し耳で聞く
・数字は7桁までしか覚えられないので区切って語呂合わせ
・睡眠はしっかりとる
・類似情報はまとめたほうが覚えやすい
・内容を大中小で考える
・思い出すヒントを用意しておく


■PART3 想起力を高める記憶法

- 記憶とは「記銘」「保持」「想起」の3ステップ。年を重ねるごとに重要になってくるのが「想起」いつでも必要なときに必要な情報を引っ張り出せるか!
アウトプットを目的にインプットする「いつどこで使うか」「何と関連づけて覚えればよいか」

- 名前は付加情報とセットで。大人になるほど付加情報が格段に増加。付加情報にも優先順位をつける。優先順位の付加情報は捨てる。

- 名前を忘れないこつは1.声に出す、2.意識して復習、3.そのときの資格情報とセットで覚える、4.メールの宛名や書類に相手の名前社名役職を毎回書いて付加情報を合わせて覚える

- 子供は意味記憶、大人はエピソード記憶

- 記憶定着のステップは1.注目、2.よく理解、3.セットで覚える、復習、練習(リハーサル等)

- リハーサルをして想起力を上げるトレーニング(日本人は怠りがち)

- 思い出すきっかけとなる情報は多いほうがよい。セットで覚えた情報は流れつながりを意識してスムーズに取り出せるよう整理しておく

- アウトプットの機会をとにかく増やす。場数を踏めば緊張が減り想起力も上がる。

- そのまま覚えるよりも自分なりに加工することで情報の価値が増す「周辺情報とくっつける」「エピソードで記憶する」スピーチなどのアウトプットは「シナリオ」を必ず用意する。面白いと思ってもらえる工夫、伝わる工夫。


■PART4 記憶力トレーニング

(割愛)


日頃の心構えを変えて、出来そうなとこからやってみよう。




HR×テクノロジー

f:id:munqu:20160414122059p:plain

http://eventdots.jp/event/583715

 

ちょっと面白そうだったので行ってきました。

 

◆HRとは

ヒューマンリソース 人材資源のこと

http://www.weblio.jp/content/HR

HR×テクノロジー(HRテック)とは

ITを使った人材資源の活用に関する取り組み

 

◆各社状況

社内に開発部隊を持っていなかった

システム開発はグループ会社などに外出し

社内で開発部隊を持とう

何千人いる社員のうち最初は開発メンバー1人とか

従来の文化体質

・人材会社にとって情報は最も重要、とにかくセキュリティが最優先

・開発技術ツールを好きに選定できない

・外部とのネット接続がかなり制約されてる

従来の文化体質に馴染むのではなく、情熱を持って変えていく

もちろん抵抗にあう

徹底的にリサーチして説得できる根拠を揃える

会社としても変わりたくないわけではない

メリットがデメリットを上回れば了承

現在ポリシーを持って組織作り体制を強化しているところ

・まずは情熱が大事、とにかく挑戦

・組織として結果も出すし、個人のやりがいも追求する

・みんなが当事者意識をもつ、スピード感をもつ、コミュニケーションとにかく大事

・新しいメンバーを募集するため、積極的に情報発信している

 

◆感想というか感じたこと

とにかく情熱を持って技術を追求していく、そしてとにかく楽しむ

何かを変えるとき当然反発はあるけど、地道に根拠を集めれば変えられるのと、時には代替案があったりするので、簡単に諦めないこと

技術のことだけじゃなく、組織作り、ビジネス視点でのことも勉強してて、4人とも仕事に対する情熱が凄かった

小学生並みの感想だけど、とても面白かったし、よい刺激になった