設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
徳島県、決裁済み書類を書き換え 消しゴムで金額を修正：朝日新聞デジタル
２０１６年参院選で、徳島県選挙管理委員会事務局を務める県市町村課が、確認ミスで約３２０万円の損害を出していたことが、県の包括外部監査（監査人・野々木靖人弁護士）の報告書でわかった。決裁済みの書類の金額を砂消しゴムで消して書き換えたことも判明したという。 同課は高知との合区となった１６年参院選で、選挙公報や投票用紙などの印刷について、同年５月に徳島市内の印刷会社と８９８万円で随意契約を結んだ。 徳島・高知選挙区には３陣営が立候補。陣営が提出した選挙公報の原稿のうち、１陣営の原稿が規定の枠からはみ出ており、印刷会社は３陣営分を同じ比率で縮小して印刷した。同課は県内分約３５万８千部が刷り上がった時点で、他の陣営分も縮小したミスに気付き、印刷会社に刷り直しを依頼。契約額は１２１９万円に増えた。 契約額の増加を受け、同課は決裁済みの書類の支出予定額を、砂消しゴムで消し、「９５０万円」から「１２５０万
システムに不可欠なセキュリティ対策、漏れを食い止める設計書3点セット
「セキュリティ対策はシステム開発で不可欠だが、設計書でうまく表現できている開発現場はまだ少ない」――。 ラックの永井英徳氏（エンタープライズ・セキュリティサービス事業部セキュリティディレクションサービス部長 兼 第一グループ部長）はこう指摘する。よく見られるのが、「クロスサイトスクリプティングの脅威には、Aフレームワークを利用することで対処する」などと、個別の脅威ごとに対策を記述するケースという。しかしこれでは、「システム全体として必要なセキュリティ対策を網羅できているのか判断しにくい」（永井氏）。 とはいえ、機能に関する設計書に、想定しうるあらゆる脅威の内容と対策を書き込むのも問題だ。記述が膨大になり、読みにくい設計書になってしまう。後工程の開発メンバーの作業ミスを招く恐れがある。セキュリティ要件が変わったときの修正作業の負荷も大きい。 このような問題意識のもと、ラックの永井氏は、セキュ
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ | Microsoft Docs
拝啓『変わらない開発現場』を嘆く皆様へ ～変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み～ 05/25/2017 3 minutes to read 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。 こうした背景があり
システムやアプリケーションの要件定義、設計から実装、完成まで - 偏った言語信者の垂れ流し
はじめに 普段システムやアプリケーションを作るのに、どういう手順でやるっけかなーというのを書き出してみた、というものです。 必ずしもこの通りにすればうまくいく、というものではなく、一例だと考えてください。 流れ 大雑把に次のような流れになります。 何をしたいのか、まとめる(企画、要件定義) 要件を満たすシステムの入力や出力の詳細、データの流れやシステムの処理をまとめる(仕様策定) 要件、仕様をどうやって実現するのか考えてまとめる(設計) 設計に対応する実装をする、システムを構築する(実装) 実装、構築して出来上がったものが、要件や仕様を満たしているか確認する(試験) 完成 各工程で、アウトプットしたものを後工程で使ったりします。 1. 何をしたいのか、まとめる(企画、要件定義) システムやアプリケーションに限らないですが、そもそも何をするのか決めていないと、始まらないので、やりたいことをま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
