タグ

Developmentと保守に関するItisangoのブックマーク (3)

  • ソフトウェア・メインテナンス研究会

    ようこそソフトウェア・メインテナンス研究会へ ソフトウェア・メインテナンス研究会(SERC)は ソフトウェアのメインテナンス(ソフトウェア保守開発)を専門に研究する非営利任意団体として、 1990年12月に誕生しました。 「ソフトウェア保守の諸問題」に関し研究を進めています。 新着情報

  • とある企業の基幹システム、1行の改修に1ヶ月をかける | スラド IT

    影響度の大きいソフトウェア変更は怖い例。 カーソルキーで値を設定しなおした際に生じる、線量設定関連のバグで、 改善させるべくソフト修正かけても、過照射の事故がなくならず 死亡事故が続いた怖い例です。 この一件もFDA(日では厚生労働省に相当)が、ソフトウェアの 安全性確保に対してとても厳しくなったものと思います。 セラック25 [archive.org] 1985〜1987年――セラック25:複数の医療施設で放射線治療装置が誤作動し、過大な放射線を浴びた患者に死傷者が出た。セラック25は2種類の放射線――低エネルギーの電子ビーム(ベータ粒子)とX線――を照射できるよう、既存の設計に「改良」を加えた治療装置だった。セラック25では電子銃と患者の間に置かれた金属製のターゲットに高エネルギーの電子を打ち込み、X線を発生させていた。セラック25のもう1つの「改良」点は、旧モデル『セラック20』の

  • ソフトウェア開発の工数見積もりが混乱しやすい理由 - プログラマの思索

    工数見積もりしていると、同じ人月で数えているのに、コストだったり、システム規模だったり、出来高だったり意味が違っているのに気付いた。 考えたことをメモ。 間違っていたら後で直す。 【1】運用保守では、顧客に毎月の実績工数を報告して保守料金をもらう。 マネージャの仕事の一つが、月次報告のための工数集計がある。 だが、この工数集計が結構面倒だ。 普通はメンバーに毎日の日報で、どのタスクにどれだけの時間をかけたのか、報告してもらう。 しかし、普通はタスクは顧客の改善要望をWBSレベルで詳細化したタスクのため、まず要望別に集計し直さないといけない。 更に、顧客からの改善要望のステータスが未着手なのか、進行中・完了なのか、逐一記録して、追跡しないといけない。 また、それら要望は、問合せ調査だったり、定常的な運用作業だったり、障害対応や改善対応などの種類に分けて、それぞれで集計し直したい。 特に、

    ソフトウェア開発の工数見積もりが混乱しやすい理由 - プログラマの思索
  • 1