品質に関連する単語の検索結果にリンクを、貼って見ます。
品質、クォリティー、
69(sixnine quality)
ソフトウェアの信頼性
では、どのようにして、求める品質を達成し、維持するか
品質管理、クォリティーコントロール、QC、TQC
ちょっと話題を変えますが
「入門仕立てのプログラマ1年生」、「独学個人プログラマ」と言う場合、最初は品質管理なんて、考えもしないかも知れません。
ここで、演算誤差について検索した結果を張り付けてみます。
また、プログラムで文字を扱うシーンも、結構有ると思うのですが、自分で「文字コード体系を判別するアルゴリズムを構築する」とか、そのルーチンを書くと言う人は案外少ないと思います。既に提供されている機能の中でやってもらうことが多いと思うのです。
つまり、自分がソフトを組んだとは言え、生産物で有るソフトの挙動のすべてを熟知している訳ではなくて、提供された機能を利活用しているに、過ぎない事は往々にして有りますから、「文字コード判別」に関する詳細な知識を持って居ないことも多いと思います。だから、プログラムを書いた人物だから、この人物がすべてを掌握していると思うのは、早合点と言うものです。
私自身、BASIC言語で趣味のプログラムをやり始めた頃は、「品質」とか何も考えませんでした。思いついたアイデアを、コーディングして、動かしてみて、エラーが出たら、デバッグして、バグがほぼ消えたら。それで終わり。でした。自分の求めるプログラムが組めて、目的が達成できたので、品質とか特段考えませんでした。
自分のやりたいことを、実現できる言語との出会いがあれば、「自分に不可能は無い」と思い始めたりします。実際それで、収入につながれば良いのですし、問題にも遭遇しないなら、問題は無いのでしょう。
けれでも、そうは、簡単では有りませんでした。他人様に、使っていただくものを書く様になり、品質と言う壁を意識し始めました。と言いますか・・・、外から品質についての要求を突きつけられました。と言うか、ソフト製造に関する教育を受けられた方であれば、ソフトウェア製造に関する品質管理に関する教科を習われたと思います。
結構面倒くさい内容です。自分や、自分たちの製造するソフトウェアに関する資料を、初期検討資料から、概要設計書、詳細設計書、ソフトウェア仕様書、ソースコード、そして、生産物、そして、品質確認検査の項目リストに検査結果に至まで全部、製造開始から完了と判断されるまでに発生したバグのリストやバグ発生件数やバグ収束の推移や、なにやから全部。が品質管理（クオリティー・マネジメント）の対象になり、品質判断の材料になります。
これらの資料は通常は「部外秘」でしょう。つまり、よそのソフトについて、自分が何の権限も有していない場合、閲覧も存在すらも、知り得ない資料達です。
デバッグは、この一連の膨大な開発関連設計資料を、所有または読みこなす事が出来ないと、かなり辛い状況だと言えると思います。
さらに、自分達が開発に用いるプログラム言語の仕様やコンパイラの仕様について、関連するミドルウェアや、動作環境であるOSの内部処理に関する、熟練度を上げておかないと、デバッグに於いて、内部処理のどんな挙動の結果、問題の発生に至っているのか、推論が困難です。
目の前に、厳然と問題が居座って居ても、その発生原因を推論・特定するには、とても高度な経験と熟練と、知識が必要とされます。
さて、何らかのソフト製品や、IT製品に、バグは潜んでいるのだろうか？。とか、スパイ行為に類する挙動が含まれているのだろうか？。とか、製造上の不注意や、間抜けな事柄の結果、ダダ漏れ状態が発生する条件が見過ごされては居ないか？。等について、知りたいと言う要求がある場合、それはとても大変な、そしてとても困難な要求事項なのだと、理解出来るでしょうか？。
有名なパソコンソフトの会社の製品の場合、過去には良く、製品版が発売される前に、α（アルファ）バージョン、β（ベータ）バージョン、等が出されることが多かったと思います。
有名ソフト会社の社長さんの伝記か何かで、次のような内容を読んだ事がありました。
いわゆるIBM-PC/AT互換機（DOS-Vマシンと呼ばれていたことも有る）のソフトを販売する場合、市場に稼働するPCは、マザーボードも各種メーカーが有り、各種バージョンがあり、そのマザーボードに搭載されるCPUも型番も様々で、メーカーもIntel以外のメーカ製CPUの場合も有り、メモリーも同様に各種メーカー製品があり、搭載されるサイズも様々、グラフィックプロセッサのメーカーも型番も様々あり、ストレージも、一時記憶媒体も様々、モニター画面も様々なので、想定される組み合わせのバリエーションを社内の検証チームが取り揃える事が、とても大変だと書かれていました。
世の中に存在するバリエーションを考えると、無限とも言えそうな膨大な数のバリエーションが存在するので、社内で検証マシンを揃えるにも、おのずと限界が有る。そこで、世間に対して、製品概要を知ってもらうため、初期にαバージョンが出されて、その後製品の品質を問うシーンで、βバージョンが出て、それで発見された問題に対処を入れてから、製品版が販売されるという流れだったと思います。
でも、最近はαバージョンとかβバージョンを聞かなくなりました。
「品質確保の手法について、最新のやり方であれば、もう今は、大丈夫なんだよわっはっは。」と言われると、言い返す言葉はありません。
確かに、ダウンロードして動かせば、ほぼ問題なく動く場合が多いです。
でも、私個人としては、理屈が判りません。
この部分です。「理屈が判らない」と言う部分。
「自分できっちり修行する」か、「他人に任せる」か「どうでも良いや」の、どれかになります。
ソフトをやっていると、自分にも他人にも「間抜け」を見る事が有ります。
「バグ収束曲線」と言う言葉が、ソフト業界には存在します。これは、バグ退治をしていくと、限りなく含まれるバグの数が０に近づいていくという曲線です。そうです、限りなく０に近づくのですが、０には永遠にならないという曲線です。つまり社内検証設備で散々検証しても、世間に出すと、バグが報告されてくるという奴です。ソフト業界の人はほぼ全員がしっていると思いますけど。(こちらのサイトなど: URL : http://ameblo.jp/pictmaster/entry-12066538197.html)
散々バグと格闘した後、「もうこれでバグは無いよね！」と言われると、人間とは弱いもので、「何言ってんですか？。バグがゼロになんか成る訳け無いじゃないですか！」なんて、言えなくて、「もう有りません。」と言ってしまいがちです。そして、後日「バグ発生で呼びつけられる」と言う間抜けな事態に陥ってしまう。
とても大事な事柄について、自分の手に負えないので、誰かに責任を押し付けて、それで解決出来た事にする。と言うのは頭が良いのか間抜けなのかが、判りませんけど、結果的にはそう成らざるを得ない事もあるかもしれません。
作り話１
「明日、私自身が溶岩の中に入って、火山内部の様子を見てくる事にした。その作業で、私にもしものことが有ったら、ナンバー２である、君に後の事一切を任せることになるが、よろしく頼む。あ、それと、溶岩の灼熱に耐える耐熱スーツの調達は、私には出来ないので、ナンバー2である君が責任を持って今日中に調達してくれたまえ。任せたよ。」
変な話でしょ、間抜けというか、あり得ないというか、でもしかし、個人の能力には限界が有って他人に頼らざるを得ない事が実在するのも事実ですし。
世の中、持ちつ持たれつで何とかやっている訳です。
持ちつ持たれつで、やっとこさっとこ何とかやっているのに、反目し有ったり、競い合ったり、敵対してみたり、抜け駆けしてみたりしているのも有ると思うんです。
ソフトって、良く判らない。誰かわかっている人、私に分かり易く、簡単に教えてください。
でも、「自分で精進しろ」とか「自分で修行しろ」と言われるのが落ちですね。
海外映像で、小さな手漕ぎボートに、大きな冷蔵庫を載せて運んでるのが有りましたが、アクロバティックですねー。誰にでも出来る芸当じゃない。安易に真似をすると怪我をする。または、荷物を水没させて損害を発生させてしまう。
それに、載せても丈夫なのか？。どういうものなら、載せても問題は起きないのか。良く考えてから、載せないと、何かが、想定外の何かが待っているかもしれない。
数学的、統計的、経験的、科学的、そう言うきっちりとした根拠に基づく、正しい推論または、見通しなのか。その逆の「盲信」「迷信」「思い込み」「勉強不足」「経験不足」「注意不足」「考慮不足」「配慮不足」とかそういう物なのか、もしそうなら、どこかでそう言った不確実性要素を排除しないといけないのですが。それを、他人に任せざるを得ないと言う場合。「信頼する」しかない。訳ですが、「信頼をした」けど後で、「勉強不足でした」「思いもつきませんでした」と言う場合、どうしろと言うんだ。と言う事態になります。
こうなると「あきらめる」以外に無いかも知れなくて。
「ITとかソフトとか、コンピュータについて、それは、経費節減ツールなのか？」と言う命題に対して、正直に回答をするなら「ITとかソフトとかそういう一切の物は、地道に精進をやりだすと時間も金も、かなりかかるものです。」と言う回答になる場合が多いのではないかと思います。
「でも、ITって便利だし、お手軽だし、すっごくいいじゃん」と言う意見も多いと思うんです。
「すべての人類のプライバシーが確保されなく成るかも知れない、と言うリスクは存在する。けれども、ITは便利。」
例えば、貴方が、貴方の奥さんの「もの凄いことを、知り得てしまったけど、コンプライアンスがあるので、自分の奥さんではあるが、切り出すことは法律違反になるので言い出せない。」とかその逆とか。
また、上記のもの凄い情報が事実ではなくて、たまたまシステム上、あたかも事実のように見えてしまった場合も有るかもしれません。その場合は不幸ですね。
さらに言うなら、クラッキングによる悪意により、そう思わされてしまう事態が発生してしまったら、不幸とかそういう次元ではなくて、犯罪ですから、きっちり検証して、作り込まれた嘘の情報であることを明確化する必要があるのですが、それには、相当深くシステムに精通している必要が有ります。詰まり、相当時間きっちり修行して置かないといけないと言うことです。これは悲しい事実です。
また、法制度や条例が、きちんと考えられて居て、コンプライアンス違反に対して、きちんと歯止めがかかって居る国家や場所だけを、情報が流通する仕組みを作るのは大変なのです。
情報通信に於いて、端から端まで、自分が所有する設備または自分が製造した設備で構築するのは、経費的に、現実的では有りませんから、いずれ他人の設備のお世話にならざるを得ないのですが、他人がしでかした事の責任を自分が背負得るか？と言えば背負えない。自分が他人の通信の中継をするポジションに立つ場合、例えば、遊びに来た友人に、自宅Wifiを解放してあげるシーンで、自宅から先の、プロバイダーや、その先の通信業者や、友人の通信先の設備に起因して発生した、何らかの問題について、貴方が何らかの責任を背負う必要はあるのか？。と言う命題に於いて、どうお考えに成りますか？。
個人として、ITを嫌って、山中に逃避行する事も出来ないし、既存の社会システムから抜け出して、いき伸びることも困難。
と言う状況なのではないのでしょうか。
ぶっちゃけて言えば、近年より先の未来に向けて、プライバシーとか価値観とか、パラダイムがシフトしていく、つまり、労働や報酬や、価値の分配において、パラダイムがシフトした。
でも、トイレ掃除は誰かがやらないといけないし、古いインフラの下水/浄水の配管は修繕しないといけないし、家もビルも経年劣化してくるし、誰かが、直しつづけないといけない。
じゃ、ロボットにやらせるか？。と言う事になると、ロボットこそ、ITの最たるものでしょ。危険性はないのか？誰が、学術的に理論を構築するのか、現物の検査を行うのか、検証能力を学び身につけるのか。
自分のコミュニティーで、天才を育成できない場合、世界で天才が生まれてくれることを待たざるを得ない。はずですけれど、世界がいがみ合っていたら、天才の育成と共有が出来なくなって、そうすると、自分たちの今後のライフオブクオリティーは上昇しない。事になりかねない。ので、昨今、市民は、バカではいけないなぁとは、思いつつ、自分自身を振り返れば、資格の一つも取得するに四苦八苦していて。
大変だなー、みなさん、おねがいしますよー言う感じです。
追伸
ITに関して、品質や信頼性などと言う場合、壊れにくさや、誤動作や誤差やエラーが起きない度合いについて着目することが主です。又は不幸にして故障やエラーが発生した場合の停止時間の少なさや、リカバリについて、いかに考え抜かれているかや、どれ位バックアップシステムを地球上に分散配置していて、データ消失への備えをしてあるか等が大事になります。
また、大規模災害などにより、WEBシステムなどが、バックアップシステムに切り替わったからと言って、URLが変わってしまうと、アクセス出来なくなるユーザーが出たりしますから、ユーザーがシステム切り替えに気付かないくらいに、URLの変更も無く、スムーズに切り替わるのが、求められたりするんじゃないかなと思うんです。
しかし、一般利用者はWEBシステムなどの場合、ふだんは故障しにくさより、「データ漏洩がない度合い」を求めたりします。
不条理な話に思えます。システムをBiosから、OSから、ミドルから、アプリケーションまで、全て自分又は自分達で、設計製造、検証するのはかなり困難です。だから、よそのソフトウェア製品を使わざるを得ないと思うのですが、
品質確認や、信頼性確認の為に、閲覧したくても、よそのソフトウェアの設計書は部外秘で見せてはくれないでしょうし、閲覧させて貰うには、ライセンス契約などで莫大な費用が必要になるでしょうし、仮に設計書を入手出来ても、読こなせないと意味がないし、保管も厳重にして置かないと、まずいでしょうし。
なので、端的な話、結果として、「該当システムのデータ漏れませんよ度合い」は、どうやって確保し、どうやって測定したらいいんだろう。と言う話。
スタンドアロンてか？。
クローズドネットワーク(閉域ネットワーク)にして、インターネットと、隔離するてか？。
チューナーカードをクリーニングして、差し込み
このチップは、I/Oコントローラだそうです。
