パスワードを忘れた? アカウント作成
10918297 journal
日記

dotkuwaの日記: QMS試験受けました 4

日記 by dotkuwa

会社でQMSの試験(pdf数十ページのハンドブックを見ながら、問題に答える)を受けました。

ISO 9001に準拠した内容だそうですが、せっかくISO 9001:2008の内容も反映し、"Output Matters"
も踏まえ、レビューの順序などに柔軟性を持たせても良いという記述が有る一方、承認(必須)が
からみ出すと途端に、

・プログラマがプログラム設計書(謎)を作る
・責任者とプログラマがレビューを行い、責任者が承認する
・それに従いプログラムを作る

と言った、ISO 9001:2000から一歩も進歩していない内容になります。レビューし、承認を得られる
「プログラム設計書」とは一体なんでしょうか? 見当も付きません。しかも、このプロセスは必須で、
これを省いたらISO 9001とは間違いなく関係なくなります。

まぁ、ISO 9001も"Output Matters(ISO 9001が提示する品質マネジメントシステムは、要求事項を
満たした製品を一貫して提供し、顧客満足を向上させるためのものであると適用範囲に規定されて
いるにもかかわらず、現実にはISO 9001に適合していると判断されていても要求事項を満たす製品を
提供できないことがある)"について問題意識を持ち、議論中という事なので、ISO先生の次回作に
期待するのが吉かと思います。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by dotkuwa (9387) on 2014年04月26日 11時12分 (#2589326) 日記

    つまり、ISO9000で言っている(個々の組織がテーラリングでそう書いても構わないと許容されている)
    「プログラム設計書」は、

    ・(他国、どう考えてもソフトウェア開発新興国で、レベルの高い達成度を得ていた所)いわゆる
      「設計書」なりの自然な表現力のまま、「プログラム設計書」を書き、合格とジャッジしていた。
     実際にプログラムする方は、(開発者よがりが禁止され、設計書に沿うより仕方なく)途方も無い
     要件のデグレが起きる。(Output Mattersの主因だと、強く思います。)
    ・(#2585357さんが見たと仰っていた)「プログラム」の近似に過ぎない射影体。実際に検証出来ない為、
      全体の50%は間違いで、全体の10%は矛盾の為、それに従うと本質的に解0となってしまう
      (しかし、設計者の権限の強さの為、だれも手出しできず、開発期間の三分の一が浪費されてしまい、
      より権限の強い人がやってきて、やっと開発再開になる。)

    のどちらかだと思います。

    やはり、自然言語とプログラム言語の中間は無いんです。

    • by hig (25417) on 2014年04月27日 9時23分 (#2589605) 日記

      ソフト開発の実態を知らない全くのシロートなんですが、素朴な疑問。

      やはり、自然言語とプログラム言語の中間は無いんです。

      昔ならフローチャートとかあったと思うんですが、今はそんな橋渡しになるようなものは作成されないんでしょうか?

      親コメント
      • by dotkuwa (9387) on 2014年04月27日 10時22分 (#2589613) 日記

        当然個人的見解ですが(それを言い出したらこの日記は全部そうですが)

        フローチャートは違うかも知れませんが、HTMLやXMLなどはよく、半構造文書とか言われます。
        ここでは両者を同じに扱いますが、それらは単に自然言語とプログラム言語が混ざっただけの
        個溶体に過ぎないのではないかと思っています。

        だとどうなるかと言いますと、大規模な文書になったとき、「半構造」の良さがなくなり、自然言語
        寄りになったり、プログラム言語寄りになったりするだけになります。
        フローチャートが「作ってもよいが、いい加減な所で切り上げろ」とか言われる表現なのも、
        そのせいだと思います。

        テスト手法などで、初心者にとって目の覚める様な表現の代表としての、「デシジョンテーブル」
        なども大規模になってくるとそのままでは表現できず、2つのテーブルのクロスジョインで表さなく
        ならなくなったりする事がありますが、それも半構造文書が個溶体に過ぎないのだという傍証に
        なるかと思います。

        橋渡しですが、プログラム言語の設計上の本来のやり方では、インターフェースやパッケージや
        名前空間といった、現状「何の為に有るのか不明」な要素を使うのが想定だった様に想像します。
        (その様なやり方をしている所と言ったら、非古典以前からずっと続いているMS位かも知れません
         が。)

        親コメント
        • by hig (25417) on 2014年04月27日 12時42分 (#2589655) 日記

          現在の超複雑なソフト開発とは比べ物にならないですが、以前お仕事で産業機械の作成を業者に依頼するときに仕様書を書きました。PLC(三菱のシーケンサだったか)
          その時に思ったのが、プログラムを全くできないときに書く仕様書と、曲がりなりにも自分で組めるようになった後の仕様書は全く別物といっていいぐらいの差があったことです。

          後者ではある程度プログラムを想定しながら作成するので、当然プログラム言語寄りになって業者にとっては理解しやすいものとなりますが、肝心の作業の本質を理解しやすいように表現しているとは言えないのが何ともしがたい所です。
          あまり詳細に仕様書で限定してしまうと自由度がないせいか業者から上がってくるプログラムはあまり出来が良くなかったような覚えがあります。(仕様書がヘボいせいですが)

          親コメント
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...