ようこそソフトウェア・メインテナンス研究会へ ソフトウェア・メインテナンス研究会(SERC)は ソフトウェアのメインテナンス(ソフトウェア保守開発)を専門に研究する非営利任意団体として、 1990年12月に誕生しました。 「ソフトウェア保守の諸問題」に関し研究を進めています。 新着情報
ようこそソフトウェア・メインテナンス研究会へ ソフトウェア・メインテナンス研究会(SERC)は ソフトウェアのメインテナンス(ソフトウェア保守開発)を専門に研究する非営利任意団体として、 1990年12月に誕生しました。 「ソフトウェア保守の諸問題」に関し研究を進めています。 新着情報
影響度の大きいソフトウェア変更は怖い例。 カーソルキーで値を設定しなおした際に生じる、線量設定関連のバグで、 改善させるべくソフト修正かけても、過照射の事故がなくならず 死亡事故が続いた怖い例です。 この一件もFDA(日本では厚生労働省に相当)が、ソフトウェアの 安全性確保に対してとても厳しくなったものと思います。 セラック25 [archive.org] 1985〜1987年――セラック25:複数の医療施設で放射線治療装置が誤作動し、過大な放射線を浴びた患者に死傷者が出た。セラック25は2種類の放射線――低エネルギーの電子ビーム(ベータ粒子)とX線――を照射できるよう、既存の設計に「改良」を加えた治療装置だった。セラック25では電子銃と患者の間に置かれた金属製のターゲットに高エネルギーの電子を打ち込み、X線を発生させていた。セラック25のもう1つの「改良」点は、旧モデル『セラック20』の
工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。 考えたことをメモ。 間違っていたら後で直す。 【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。 マネージャの仕事の一つが、月次報告のための工数集計がある。 だが、この工数集計が結構面倒だ。 普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。 しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。 更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。 また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。 特に、本番
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く