保守について学習。
前回の記事。
"前記JIS規格によると、ソフトウェアの保守には6つの種類がある[JIS08a]。その全体像を図表33-1に示す。"
こちらから無料で読み始められます:https://a.co/eBh3QEM
今回初めてISO/IEC 14764:2006で定義される保守の構造がわかった。
訂正: reactive
- 是正保守: reactiveの中のreactive
- 緊急保守: reactiveの中のreactiveのさらに緊急
- 予防保守: reactiveの中のproactive
改良保守: proactive
- 適用保守: proactiveの中のreactive
- 完全化保守: proactiveの中のproactive
訂正はバグで、改良はwishと考えると非常にしっくりくる。
①保守に必要な成果物の引き継ぎ
②問題把握及び修正の分析。他の解決法の検討・提案
③修正の実施
④保守レビュー及び／または受入れ
⑤運用テスト及び移行の支援
⑥業務プロセス改善の提案
こちらから無料で読み始められます:https://a.co/50G5Y4H
ふーむ。共通フレーム2013の「4.7 問題解決プロセス」から「2.6 保守プロセス」を呼び出しているのがヒントになるかもしれない。
"1つのチームが新規開発と保守の両方を担当するのは良くない。保守作業は常に、新規開発よりも優先順位が高い。したがってこの両方を同じチームが担当していると、新規開発が保守作業の影響を受けてスケジュール遅れをきたすことが多い。これが原因して、品質面に影響が出ることもある。これらはいずれも、新規開発では避けなければならないことである。"
こちらから無料で読み始められます:https://a.co/2PHMp0H
いわゆるstream-aligned teamとは真逆のことを言っていると思うのだが、全てはいいようだなと思う。また、保守のアウト・ソースが非常にチャレンジングな領域であるというような言及の仕方をしていて、なかなか面白い。
