(toppers-users 3898) Re: SSPの DEF_ICS のレビュープロセスについて（回答）

[高橋和浩@nifty]

高田様　皆様　アライブビジョンソフトウエアの高橋です。

論点がずれていると思います。
杉本様も同じ方向にずれた回答をされているように思います。

なぜか全体的なソフトウエアの品質管理という話題になっているかと思います。
確かにメーカーさんがするような再発防止策をTOPPERSプロジェクトを
行うことはいいとは思いません。ほどほどの品質のところで公開
そしてフィードバックして品質を向上させていく。というプロセスが
最適だという意見には賛成です。

また、なぜか再発防止という単語、や品質という話になると実装上の動作上
仕様通り動くかどうかという範疇の話だという解釈をされるようですね。

私が言っているのは、仕様の妥当性について検討されていないのではないか？
ということで、具体的には、仕様のレビューをチェックシート使って
やっているかということを質問しています。
特に名称が同じもので違う機能というのはチェックシートで簡単にチェックできると
思っています。
そういう工程を入れてみてはどうかという話です。
あくまで、欠陥ではない、ただユーザーの意見からよりよい仕様に変更します。
ということのようですが、DEF_ICSの件は、ほどほどの品質とは思えない（欠陥）と思うからです。

仕様の妥当性について検討に関するレビュー（チェックシート）これが限られたリソースで実施できない内容でもない　
と思います。JSPなどの少なくとも一部のものは、μITRON4.0検定仕様書に沿って評価されているものか
あると認識しています。なので労力的にも可能な範囲ではないかと思っています。


On Wed, 08 Feb 2012 10:38:16 +0900
Hiroaki TAKADA <hiro ＠ ertl.jp> wrote:

> 高橋様、皆様
> 
> 一般にソフトウェアの仕様策定や実装において、見落としや考えが足りない
> 部分が出るのを完全に避けることはできませんし、これまでのTOPPERSカーネ
> ルの仕様においても、リリースした後に次のバージョンで仕様を見直した例
> は沢山あります。
> 
> 見落としや考え不足をプロセスで補うことはできるかもしれませんが、それ
> にはコストがかかりますし、TOPPERSに適用すると、完成が遅れる（つまり、
> オープンにするタイミングが遅れる）という結果にしかつながりません。
> 
> ほどほどの完成度になったところでオープンにして、今回のようにユーザの
> 皆さんのご意見を聞き、それをフィードバックして改良していくことが、オー
> プンソースソフトウェアにふさわしい開発プロセスだと考えています。
> 
> 別の言い方をすると、企業におけるソフトウェア開発で問題があった場合に
> 再発防止策を講じるのが常道であるのは知っておりますが、そのやり方を、
> 限られたリソースで実施しているオープンソースソフトウェア開発に適用す
> るのは得策ではないと考えています。
> 
> ですので、今回（DEF_ICS）の件で仕様に考慮不足があったとは考えています
> が、皆さんのご意見で考え直すことになったという点でオープンソースソフ
> トウェアの開発プロセスが機能しているわけで、新たな再発防止策が必要で
> あるとは考えていません。
> 
> 高田広章
> 名古屋大学
> 
> (12/02/08 10:08), 高橋和浩@nifty wrote:
> > 斎藤様　皆様　おはようございます。
> > 
> > アライブビジョンソフトウエアの高橋です。
> > 
> > 要約しますと
> > 1.欠陥ではなく仕様変更です。
> > 2.ユーザーが使い方を誤解するケースがあったと思う
> > 3.レビューはちゃんとやったし、プロセスに問題無しです
> > 4.特に再発防止策はないです。
> > 
> > 4は自分が追加して書きましたが、誤用つまり欠陥ではないので
> > 再発防止そのものが無いのは当然かもしれません。
> > 
> > なので、今後も、ASP等の別の実装と同じような機能のものが移植された場合に
> > 同じ問題が、いや正確には、同じようにユーザーが誤解するケースが起こるかも
> > しれないということですね。
> > 
> > 
> > On Mon, 06 Feb 2012 23:02:31 +0900
> > Naoki Saito<nsaito.nmiri ＠ gmail.com>  wrote:
> > 
> >> 高橋様，みなさま
> >>
> >> 斉藤です．
> >> どうもお答え出来ていない気がしたもので．
> >>
> >>>>> レビューといっても仕様のレビューではなく、実装のコードレビューかなに
> >>> かですか？
> >>
> >> 前回のメールにも書きましたが仕様のレビューとコードのレビューの
> >> 両方を実施しておりますが，DEF_ICS の話題に関しては，
> >> 仕様のレビューの話だと思います．
> >>
> >>>>> 結果的にはレビューしているけど抜けたという感じですか？　最初から用語
> >>
> >> 抜けたのではなくて，あえて DEF_ICS を共有スタック領域の静的API として
> >> 流用するという仕様をレビューにかけました．
> >> その点について，互換性の問題等も話題になったと思いますが，
> >> 結果的に強い異論は出なかったということです．
> >>
> >> 以上，よろしくお願いします．
> >>
> >>
> >> (12/02/06 19:28), Naoki Saito wrote:
> >>> 高橋様，みなさま
> >>>
> >>> 斉藤です．
> >>> お返事が遅くなってしまいました．申し訳ありません．
> >>>
> >>>> 1.スタックは、一本のスタックのみ存在する（スタック共有）。
> >>> （略）
> >>>> 7.この計算値は、狭義の省スタック化を踏まえて合計した値である。
> >>>
> >>> はい．仰る通りです．まとめていただいてありがとうございました．
> >>>
> >>> ----
> >>> それから，開発プロセスのご質問の件につきまして，
> >>> 杉本さんから回答いただいておりますが私からも少し補足します．
> >>>
> >>> 私自身からはTOPPERS全体の話を回答できる立場でもありませんので，
> >>> あくまでもSSPでの話に絞ります．
> >>>
> >>>>> DEF_ICSのレビューのことですよ。
> >>>>> レビューといっても仕様のレビューではなく、実装のコードレビューかなに
> >>> かですか？
> >>>>> 結果的にはレビューしているけど抜けたという感じですか？　最初から用語
> >>> の間違いでICSの用語の誤用であり、レビューで指摘しやすいような
> >>>>> 内容かと思いますレビューのチェックシートを作って互換性という項目や機
> >>> 能の用語に誤用がないかを入れれば間違いは無かったように
> >>>>> 思いますが、後の祭りですかね。
> >>>
> >>> （屁理屈といわれるのを承知で申し上げますと）誤用というより流用です．
> >>> ただし，今回の議論でもご意見をいただいたように誤解を生みますし，
> >>> 今後は元の意味で用いるように戻す方向で検討しています．
> >>>
> >>>>> レビューは実際にはコード／仕様いずれかですか？　レビューの際のチェッ
> >>> クシートなどは利用していませんか？
> >>>
> >>> コードも仕様も両方レビューを実施しています．
> >>> レビューの観点については実施前に確認してから行いました．
> >>> チェックシートのようなものは利用していません．
> >>>
> >>> 杉本さんからのメールにもありますがテストは実施しています．
> >>> それでも完全というのは難しいですので，MLにてご意見頂けるのは
> >>> 大変貴重機会でありがたいと思っています．
> >>>
> >>> 以上，よろしくお願いします．
> >>>
> >>> (12/02/01 13:45), 高橋和浩@nifty wrote:
> >>>> 斎藤様　MLの皆様
> >>>> アライブビジョンソフトウエアの高橋です。
> >>>>
> >>>> 長々とお付き合いいただきましてありがとうございます。
> >>>> MLのカーカイブを見て結論がわかるようにタイトルを変えておきます。
> >>>>
> >>>> 1.スタックは、一本のスタックのみ存在する（スタック共有）。
> >>>> 2.そのスタックは、DEF_ICSで定義すれば、その値のスタックが確保される。
> >>>> 3.DEF_ICSがない場合は、DEFAULT_ISTKSZ マクロの値でスタックが確保される。
> >>>> 4.DEF_ICSもDEFAULT_ISTKSZも無い場合は、エラーになる。
> >>>> 5.設定するサイズについては、全タスクの使用サイズとカーネルおよび割り込みの
> >>>> サイズ合計をユーザーが設定する必要がある。
> >>>> 6.全タスクの使用サイズは、参考用にkernel_cfg.cのMaximum Task Stack Sizeと
> >>>> 記載のある部分にCRE_TSKからの計算値がコンフュグレーターが出力する。
> >>>> 7.この計算値は、狭義の省スタック化を踏まえて合計した値である。
> >>>>
> >>>> ですね。
> >>>>
> >>>> ------------------------------------------------------------------
> >>>> すいません、まだ回答いただいていないことがあったようです。
> >>>>
> >>>>> Q3.設計思想の件その１
> >>>>>>> Q2.設計思想の件その１
> >>>>>>>>> 2.TOPPERSの会員内のレビューで議題にあがっいなかったのでしょうか？
> >>>>>>> は、回答が難しいのでしょうか？
> >>>>>>
> >>>>>> いえいえ，難しくはありません．
> >>>>>> ご質問にお答え出来ておらずすいませんでした．
> >>>>>> SSP仕様レビューという議題の中で DEF_ICS のレビューの際に
> >>>>>> ついでに議論されました程度で，最初から議題に挙がっていたわけでは
> >>>>>> ありませんでした．
> >>>>>
> >>>>> DEF_ICSのレビューのことですよ。
> >>>>> レビューといっても仕様のレビューではなく、実装のコードレビューかなにかですか？
> >>>>> 結果的にはレビューしているけど抜けたという感じですか？　最初から用語の間違いでICSの用語の誤用であり、レビューで指摘しやすいような
> >>>>> 内容かと思いますレビューのチェックシートを作って互換性という項目や機能の用語に誤用がないかを入れれば間違いは無かったように
> >>>>> 思いますが、後の祭りですかね。
> >>>>> レビューは実際にはコード／仕様いずれかですか？　レビューの際のチェックシートなどは利用していませんか？
> >>>>>
> >>>>
> >>>> ここのMLにはなんの回答義務も無いので無視されてもかまいませんが、
> >>>> 利用ユーザーとして、どのような開発プロセスを経て作られたものであるかは大変興味のあることです。
> >>>> 仮に、「本業ではありません」という回答もあったかと思いますが、副業的に開発されて、レビューもしっかり
> >>>> 行われていないものだけど、ソースが公開されているので、自力でデバッグしながら使ってください。
> >>>> というものであったとしても非難できる立場でも無いと思っています。
> >>>> ユーザーが安心できる回答をお待ちしています。
> >>>> ---
> >>>> アライブビジョンソフトウエア株式会社
> >>>> 高橋和浩
> >>>> 673-0005兵庫県明石市小久保2-2-7幹線ビル4F
> >>>> Email:takahashi_kazuhiro ＠ nifty.com
> >>>> http://homepage3.nifty.com/ALVS/
> >>>
> >>
---
アライブビジョンソフトウエア株式会社
高橋和浩
673-0005兵庫県明石市小久保2-2-7幹線ビル4F
Email:takahashi_kazuhiro ＠ nifty.com
http://homepage3.nifty.com/ALVS/