非機能要求グレード

[A.2.3]可用性＞耐障害性＞ネットワーク機器 ①冗長化（機器） ②冗長化（コンポーネント） 耐障害性(ネットワーク機器)に関するまとめ 結論：非機能要件として、ネットワーク機器の冗長性について合意しよう [A.2.3]可用性＞耐障害性＞ネットワーク機器 今回は、耐障害性(ネットワーク機器)について紹介する。耐障害性(ネットワーク機器)とは、サーバーにおける耐障害性と同様、ネットワークがどのくらい障害に耐えられるのかを示す度合いのことを指す。サーバーにおける耐障害性については、下記参照。 req-definer.com ただし、サーバーのそれと異なる点として、サーバーはネットワーク上の端っこ…

[A.2.1]可用性＞耐障害性＞端末 ①冗長化（機器） ②冗長化（コンポーネント） 耐障害性(端末)に関するまとめ 結論：非機能要件として、端末の冗長性について合意しよう [A.2.1]可用性＞耐障害性＞端末 今回は、耐障害性(端末)について紹介する。耐障害性とは、サーバーにおける耐障害性と同様、どのくらい障害に耐えられるのかを示す度合いのことを指す。サーバーにおける耐障害性については、下記参照。 req-definer.com ただし、サーバーのそれと異なる点として、サーバーの場合は、端末から接続されているので壊れたら別系統へ速やかに切り替えなければならないが、端末の場合は、文字通り端っこの…

[No1][A.2.1]可用性＞耐障害性＞サーバ ①冗長化（機器） ②冗長化（コンポーネント） 耐障害性(サーバ)に関するまとめ 結論：非機能要件として、サーバーの冗長性について合意しよう [No1][A.2.1]可用性＞耐障害性＞サーバ 今回は、耐障害性(サーバ)について紹介する。耐障害性とは、サーバやコンポーネント（部品）が故障しても、予備の系統に切り替えるなどして稼働を継続し、どのくらい障害に耐えられるのかを示す度合いのことを指す。 耐障害性(サーバ)に関して決めるべき項目は2点存在する。 冗長化（機器） 冗長化（コンポーネント） 以下、順に説明する。 ①冗長化（機器） 機器の冗長化とは…

A.1 可用性＞継続性 継続性に関するまとめ 継続性に関する記事一覧 A.1 可用性＞継続性 req-definer.com 上記の記事で紹介したIPAの非機能要求グレードに関して、小項目をちょっとずつまとめてきた。今回まとめた項目は、中項目としての継続性に分類されるものとなる。ようやく11項目/283項目完了した。先は長いがちょっとずつまとめていきたい。 継続性に関するまとめ 下記に、「継続性」の11項目に関して簡単にまとめたものを表形式で記す。業務継続性として、何を決めなければならないのか？と思ったときは、参照されたい。 項番 小項目 メトリクス（指標） 決めることの具体例 A.1.1.1…

[No1][A.1.4]可用性＞継続性＞目標復旧水準（大規模災害時） 目標復旧水準（大規模災害時）についてのまとめ 結論：大規模災害が起こった時のことについて話し合っておこう [No1][A.1.4]可用性＞継続性＞目標復旧水準（大規模災害時） 今回は、目標復旧水準（大規模災害時）だ。 想定したくはないものだが、想定しておかなければならない。大規模災害というのは必ず発生する。大雨洪水で電力の供給や通信線が遮断され、システムが稼働できなくなる場合もある。地震や火災でデータセンターが破壊されてしまう場合もある。それでもいつかはビジネスを再開せねばならず、再開までの目標を決めておかねばならない。 r…

[No1][A.1.3]可用性＞継続性＞目標復旧水準（業務停止時） ①RPO(Recovery Point Objective)：目標復旧地点 ②RTO(Recovery Time Objective)：目標復旧時間 ③RLO(Recovery Level Objective)：目標復旧レベル 目標復旧水準（業務停止時）に関するまとめ 結論：非機能要件として、目標復旧水準（業務停止時）について合意しよう [No1][A.1.3]可用性＞継続性＞目標復旧水準（業務停止時） 今回は目標復旧水準（業務停止時）だ。簡単に言うと、システムが故障した後に、いつまでに、どのくらいのレベルで、システムを復旧さ…

[No1][A.1.2]可用性＞継続性＞業務継続性 ①対象業務範囲 ②サービス切替時間 ③業務継続の要求度 業務継続性に関するまとめ 結論：非機能要件として、業務継続性について合意しよう [No1][A.1.2]可用性＞継続性＞業務継続性 今回は、業務継続性について紹介する。業務継続性は、システムに障害が発生しても、どのくらい業務を継続できるようにするのか、の程度を表している。 業務継続性に関して決めるべき項目は3点存在する。 対象業務範囲 サービス切替時間 業務継続の要求度 以下、順に説明する。 ①対象業務範囲 対象業務範囲というのは、対象業務の種別のことを表している。対象業務範囲として、下…

損害保険システムの要件定義に関わることになった。 損害保険システムはよさげな情報が見つからない。 業界の再編に伴って，ただでさえ複雑な商品構成がさらに混然一体となっているようだ。 他システムとの接続も，金融システム特有の複雑さ。 Web上のバラバラな情報では一貫した理解は望めないので，基本の書籍調査を行う。 知りたいこと 一般的な業務機能 業務機能ごとの業務フロー 会社間の関係，行政，海外組織との関係(システム，業務連携の観点から) よくあるUser Interface，帳票 基幹システム構成 業界一般 できるだけ，「損害保険システム」が出ており，かつ業務の話も扱っているものが望ましい。 [1…

はじめに 受託開発（クライアントがオーナーになるシステムの構築依頼を受ける場合）のプロセスの内、アプリケーション基盤領域のITアーキテクト（APアーキテクト）の仕事内容をまとめたもので、所謂SIerの仕事の一断面です。以降、ITアーキテクト（AP）と記載します。 SIer各社における標準的な開発プロセスや役割分担、クライアント意向など様々な要素の影響を受けるため、SIerにおける標準的な仕事内容を示すものではありません。 プロセス概要 受託開発のプロセスの内、ITアーキテクト（AP）のタスクの概要を示します。ここでは受託開発前の案件化のプロセスも含んでいます。 自社の受託開発においてアジャイル…

技術書 人月の神話 ブルックスの法則など今でも通用する話が多く登場。妊婦さんの例も分かりやすかった もう一度読み直したい。古いコンピューターの話が登場しついていけないがそれは耐えるしかない レガシーコードからの脱却 小さい方が良い。見積もりの単位に時間を使わない。人生で好きなことをやっているなら、人生で働いてた日は1日もない。などハッとさせられる名言が多い。 ただ、なんとなく読むのがつらかった。 UMLモデリングのエッセンス 全部読んではいない。必要なときに参考にしている 図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書 表紙で心配になったが内容はちゃんとしていた IP…

これは フェンリル デザインとテクノロジー Advent Calendar 2022 23日目の記事です。 インフラ担当の柴田です。今回はプライベートで関心を寄せていることということで、負荷テストについて書きますが、特にオチ（結論）はありません。 負荷テストとは？ 負荷テストは、非機能テストの一部で、システムの品質特性を評価します。ただ、一言で負荷テストと呼んでいても、実際のテストではさまざまな目的をもって実行されています。 私がなぜ負荷テストに関心を寄せているかというと、いざ自分が負荷テストをしようとすると、なかなかに難しく「こんな難しいのを他の人は本当に適切に実施できているのか？」と考えた…

みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので…