JIS X 0161:2008 ソフトウェア技術―ソフトウェアライフサイクルプロセス―保守 | ページ 6

22
X 0161 : 2008 (ISO/IEC 14764 : 2006)
する環境に適応させるために必要な修正である。適応のための修正は,新しいシステムインタフェース,
新しいシステム又は新しいハードウェアの要求事項を実現するための修正を含む。完全化のための修正は,
ソフトウェア製品の性能又は保守性を向上させるためのものである。完全化のための修正は,利用者のた
めの新機能改善の提供を必然的に伴い,また,これまで存在しなかった保守文書の作成のためのリバース
エンジニアリング又は現行文書修正のためのリバースエンジニアリングの提供を必然的に伴う。
  ソフトウェア保守は,現行の構造又はシステムの修正を必要とする。例えば,ソフトウェア修正は現行
のアーキテクチャに対して行われ,設計構造によって課せられた制約を考慮するはずである。このように
適応及び完全化保守の形態での改良は,しばしば多大な費用及び時間を消費する。改良は,保守費用のか
なりの部分を占める。

6.3 保守の段取り

  取得者は,開発元が保守を行う合意を締結してもよいし,第三者が保守者になってもよい。また,保守
は,内部での二者間合意によっても提供可能である。
  保守サービスモデルは,合意されていることが望ましい。このモデルは,すべての型の保守を対象とし,
費用及び資源の総計が当初の固定価格を超えない範囲であれば,新規開発を含むことが望ましい。責任者
は,どの型の保守が含まれているかを識別することが望ましい。
  なお,包括契約は,固定価格で作成されることが望ましい。推奨契約形態は,次のものがある。
− 形態1 : 総保守費を固定した一括契約である。これにはすべての型の保守を含み,かつ,新規開発を
             含んでいてもよい。
− 形態2 : 保守の個別契約である。典型的には合意した期間での是正保守がある。予防保守,適応保
             守,完全化保守は,通常それぞれ別に契約を結ぶ。
  JIS X 0160は,取得者と供給者との間の合意締結を導くための詳細なタスクを提供する。これは,取得
者と供給者とが同じか又は異なる組織であるかにかかわらず,保守合意締結を導く助けに使用されること
が望ましい。これらの契約は,しばしばサービスレベル契約 (SLA)と呼ばれる。特定の保守問題について
は,後ほどで示す。
  取得者が,引渡し後又は保証期間終了時に,ソフトウェア保守を開発者に要求する場合には,合意書に,
このことを明文化することが望ましい。更新された文書を納入するよう,契約の中で明文化することが望
ましい。教育訓練も,同様に明文化した方がよい。その後,供給者は,保守タスクのための手続を準備し,
これらの手続を最新に維持し,活動が合意要求事項及び準備した手続に適合しているかどうかを確認する
ことが望ましい。経験的データは,当該手続の使用が,費用対効果が高いことを示している。保守すべき
項目,保守の手続及びそれらの保守のための時間は,保守計画の中で規定することが望ましい。
  供給者(保守者)及び取得者は,保守合意締結について合意し,保守対象ソフトウェア製品に修正を取
り込む手続を明記することが望ましい。保守者が開発元及び第三者である場合にも,同様の手続が利用さ
れることが望ましい。
  これら手続には,次を含む。
− ソフトウェアが局所的に訂正できる時期,又は導入及びリリースのためにJIS X 0160の開発プロセス
    を用いている新しいベースラインが必要となる時期を決定するための基本ルール
− 頻度又はソフトウェア運用に影響するリリースのタイプの記述(例えば,緊急リリース,定期的リリ
    ース)
− 現在又は将来の修正の状態について取得者に知らせる方法
− 変更がソフトウェアに新たな別の問題を発生させないことを確認する手法

――――― [JIS X 0161 pdf 26] ―――――

                                                                                             23
                                                                X 0161 : 2008 (ISO/IEC 14764 : 2006)
− 修正の分類は,次のとおりである。
  a) 大規模・小規模
  b) その他の特徴 修正がどのように認証され,処理され,そして承認されるかの区別

6.4 保守ツール

  ソフトウェア保守費用を抑える可能性のある方法は,CASEツールの使用である。これらのツールは,
ソフトウェア保守の作業を助ける。CASEの潜在的な性能は,ソフトウェア開発及び保守のすべての局面
を支援する相互に関連したツールのセットである (ISO/IEC TR 14471)。これらの相互に関連したCASEツ
ール群は,ソフトウェア保守の作業を支援する手法,方針,指針及び標準をソフトウェアエンジニアリン
グ環境(SEE)の形式にまとめ上げることが望ましい。ソフトウェアテスト環境(STE)も,また修正したソフ
トウェア製品を非運用環境でテストすることができるように保守者のために提供されることが望ましい。
SEEは,最初に,ソフトウェア製品を開発し,かつ,修正するためのツールを提供する。STEは,テスト
環境を提供する。STEは,修正したソフトウェア製品を非運用環境でテストするために使用するとよい。
  これまでのところ,CASEツールの導入は,十分でないところもある。保守者は,CASEツールの導入
を慎重に計画することが望ましい (ISO/IEC TR 14471)。ISO/IEC TR 19759は,ツールに関する補足情報
を提供する。

6.5 ソフトウェア保守の測定

  ソフトウェア品質は,ソフトウェア製品の保守の重要な考慮事項である。保守者は,JIS X 0129-1に規
定されているソフトウェア品質の6特性を含むソフトウェア品質計画をもつことが望ましい。JIS X 0160
追補1 (F.3.1.6)による測定プロセスが,ソフトウェア保守のためのソフトウェア測定の特定,定義,選択,
適用,妥当性確認及び改善のために,実装されていることが望ましい。JIS X 0141は,測定に関する補足
情報を提供する。
  ソフトウェア測定の一部として,保守者は,是正保守,予防保守,適応保守及び完全化保守のための作
業工数を(費やす資源について)割り出すのがよい。保守プロセスの改善を促進し,保守費用が何に費や
されているかを,よりよく理解するために,データを収集し,分析し,解釈することが望ましい。ライフ
サイクル費用の見積りを助けるために,更に必要であれば,ソフトウェア製品の品質問題及び次期ソフト
ウェア製品に対する開発者のプロセスの改善に対して何ができるかを説明するためにも,実証的測定デー
タを集めることが望ましい。

6.6 プロセスの文書化

  ソフトウェア保守プロセスの詳細(箇条5を参照)は,すべての保守要員が同じプロセスに従うように
文書化することが望ましい。測定値によって,プロセス及び関連するソフトウェアプロセス改善作業を支
援することが望ましい。

6.7 開発への早期参加

  これまでのデータによれば,ソフトウェア保守費用及び保守者のソフトウェア保守を行う能力は,ソフ
トウェア開発プロセスにおいて,何が発生したか,又は発生しなかったかに大きく影響を受けていること
を示している。多くの場合,契約又はその他の理由で,保守者は開発に参画できない。特に,保守が第三
者に外部委託される場合は,開発に参画する機会は多くの場合,全くない。開発中に保守者が参画するこ
とが可能ならば,参画することが望ましい。
  保守者によって実施される機能には,次を含めるとよい。
− そのソフトウェア製品を支援する業務を計画する。
− 知識引継ぎを計画する。

――――― [JIS X 0161 pdf 27] ―――――

24
X 0161 : 2008 (ISO/IEC 14764 : 2006)
− そのソフトウェア製品の保守性を確実にする。
− 開発から保守へのソフトウェア製品の引継ぎ計画立案を支援する。
  計画については,この規格の7.3で詳しく示す。保守者のプロジェクトへの早期参画は,ソフトウェア
の保守性要求を明らかにし,確立し,提示することに役立つ。JIS X 0129規格群は,保守性及び他のソフ
トウェア品質特性を明示的に定義するために使用するのが望ましい。保守性は,保守者がJIS X 0160の支
援ライフサイクルプロセスの品質保証,検証及び妥当性確認のプロセスに参加することによって改善でき
る。保守者は,次のことを実施するのがよい。
− レビューに参加する。
− コード分析を行う。
− 要求事項の追跡をする。
− 検証及び妥当性確認を行う。

6.8 保守性

  ソフトウェアの保守性及び保守は,ディペンダビリティの重要な側面である。保守性は,取得者,供給
者及び利用者にとって,ソフトウェアの重要な特質である。保守性要求事項は,JIS X 0160の取得プロセ
スの開始アクティビティに含まれ,JIS X 0160の開発プロセスを通じて評価することが望ましい。設計の
変化が,保守性への影響を与えることについて,開発を通して監視することが望ましい。ソフトウェアの
品質を定義し,評価するために,複雑度測定値を含む,様々な測定値を用いることが望ましい。定性的及
び定量的評価がともに重要である。ソフトウェアの解析性,変更性,安定性,及び試験性を扱う四つの保
守性の副特性がある。これら四つの特性が,作業(速さではない。)及びソフトウェア修正の容易さに影響
する。
6.8.1  保守性及び開発プロセス
  非機能的要求である保守性要求は,ソフトウェアプロジェクトの早い段階で作成及び合意しておくこと
が望ましい。ソフトウェアが第三者から取得されるとき,JIS X 0160の開始アクティビティの一部として,
取得者と供給者との間で,保守性要求水準の取決めがなされることが望ましい。
  保守性の基準(又は目標)を監視し,評価するための能力は,各々の要求について特定し,ソフトウェ
ア開発中に作成するのがよい。この能力によって,顧客が定めた定性的及び定量的なソフトウェア保守性
の要求事項を記述する。これによって,基準及び検査法を定義する。定性的要求事項(例えば,使用性,
保守性)は,保守の見積り及び資源を準備するために用いる技法を定義するために利用する。定量的要求
事項は,保守性の評定,評定水準又は品質基準及び測定値を定義するのに使用され,様々なソフトウェア
のライフサイクルの段階を通じて,数値又は指標を決定するために用いる。
  指定された保守性の副特性は,ソフトウェア開発期間中にレビューし,制御することが望ましい。保守
者による保守性の妥当性検証を確実なものにするための見積り工数は,保守戦略文書の中に規定されるこ
とが望ましい。開発者は,保守性の要求事項を実現し,保守者は,その実施を監視することが望ましい。
この作業は,保守戦略の一部である。
  JIS X 0160を適用するためのかぎ(鍵)となる一つの要因は,保守戦略(ISO/IEC TR 15271, Guide for
ISO/IEC 12207)の策定である。それゆえ,保守戦略を策定し,保守を計画することが望ましい(箇条7
を参照)。
  保守戦略は,また,設計前に確立するとよい。初期に保守者が,ソフトウェアプロジェクトに参画する
ことで,保守費用の節減につながる可能性がある。ソフトウェア保守計画を含めて,開発プロセスの間に
多くの行為が行われる。これらの行為は,保守計画に文書化することが望ましい(7.3.2を参照)。

――――― [JIS X 0161 pdf 28] ―――――

                                                                                             25
                                                                X 0161 : 2008 (ISO/IEC 14764 : 2006)
  保守性は,アーキテクチャ,設計,コーディング及びそのプログラム言語,並びにテストアクティビテ
ィに影響される。ISO/IEC TR 19759は,保守性を高めるために,よいアーキテクチャ及び設計への取組に
関する追加情報を提供する。
  次の側面は,すべて保守性に影響するものであるが,プログラム言語を選ぶときに考慮することが望ま
しい。
− 言語の移植性
− 言語の読みやすさ
− 言語の安定性
− 自己記述性
− プログラムの分かりやすさを損なうプログラミングの技巧の許容範囲
− プログラム構造化の可能性
− 新規リリース作成の容易さ
− データ構造化の可能性
− コンパイラなどのツールの入手可能性
− コンパイラなどのツールの安定性
− コンパイル及び実行中のテスト可能性
− 作成,デバッグ,構成管理,及び信頼性要求事項・品質要求事項の充足を支援するソフトウェアエン
    ジニアリング環境及びソフトウェアテスト環境の利用可能性
− 様々な開発ツールの使用可能期間
6.8.2  保守性及び開発プロセスでの特定のアクティビティ群
6.8.2.1  ソフトウェア要求分析
  ソフトウェア仕様書は,ソフトウェアの保守性の要求事項を漏れなくあいまい(曖昧)でなく記述して
いることが望ましい。これらのものは,JIS X 0160が要求する品質特性仕様書に含まれていることが望ま
しい。次の側面は,保守性に影響を与えるものであり,考慮することが望ましい。
− 機能の識別及び定義,特に付加機能の特定及び定義
− データの正確性及び論理的構成
− インタフェース(機械及び利用者),特に将来変更が起こり得るインタフェースの要求
− 訂正及び追加の影響を考慮した性能要求事項
− 規模性の要求事項及び予測されるシステム成長を考慮して,計画された環境によって課せられる要求
    事項
− 追跡の容易さ又は困難さに影響するような要求事項の粒度
− 文書化及び文書適合性に重点を置いたソフトウェア品質保証計画
6.8.2.2 ソフトウェア方式設計
  このアクティビティは,ソフトウェア品目に対する要求事項を,ソフトウェアの最上位水準の構造及び
ソフトウェアコンポーネントを明らかにするソフトウェア方式に変換する(JIS X 0160を参照)。ユーザア
プリケーション層及び基盤システム運用層がインターネットシステムに対して適切に独立しているような
方式例では,基盤ソフトウェアからアプリケーションを分離して保守する大きな助けとなる。保守性に影
響を及ぼすJIS X 0160の開発プロセスのアクティビティの主な特徴は,プログラム構造を選択し,それを
構成要素に分解し,そこでのデータの流れを定めることである。他のアクティビティのように,プログラ
ミングチームのデータ処理の知識を利用することが重要であり,特にこれによって,ディペンダビリティ

――――― [JIS X 0161 pdf 29] ―――――

26
X 0161 : 2008 (ISO/IEC 14764 : 2006)
が既に確認済みの,既存のプログラム又はライブラリ部品の利用可能性を明らかにできるからである。
    注記 ディペンダビリティ(dependability) アベイラビリティ及びその影響要因,すなわち,信頼性,
          保守性及び保全支援の能力を記述するために用いる用語の総称(JIS Q 9000:2000を参照)。
6.8.2.3  ソフトウェア詳細設計
  JIS X 0160の開発プロセスのこのアクティビティは,それぞれのソフトウェアコンポーネント,インタ
フェース及びデータベースの詳細な設計を提供する。このアクティビティは,提示されたプログラミング
の解決策を仕上げるために,機能を正確に詳細化した記述を作り出す。
6.8.2.4  ソフトウェアコード作成及びテスト
  JIS X 0160の開発プロセスのこのアクティビティは,ソフトウェアユニット及びデータベースを開発し,
文書化し,テストする。ソフトウェアの保守性は,文書の品質を向上することによって改善される。質の
高い文書は,保守プロセスの実行を助ける情報を提供することが望ましい。保守性を改善させるための提
言としては,次がある。
− 確実に読みやすくする。
− 構造化コーディングをやり通す。
− コーディングの複雑度を低減する。
− コードに正確なコメントをつける。
− 字下げ及び空白を利用する。
− 言語の弱点を考慮することによって,古典的なわな(罠)をさける。
− 誤りの追跡を容易にするような技術を使用する。
− ソースコードから設計への追跡性を確実にする。
− コーディング標準を使用する。
− 制御フロー及び判定の複雑度を低減する。
− コード及びテストケースの検査を指揮する。
− 開発サイクル期間中の文書を維持する。
6.8.2.5  ソフトウェア適格性確認テスト
  このアクティビティは,それぞれ実装されたソフトウェア品目がその適格性確認要求に適合しているか
をテストするのを確実にする。ソフトウェア開発中に使用されたテストケースは,修正後の回帰
(regression)テストのために保管しておくことが望ましい。さらに,開発期間中のソフトウェアの進化をよ
りよく理解するために,プログラムの開発履歴が保守で利用できることが望ましい。

6.9 ソフトウェアの引継ぎ

  ソフトウェアの引継ぎは,ソフトウェア開発を,最初のソフトウェア開発実施組織から,ソフトウェア
保守を実施する組織に受け渡すための,制御され,調整された一連の行為である。もし,保守の責務があ
る組織から他の組識へ移るならば,引継ぎ計画を策定することが望ましい。この計画では,次のことを考
慮することが望ましい。
− 開発者から保守者への,ハードウェア,ソフトウェア,データ,支援サービス及び経験の引継ぎ
− ソフトウェア保守戦略を実現する上で,保守者に必要なタスク(例えば,要員配置,教育訓練,導入
    及び保守中の問題の再現)
− 知識引継ぎ及び文書化の評価
− 突出した問題及び新規要求事項の優先順位
− テスト環境の準備状況の評価

――――― [JIS X 0161 pdf 30] ―――――

次のページ PDF 31