en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
en : Stakeholder Needs and Requirements Definition process
JIS X 0160 での訳 : 利害関係者ニーズ及び利害関係者要件 (要求事項) 定義プロセス
JIS X 0160 で定義されているソフトウェアライフサイクルプロセスのひとつ
取得者の業務要件と、取得者がシステムに求める要件 (機能要件、非機能要件) を明確にすることを求めている
ITIL 4 では、サービスの利害関係者の代表例として以下を挙げている
サービス消費者 (ユーザー、顧客、スポンサー)
サービス・プロバイダ
パートナー、サプライヤ
株主、従業員、コミュニティ等
en : system
JIS X 0160:2021 での定義 : 一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ
一般システム理論におけるシステム
内部の要素が相互に関連する、1 つのまとまりのこと
複数の要素が情報やモノ、エネルギーなどの流れでつながり、相互に作用しあい、全体として目的や機能を有する集合体
共通フレーム 2013 においては、JIS X 0160:2021 の利害関係者ニーズ及び利害関係者要件定義プロセスを単に要件定義プロセスとしている
いわゆる業務要件定義を行うプロセス
関連
利害関係者要件
『SEC BOOKS 共通フレーム 2013』 より
en : System/Software Requirements Definition process
同義 : システム及び/又はソフトウェア要件 (要求事項) 定義プロセス (JIS X 0160 での訳)
共通フレーム 2013 においては、システム要件定義プロセスやソフトウェア要件定義プロセスがこのプロセスに該当するぽい
JIS X 0160:2021 より
JIS X 25030:2021 より
JIS X 0170:2020に定義されている要求事項関連プロセス (利害関係者ニーズ及び利害関係者要件定義プロセスやシステム要件定義プロセス) を用いて、品質要件を引き出し、定義し、分析し、維持する
ソフトウェアシステムだとシステム/ソフトウェア要件定義プロセスだな
利害関係者ニーズ及び利害関係者要件定義プロセス (要件定義プロセス) によって利害関係者要件を定義する際に、その中で利用時品質要件も定義
→ /yunoha-pub/JIS X 0166:2021
規格名称 : システム及びソフトウェア技術-ライフサイクルプロセス-要求エンジニアリング
対応国際規格 : ISO/IEC/IEEE 29148:2018 (IDT)
関連
JIS X 0166
テストについて
ソフトウェアテストは、開発と保守を通して、様々なレベル (テストレベル) で実行される
テストレベルは、テストの目標物 (テスト対象) とテストレベルの目的または目標によって識別される
テスト対象による分類 (『SWEBOK V4 Beta』 参照)
単体テスト (unit testing)
共通フレーム 2013 で定義されているプロセス
ISO/IEC 15288 の要求事項分析プロセスを特化したもの
JIS X 0160:2021 におけるシステム/ソフトウェア要件定義プロセスに該当するはず
定義された利害関係者要件を、システムの設計を導く、システムの技術的要件の集合に変換する
成果物として、システム要件を明記する
en : software system
JIS X 0160:2021 の定義 : 利害関係者にとって、ソフトウェアが最も重要であるシステム
一般的に、ソフトウェアシステムは、ハードウェア、ソフトウェア、人員及び手作業で構成される
ソフトウェア開発の成果物
3 つの重要な特性 (1)
アジャイル手法とソフトウェアライフサイクル
JIS X 0160:2021 より
アジャイルプロジェクトでは、概念の探索、開発、構築、テスト、移行、及び以前のソフトウェアの廃棄を連続的な反復で同時並行して行うことができる
こういったプロジェクトでは、これらの活動と同時並行して再計画を行う
この取組方法では、ライフサイクル段階の終了時点を管理チェックポイントとして、あるいは制御のために使用することは有用ではない
en : systems engineering
JIS X 0160:2021 での定義 : 利害関係者のニーズ、期待及び制約の集合を、解決するソリューションへ変換するため、及びソリューションが用いられる全期間を通じて、それを支援するために要求される、技術上及び管理上の作業の全体を統括するような、複数の専門分野を横断した取組方法
DSV は Drive Stakeholder Value のこと
サービスに関わる利害関係者の誰もが、サービスを通して価値を得られるように牽引すること
顧客だけではなく、サービス・プロバイダやサプライヤにとっても価値があるように
互いに win-win な関係 → 持続可能なサービス
カスタマージャーニー
ITIL の継続的改善のモデル。 ITIL SVS の構成要素のひとつになっている。
ビジョンを定義し、現状分析から改善を積み上げて推進力を維持しながらビジョンを達成するためのアプローチ
ビジョニングの分野から生まれた
ITIL 4 DPI に合致するモデル
次の 2 つが参考になる
ビジネスコンセプト : 構想立案時やシステム化企画時に検討され、要件定義開始時に提示されていることが多い
ビジネスコンセプト確認ドキュメント
ステークホルダー (利害関係者)
ステークホルダー関連図
ステークホルダー一覧
最初にやること
立ち上げ : 確認・準備
企画・構想を確認する
企画の目的の整理
ステークホルダー (利害関係者) の特定
ソフトウェアエンジニアが、適切な利害関係者に対してソフトウェアの側面を理解させたり、工業製品化したり、伝達する際に使える身近な手法
汎用原則
本質をモデル化せよ
大局観を提供せよ
効果的な伝達を図れ
IT システムを作らせる側が、システムに求めること (= 要求) を明確にする作業
ケンブリッジ・テクノロジー・パートナーズの定義としては、「利害関係者の意見をまとめ、実現することとしないことを揺るぎなく定めること」 としている
「要求定義」 と 「要件定義」 を同じものとする派閥もあれば、異なるものとする派閥もある
主要な成果物
ファンクショナリティ・マトリクス (FM)
en : Use Case
1987 年に Ivar Jacobson が提唱して依頼、広く使われてきた要求分析技法
UML では、ユーザー (アクター) とユースケースの関係がユースケースモデルとして表される
ユースケースの分割 : ユースケーススライス
『ソフトウェア要求 第 3 版』 より
一般的マネジメントプラクティス (ITIL 4) のひとつ
戦略および戦術レベルで、組織と利害関係者のつながりを確立し、深める
関係の識別、分析、モニタリング、継続的改善等
参考文献
ITIL® ファンデーション ITIL 4 エディション
目的 : 組織で、変更が円滑かつ成功裏に実施されることと、変更における人に関わる側面を管理して、持続的なメリットの実現を確実にする
組織変更の管理のポイント
切迫感の創出 (危機意識を生み出す)
変革の 8 段階のプロセスの 1 番目のステップと同等
人は変化を嫌うものなので、今のままではいけない、という意識を持ってもらう
環境的、社会的、経済的発展に関連するリスクと機会に取り組むことで、社会やその他の利害関係者に長期的な価値を生み出すことに焦点をあてたビジネスアプローチ
参考文献
ITIL 4 の教本
from PMBOK はじめの一歩 ― スッキリわかるプロジェクトマネジメントの基本
プロジェクトを実行、監視・制御、および終結する方法を記述した文書
計画書の要素
プロジェクトの目的、目標
スコープ
JIS X 25030:2021 で説明される、品質要件の一種
この JIS では 「利用時品質要求事項」 という言葉が使われているが、requirement の訳として 「要件」 を使うことが多いので、要件としている
利害関係者の視点から品質の要求レベルを明記したもの
様々な利害関係者のニーズから導出される
製品の妥当性確認のための対象として使用可能
en : stakeholder requirements specification
略 : StRS
JIS X 0166:2021 の定義 : 利害関係者、及び利害関係者と外部環境との関係についての要件を構造化した集合
規格名称 : ソフトウェアライフサイクルプロセス
対応国際規格 : ISO/IEC/IEEE 12207:2017 (IDT)
JIS X 0160 の 2021 年に発行された版
内容メモ
ISO/IEC/IEEE 12207:2017 を基に、技術的内容および構成を変更することなく作成された日本産業規格
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
システム化構想を実現するために、運用や効果等の実現性を考慮したシステム化計画とプロジェクト計画を具体化し、利害関係者の合意を得ることが目的
アクティビティとしては、準備、立案、承認、がある
en : invention design
ソフトウェア要求プロセスの中で、発見されたニーズと要求を満たすために、システムの概念化および仕様化を目的に行う
システム開発における要求と要件の違いについて、標準的な定義は無い模様
英語の requirement の訳として、要求も要件も使われるっぽい
『ユーザのための要件定義ガイド 第 2 版』 では、「要求を文書化、仕様化し、ステークホルダーと合意したもの」 を要件としている
『経営者が参画する要求品質の確保 ~超上流から攻める IT 化の勘どころ~ 第 2 版』 における使い分け
以下のような使い分けを考えている様子
プロジェクト (1 つまたは複数) にソリューションを作成させるもとになるニーズと、最終的に望むビジネス成果を記述した一連の情報
ビジネス機会、ビジネス目標、成功判定メトリクス、ビジョン記述からなる
核となる 2 要素
プロダクトビジョン : ビジネス要求を満たす最終的なプロダクト
プロジェクトスコープ : 現在のプロジェクトまたは開発イテレーションが、プロダクトビジョンのどの部分に対応するか
イノベーションを生むための理論
『ジョブ理論 ― イノベーションを予測可能にする消費のメカニズム』 にて説明される
ジョブとは、ニーズをさらに深めたものに近い
特定の状況におかれた人が持っている、解決したい課題とか用事
ミルクシェイクの例
Essence カーネルで定義されている
コンピテンシーにはレベルがある
全てのコンピテンシーで統一されている
カーネルコンピテンシー
顧客
同義 : ビジネスアナリシス
ビジネスアナリシスとは、組織をとりまく状況 (Context) において、ニーズ (Needs) を定義し、すべてのステークホルダー (Stakeholders) に価値 (Value) を提供するソリューション (Solutions) を推奨することによって、変革 (Changes) を可能にするためのプラクティス
▲ 『ソフトウェア要求 第 3 版』 で紹介されている BABOK バージョン 3 のドラフトより
略 : DX
2004 年、スウェーデンのウメオ大学のエリック・ストルターマン教授が 「Information Technology and the Good Life」 という論文の中で提唱した概念
「ICT の浸透が、人々の生活をあらゆる面でより良い方向に変化させる」 という仮説として提示されていた
世の中での定義は一致しておらず、使い方も人や場面によって様々
デジタル以外の手段では実現できない可能性がある組織の目標を実現するうえで、大きな改善を可能にするデジタル技術を利用すること
立石一真 (オムロン創業者) らが 1970 年の国際未来学会で発表した理論
社会のニーズを先取りした経営をするために、未来の社会を予測する必要があるとの考え
SINIC は “Seed-Innovation to Need-Impetus Cyclic Evolution” の頭文字
2 つ方向の相関関係により、お互いが影響しあって社会が発展する
新しい科学が新しい技術を生み、それが社会へのインパクトとなって社会の変貌を促す
from: ファンダメンタルズ × テクニカル マーケティング ― Web マーケティングの成果を最大化する 83 の方法
クリエイティブは 3 つの要素で構成される
誰に : ターゲットユーザー
ターゲット設定の方法の一つは、ニーズの強さを分類
「対策の必要性に気づいていない」 「対策の必要性は気づいているが一時的だと思っている」 など
from: ワイズカンパニー 知識創造から知識実践への新しいモデル
「A と B の両方を同時に成し遂げるにはどうすればよいか」 と問われる
ゴア社の例
常に向き合っている 3 つの矛盾
短期目標の達成と長期目標の達成
TOPPOINT 2022 年 6 月号 より
支配者が支配されるルールは、「政治的に生き残る」 ということ
リーダーは独りで国家や組織を率いることができるわけでもない
政治の世界の 3 種類の人々
名目的な有権者集団 : リーダーを選ぶ法的な立場を持つもの (例えば投票権のある全てのひと)
パフォーマンスを向上させるための、コーチングの会話
1 on 1 の内容としても参考になりそう
from: ザ・マネジャー 人の力を最大化する組織をつくる
1. 職務の明確化と人間関係の構築
個人の強みと組織全体の目標に合致した期待値を設定する
同義 : 利用時の品質
利用者のニーズをどれだけ満たせるか
関連
利用時品質要件
利用時品質モデル
アイデアとして使えそうなものをたくさん生み出すこと
IDEO 社 CEO ティム・ブラウンの 『Design Thinking』 からの引用
アイディエーションの取り組みの例 (IDEO 社)
1. 市場、クライアント、技術、問題への制約をとらえる
2. 現実における生身の人間を観察 → ニーズを探る
『SEC BOOKS 共通フレーム 2013』 より
システム、ソフトウェア製品、又はサービスの開発を目的とする
要件を、顧客のニーズにあったシステムへと変換する
システムの新規開発や保守に伴う開発、旧システムからの移行に伴う開発で用いられる
以下のプロセスがある
『SEC BOOKS 共通フレーム 2013』 より
要求と要件は、いずれも requirement の訳語
国際規格での定義の例 : 製品またはプロセスの運用/機能/設計上の特性を識別する文で、曖昧性がなく、テスト可能で、測定可能で、(顧客または内部の品質保証ガイドラインに) 受け入れられるために必要であるもの
事業目的や業務目的に照らして 「本当に必要か」 が十分検討され、要求が満たされたことの基準や手段がはっきりしており、明文化されているもの
en : Verificastion process
検証に関するプロセス
関連
検証と妥当性確認
『SEC BOOKS 共通フレーム 2013』 より
関連 : 性交
人間の最も強い欲求である 「孤立を克服する」 ための、ある程度自然で正常な方法
妊娠を目的にする場合
何より回数を増やすこと
精子は古くなると精嚢の中で老化する → 定期的に射精して新鮮な精子が常にある状態をつくるべき
孤立の克服
人間の最も強い欲求
合一を達成するための方法
合一 (孤立の克服) のために使われてきた完全ではない 3 つの方法
興奮 (祝祭的興奮) → 合一 (孤立の克服) のための祝祭的興奮
ホメオスタシス = 恒常性維持
自分らしい自分でいたいという欲求や実践
合一 (孤立の克服) のための集団への同調
過去に最も頻繁に選ばれてきたのは、興奮を用いた合一ではなく、集団、慣習、慣例、信仰への同調にもとづいた合一
現代の西洋社会でも、孤立感を克服する一般的な方法は集団への同調
独裁体制であれば威嚇と脅迫
民主的な国家では暗示と宣伝
自分が創造者だと思いたい、という欲求
人間のもっとも基本的な欲求のひとつ
根底に、人間が自己を認識しているという事実がある
自分が被造物で、壺から振り出されたさいころのようなものだと認めたくない、ということ
母親は子どもをもつことによって自分自身を超越し、幼児への愛は母親の人生に意味と目的を与える
自律性には自由な意志 (自由意志) と自己選択の感覚を持って自由に行動することが大事っぽい。
他者の自律性を支援する方法。
選択を与える。
必要に応じて制限を加える場合 :
制限自体を本人や組織が決めると良い
人生に意味はあるのか――この問いは哲学の内外で提起されうる。 この問いは複数の解釈をもつ (私の人生について語っているのか、人間一般の生について語っているのか、など)。 また、ここでの 「意味」 の意味も問題になる。 とはいえ本稿ではこうした解釈問題を避け、必要な点を約定するにとどめる。 本稿は 「創造性 (creativity)」 としての人生の意味へ焦点を絞る。
私たちは決められたレールにのる人生をしばしば無意味と見なす。 あるいは、ルーティン化された作業だけを繰り返す生活を無意味と感じるときがある。 なぜか。 その理由は重要な意味の新しさがこうした生に欠けていることである。 少なからぬひとは、それまでになかった何かを新たに生み出した人生こそを、有意味な生と考える (とりわけ学者や芸術家にこのタイプのひとがいる)。
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
人の期待をマネージしながら不確実性に適応する術
3 つの術
余白の戦略
スプリント強度を高める戦術 (やり抜く力)
from 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
期待の優先度をつけるもの
QCDS とプロジェクト特有の観点について、優先順位をつける
プロジェクトの全体像をとらえ、期待をマネジメントするツール
ThoughtWorks のロビン・ギブソンによって創作された
日本では、『アジャイルサムライ-達人開発者への道』 で紹介されて有名になった
10 個の質問からなる
1. 我々はなぜここにいるのか
著 : 岩出雅之
from: TOPPOINT 2022 年 8 月号
逆境でも組織が実力を発揮して成果を上げるには?
帝京大学ラグビー部で Z 世代と向き合って優勝に導いた元監督
2009 年度から 2017 年度まで、大学選手権で 9 連覇
from: 逆境を楽しむ力
「結果に結びつく行動を実際にとる自信があるかどうか」 の期待
from: 逆境を楽しむ力
「A をすれば B という結果を得られるだろう」 という期待のこと
『アジャイルな見積りと計画づくり 〜価値あるソフトウェアを育てる概念と技法〜』 より
計画とは期待と可能性を伝達するもの
計画は重要
計画は投資判断の根拠になる
どういう人材が必要なのかや、ユーザーが求めるフィーチャを提供できるのかの確認もできる
動機づけを期待と価値から説明する理論
動機づけを規定する要因を 3 つに絞って説明
期待 (Expectancy) : ある行動がある成果をもたらすであろうという本人の予測 (主観的)
誘意性 (Valence) : 成果自体の魅力と、成果を上げることで得られると思われる報酬の魅力
道具性 (Instrumentality) : 成果を上げることが報酬を得るための手段 (道具) としてどの程度役に立つのか
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
顧客にすばやく価値を届けるために、開発から運用への作業の流れを早くスムースにする
作業を可視化し、バッチサイズを縮小し、作業のインターバルを短縮し、品質を組み込んで下流に不良品が流れないようにする
やるべきこと
作業の可視化
en : Theory of Constraints / 略 : ToC / 同義 : 制約条件の理論
TOC (Theory Of Constraints : 「制約理論」 または 「制約条件の理論」) は、「どんなシステムであれ、常に、ごく少数 (たぶん唯一) の要素または因子によって、そのパフォーマンスが制限されている」 という仮定から出発した包括的な経営改善の哲学であり手法です。
ホケットによるもの
今井・秋田版
言語の本質的特徴
1. 意味を伝える
2. 変化する
複数のコンポーネントやサブシステムからなるプロダクトの要求を表す (ISO/IEC/IEEE 29148:2011 (E))
システムというのはソフトウェア以外のハードウェアなども含んでおり、人やプロセスもシステムの一部
ユーザーインターフェイスの分析と設計の中の作業のひとつ
システムのエンドユーザーのプロファイルに焦点を当てる
スキルレベルや業務の理解、新しいシステムに対する受容力などを記録
ユーザーのカテゴリごとに要求が導かれる
本質的には、ユーザーの種類ごとのシステム知覚を理解する取り組み
組織が学習できない 7 つの要因
1. 私の仕事は○○だから : 事業全体のことを考えられない
2. 悪いのはあちら : 他責にする
3. 先制攻撃の幻想 : 難しい問題に直面したときに積極的に敵に攻撃する (が、実際には敵はおらず、問題を引き起こしているのは自分自身を含めたシステム)
4. 出来事への執着 : 売上や予算削減、競合他社の新製品などの短期的な出来事を重視し、その背後の長期的なパターンを無視する
相手への気づかいに基づく感情の状態だと考えられやすい
思いやりは、行動に作用するシステムに対する気づきの度合いに基づくものでもある
参考文献
学習する組織 ―― システム思考で未来を創造する
en : General systems theory
1940 年代の後半に作られた
第 1 期のシステム理論とされる
世界のほとんどの現象は、要素間の関係性の網としてみなせる、という考えに基づく
複数の学問分野を一つの共通言語で形式化することを最終ゴールとしているっぽい
en : System Thinking / Systems thinking
複雑なシステムの根底にある構造を見抜き、問題解決を単純化するという考え方
多様な分野にまたがる一連の一般原則
以下に端を発する独自のツールと手法でもある
サイバネティクスのフィードバック
社会をシステムの観点から読み解こうとする理論
制御の学をルーツに、20 世紀半ばから発展
統計熱力学を下敷きにしている
コミュニケーション一元論を用いて、コミュニケーション以外のものを要素としないシステムのダイナミズムを記述する
従来の上部構造と下部構造の二元論とは区別される
モダンからポストモダンへの変化
生活世界がシステムに置き換わるプロセスの当初は、システムを使うのは生活世界を生きる我々がより便利で豊かになるため、と自己理解できる
システムが一定程度広がり、生活世界が空洞化 → もはや我々がシステムを使っていると言えない
我々や生活世界というイメージも、システムの構築物だと理解するしかない
変化のまとめ
生活世界でまかなわれていた便益をシステムに置き換える合理化過程
途上が近代過渡期 (モダン)
完遂した段階が近代成熟期 (ポストモダン)
あえて生活世界を保全しているといえるようになるのが再帰的近代
選択対象としての生活世界なので、厳密にはシステムの中に含まれる
アメリカの国内外で疑惑と論争の種を撒き散らし続ける
それでもフィールグッド・ステイトを目指す以外に選択肢はない
民主制の危機を招来する
プラットフォームの保全に関わる危機
1. 国民の便益増大が国家の権益拡大になる
システムの全域化による生活世界の空洞化
ウェーバーは、生活世界がシステムに置き換えられる動きを近代化や形式合理化と呼ぶ
モダンからポストモダンへの変化という逆説
生活世界の空洞化が起こった経緯
生活世界の空洞化 = システムの全域化は、郊外化の動きと並行
ローマ帝国が 2000 年も続いた理由
優れたシステム
徹底した合理主義
多様性 (ダイバーシティ)
キリスト教が国教になるまで、異なる宗教や文化に寛容だった
生活世界を生きる我々が便宜のためにシステムを利用する、という自己理解が、汎システム化でできなくなる社会
生活世界も、そこで生きる我々もシステムの生成物に過ぎないものとして意識される
関連
ポストモダン
モダンからポストモダンへの変化
システムに対して、残余の領域
ここで言うシステムは、マックス・ウェーバーの言葉でいうと 「物事を計算可能にする手続きが一般化した領域」
例えば、役割とマニュアルが優位なコミュニケーション
役割をマニュアル通りに演じられれば誰でもいい
善意と内発性が優位なコミュニケーション領域
en : Conway's Law
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin Conway が 1968 年に 「How Do Committees Invent?」 という記事で発表した法則
関連 : IT システムにおける設計
from ソフトウェアエンジニアリング基礎知識体系-SWEBOK V3.0-
設計は、「アーキテクチャ、コンポーネント、インタフェース、さらにシステムまたはコンポーネントのもつほかの特性を定義するプロセス」 および 「そのプロセスの成果物」
System and Software Engineering Vocabulary より
ISO/IEC/IEEE 12207 (JIS X 0160) によると、ソフトウェア設計はソフトウェア要求分析とソフトウェア構築の間の 2 つのアクティビティで構成される
システムを実現するためにネットワークやハードウェアを設計すること
from はじめての設計をやり抜くための本 第 2 版
インフラ設計で重要な点は、セキュリティ、信頼性、効率 (性能、パフォーマンス)
from はじめての設計をやり抜くための本 第 2 版
システムの具体的な外部仕様を設計する作業
システムの入力と出力を明確にすること
アーキテクチャ設計を外部設計と並行して行うこともある
基本設計や機能設計、概要設計とも呼ばれる
from はじめての設計をやり抜くための本 第 2 版
外部仕様とは、システムがユーザーや外部システムに対して提供する機能やインターフェイスのこと
ソフトウェアライフサイクルプロセス
JIS X 0160:2021 に定義されているソフトウェアライフサイクルプロセス
合意プロセス
取得プロセス
供給プロセス
en : requirements engineering
同義 : 要求工学
JIS X 0166:2021 より
多分野の協働を必要とする工学で、取得者の領域と供給者の領域とを仲介し、対象とするシステム、ソフトウェア又はサービスが満たすようにする要件を確立し、保守するための工学
要求に関するプロセスとしては以下がある
en : Architecture Definition process
ソフトウェアライフサイクルプロセスにおけるテクニカルプロセスのひとつ
JIS X 0160:2021 より
システムアーキテクチャの候補およびその代替案を作成し、利害関係者の関心事を捉え、システム要件を満たす 1 つ以上の代替案を選定し、一貫した一連の複数のビューの中でアーキテクチャを表現することを目的とする
en : life cycle stage
システムライフサイクル段階と同義?
ISO/IEC/IEEE 24748-3:2020(E) より
ライフサイクルは複数の段階 (ライフサイクル段階) から構成される
段階は、相互依存したり重なったり (overlapping)、期間が異なったり、反復したり再帰的に適用される可能性がある
参考
SEC BOOKS 共通フレーム 2013
共通フレーム 2013 解説
https://www.ipa.go.jp/sec/publish/tn12-006.html#dl から体系をダウンロードできる
『SEC BOOKS 共通フレーム 2013』 より
略 : IPA SEC
独立行政法人情報処理推進機構 (IPA) 内に設置されていた組織
2013 年より IPA ソフトウェア高信頼化センター
2018 年には、他部署も含めた統合により IPA 社会基盤センターになったぽい?
『SEC BOOKS 共通フレーム 2013』 (2014 年発行の電子版) の奥付を見ると 「社会基盤センター」 が監修していることになっているから、2014 年には社会基盤センターがあった?
企画プロセスの中のプロセスのひとつ
『SEC BOOKS 共通フレーム 2013』 より
経営上のニーズの実現や課題解決のために、経営環境を踏まえて、新たな業務の全体像とそれぞ実現するためのシステム化構想及び推進体制を立案する
アクティビティとしては、準備、立案、承認、がある
ISO/IEC 29148 の A.2.5 「Concepts for the proposed system」 を参考にすると良い
『SEC BOOKS 共通フレーム 2013』 より
共通フレーム 2013 におけるテクニカルプロセスのひとつ
目標達成に係るシステムの要件の集合と、システム化の方針、システム実現のための実施計画を得ることが目的
要件定義プロセスや開発プロセスに先だって実施する想定
事業の見直しを伴わないシステムに関しては、本プロセスを省略しても良い
利用者用文書に従って、意図する環境でシステムを運用するタスク、およびそのタスクのみからなるアクティビティのこと
参考文献
SEC BOOKS 共通フレーム 2013
#nobuoka/購入した書籍
2022-12
天才読書
2022-11
コンテナ物語
ISO/IEC TR 15271 (ISO/IEC 12207 の手引き) に記載されている開発モデルのひとつ
顧客の要求から始まり、計画、モデリング、構築、デプロイと順に進んでいく
参考文献
SEC BOOKS 共通フレーム 2013
実践ソフトウェアエンジニアリング 第 9 版
nobuoka/読んだ本
12 月
ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ
みんなのコンピュータサイエンス
世界標準のデータ戦略完全ガイド データセンスを磨く事例から、データの種類と仕組み、戦略策定のステップまで
en : architecture
JIS X 0160:2021 の定義 : システムが存在する環境の中での、システムの基本的な概念又は性質であって、その構成要素、相互関係、並びに設計及び発展を導く原則として具体化されたもの
SLCP-JCF2013 の定義 : システムのある境界 (例えば、入出力系、プロセッサ、ネットワークなど) に対して、それらの外側から見た場合の概念的あるいは論理的な属性又は構造。 「方式」 と訳される場合が多い。 (from SEC BOOKS 共通フレーム 2013)
アーキテクチャのこと
『SEC BOOKS 共通フレーム 2013』 の用語集に、アーキテクチャについて 『「方式」 と訳される場合が多い』 と書かれている
『SEC BOOKS 共通フレーム 2013』 より
共通フレーム 2013 のサービスマネジメントプロセスは JIS Q 20000 を引用している
このプロセスは、JIS Q 20000 に準拠したサービスマネジメントシステムを構築している組織が、顧客に IT サービスを提供する運用において、活動と資源を指揮、管理することを目的とする
『SEC BOOKS 共通フレーム 2013』 より
次のことを文書化する
システム化目標、対象範囲
システムの機能及び能力、ライフサイクル
事業、組織、及び利用者の要件
『SEC BOOKS 共通フレーム 2013』 より
意図された環境で、システムおよびソフトウェア製品を運用し、顧客への支援を提供することが目的
成果としては以下
運用の戦略が定義されている
意図された環境下での正しい運用の条件が識別され、評価されている
『SEC BOOKS 共通フレーム 2013』 より
運用プロセスの中のアクティビティ
タスク
実施計画の作成 (運用プロセスのアクティビティ及びタスクを実施するための計画)
運用のための資産の引き継ぎ
『SEC BOOKS 共通フレーム 2013』 より
業務運用を定期的に評価するタスク、及びそのタスクのみからなるアクティビティのこと
評価項目の例
要件の実現度、特定の利用目的の実現度
システム運用移行、業務運用移行時の影響
『SEC BOOKS 共通フレーム 2013』 より
運用しているシステムを定期的に評価するタスク、及びそのタスクのみからなるアクティビティのこと
評価項目の例
要件の実現度、特定の利用目的の実現度
応答時間、処理時間、資源の利用状況
en : Quality Management process
JIS X 0160:2021 より
ソフトウェアライフサイクルプロセスのひとつ
目的 : 製品、サービス、品質管理プロセスの実施が組織とプロジェクトの品質目標に合致し、顧客満足を達成することを保証する
以下のアクティビティから成る
『SEC BOOKS 共通フレーム 2013』 より
組織に適切な人的資源を提供し、能力を維持向上するための作業を包括的に定めたもの
組織が必要とするスキルやキャリアを定義し、それを向上させるような教育訓練を組織的に、計画的に行う
『SEC BOOKS 共通フレーム 2013』 より
以下のような開発モデルがある
ISO/IEC TR 15271 (ISO/IEC 12207 の手引き) で取り決められたもの
ウォーターフォールモデル (Waterfall Model)
段階的モデル (Incremental Model)