ReVIEW
uml
プログラム
ソフトウェア
HAZOP

算譜(program)の見直し(review)に必要な志向・技能・技法・手順、上位7ver.2.1 (20180228)

算譜(program)は、一人で書いていると思い込みや、勘違いでとんでもない穴が生じていることがある。静的検査、動的検査、証明などの道具を用いても、思い込みや勘違いのうち、根本的なところは抜けていることがある。

目的(purpose):

20180228 小寺浩司さんの助言に基づき追記
一人で仕事をしていると、うまく行っているか不安になってストレスが溜まってくる。その溜まったストレスを、先輩や専門家、あるいは新人の純粋な目で見ると、なんだそこを直せばスッキリするんだと、ストレスを解消させることがReviewの目的です。

成果(outcome):

20180228 小寺浩司さんの助言に基づき追記
ストレスが解消するため、担当者のやる気が倍増し、作業効率が良くなる。

ソフトウェアの見直しに必要な志向、技能、技法、手順を考え、それらに優先順位をつけて上位7つを記載する。

p.s.
ソフトウェア設計・開発で、仕様書、設計書を日本語で書いている人たちがいるらしい。また、それらの文書の見直し(review)で、わいがや、顔見せ、憂さ晴らし、息抜きをしている人たちがいるらしい。

1 関係する技術について技能・経験のある人に参加してもらう

これが一番大事。どの技術については誰の意見をもらわないと駄目みたいな習慣があればよい。組織内に誰もいなければ、組織外からの参加を要請できる習慣も大事。

よく見落としがちなのが材料。新しい材料を使っていれば、重さ、硬さ、動作、防水・防塵・耐熱、耐用年数など違うことがいっぱいあるのに、何のパラメータを変えれば充分かの専門的な知見、試験結果の評価ができていないと、大きな失敗をするかもしれない。

2 問題解決の意志

問題を解決するソフトウェアを設計・開発する場合に、必要となるのは、問題を解決するためのプログラムを書く人の強い意志(やる気)が大事。問題を解決するつもりがない人の説明を何時間聞いても無駄。解決したい問題の大きさと、その解決するための意志があれば、オンラインで内容を検討したり、集まって検討会をするのは無駄。

問題を解決する意志がない人がいても、集まって、わいがややって、なんとか組織として解決したいという管理者の方がいるのかもしれません。確かに、時間とお金があれば、わいがやの中から、解決策が生まれる可能性はあるでしょう。

最悪なのは、問題を解決する意思がなく、見直しの方法や手段、情報を伝達する意思があるかどうかを問題にする人。問題を解決する意思のない人に、情報を伝達しても、足を引っ張るだけで協力しない人になぜ情報を伝達する必要があるのだろう。

報連相がうまくいかない場合があるのは、報告しても、連絡しても、相談しても、足を引っ張る人がいれば台無しだということを自覚されているのだろうか。

3 ソースコードまたは図で評価

どんな難問題も、大規模案件も、その問題の核心を解決する論理は簡単かもしれません。逆に、難問題であればあるほど、大規模案件であればあるほど、核心を解決する論理が単純でなければ、プログラムの構造(architecture)が複雑になり、試験・検証が膨大になり、莫大な経費がかかるかもしれません。

最初の段階で確信の問題を解決するプログラムを書いてみて、そのソースコードを評価する集まりを開いておけば、大規模・長期的・大人数の設計・開発でも、問題を解決する意志を集中させることができるかもしれない。

問題を解決するには、ソースコードばかりでなく、状態遷移図、時系列図、刻時図、利用事例図などUMLで定義している振る舞い図が適しているかもしれない。これらの振る舞い図は、容易にソースコードに変換できるあるいは、仕様記述から生成できるかもしれないため、図から入るのが正解な案件は多数ある。

UMLではなくSYSMLを使えばよい場合もあったり、DSL(Domain Specification Language)で書いた方がいい場合もある。ソースコードではなく仕様記述言語で書いて、ソースコードを生成する場合もある。どの段階で、どの仕様を見直すとよいかのよい習慣を生み出そう。

実物による実演、動画、写真で良い場合もあるし、模擬試験を行っても良い。

ソースコードに全体の構造、動作の説明が書いてあるか、リンクしていないソースコードは読みません。

20180211追記

自分のソースコードに全体の構造、動作の説明が書いてなかった。
追記しました。紺屋の白袴
https://researchmap.jp/jovqfzcc8-1797580/#_1797580

// 1 General
// 1.0 filename: Te_td_accum2.cpp
// ver 0.1, 9(Mon), Oct, 2017
// 1.1 purpose 
// Functional testing, multiple compiler benchmarks and understanding of Template source code
// 1.2 mechanism
// Add code for output of the result of processing to fragment of code on the book.
// This mechanism came from The C puzzle book. https://www.amazon.com//dp/0201604612/
// 1.3 Outcome
// Functionality: Easy to process the function.
// Confirmability: Easy to output the result of processing.
// Comparability: Could compare the compiler differences.

#include <iostream>
#include <string>
#include <cstdlib>

// 2 original examples and/or notes:
// (c) Copyright 2003 "C++ Templates - The Complete Guide" by Pearson Education, Inc. David Vandevoorde, and Nicolai M. Josuttis.  All rights reserved.
// http://www.josuttis.com/tmplbook/

4 HAZOP

HAZOPは、想定外を洗い出すための手法で、プログラミングと親和性の高い手法です。HAZOPで分析すれば、想定外の検出方法をプログラミングしやすいという利点があります。
スライド017.jpg

大小・類部は空間、早遅・前後は時間、
大小・早遅は量、類部・前後は質
大早類前は上限、小遅部後は下限
と8個の概念で、空間と時間の質と量の上限と下限を確認することになる。
大・小、類・部、早・遅、前・後はそれぞれ対称。
無は設計・利用の意図と存在において対称、
逆は方向が対称。
対称ではないのはその他だけ。つまり、世界を三次元および存在と方向において対称な概念を確認する。

しらべ.jpg

想定外の調べかたは簡単。
無は調べた値がゼロかNull。
逆は、方向ベクトルにマイナスをつける。
大は>
小は<
類は集合演算。C言語で書くと工夫が要る。
部も集合演算。ただし、要素が一部であるかどうかを確認するだけで良い。
遅早は、時間の比較。前後は順番の比較。

工夫が要るのは、類と他である。これは、プログラムをしないで、類と他が発送しづらいこととも関係がある。この2つは無限の可能性がある。HAZOPは発散する可能性は、この2つの範囲を決められないことによる。

Hazop Safety and Security at Fukui 201
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-at-fukui-201712
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-at-fukui-201722

HAZOP, Safety and Security with records, SWEST at Gero Gifu pref. Japan
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-with-records-swest-at-gero-gifu-pref-japan

HAZOP, FMEA and FTA for risk assessment.
https://www.slideshare.net/kaizenjapan/hazopogawa2015

5 ソースコード、図、英語以外は対象にしない

ソースコードと図は、相互に変換できる場合がある。先に、ソースコードを見た方が良いか、図から始めると良いかは、その問題の複雑度や、構造の把握ができて要るかどうかによる。

構造が把握できていない場合は、その構造を確認できるプログラムを書いて試験すると良い。プログラムを書かずに問題が解決したり、問題が解けるのなら、プログラムがそもそもいらない問題かもしれない。

6 見直し対象をソフトウェアで検査する

ソースコード、図、英語で書いたものは、ソフトウェアでまず検査する。検査しても見つからない課題だけ人間が考える。
よくソフトウェアで検査すれば5分でわかることを、何人もの人間が集まって1時間も2時間もかけて議論していることがある。検査するプログラムが書けない人たちなのだろうか。

ソースコードをbeautifier等の整形の道具で、タブやコメントの形式など揃えると良い。各自、自己流の書き方をしても、reviewの際は、この道具で検査し、この道具で整形するというやり方が定着していると良い。新しい言語の場合には、自分たちで道具を作る場合もある。

7 時間を区切る

会合は、30分、1時間に区切っている組織がある。その組織の人間の質、量、問題の質、量によって30分がいいか1時間がいいかが決まることがある。厄介な難事件は、3人の班に分けて、2時間かけて3回回すとよい場合もある。問題の複雑度、対応する人の能力、分布に応じて、仕立てる(tailoring)と良い。

4人以上が集まって、2時間以上かける会合なら、最初の15分、HAZOPを実施すると良い。そこに集まった人の興味、能力、意志がわかり、無駄な説明を省くことができたことがある。

参考文献

役に立つデザインレビュー―ソフトウェアにおける考え方と戦略 (実践ソフトウェア開発工学シリーズ),堀内純孝,日科技連出版社, 1992,ISBN 978-4817161093
https://www.amazon.co.jp/dp/4817161094

履歴
ver.1
https://researchmap.jp/jofizy29u-50024/#_50024

ver.2(20170117)

ver.2.1 (20180228)