要求分析と安全設計との関係（機能安全の致命的な欠陥）
日本の組込み系のソフトウェアエンジニアに担当製品に対するユーザー要求は何かを聞くとすぐさま答えられないことが多い。 顧客の要求に基づき日々ソフトウェアを開発しているIT系のソフトウェア技術者には驚きかもしれないが、事実そうなのだ。 なぜ、組込み系のソフトウェアエンジニアは自分の製品のユーザー要求を答えられないのか。それは、過去の製品のソフトウェアを追加、修正しながら新しい製品を作っているから、大元のユーザー要求を把握していなくとも、製品開発が出来てしまうからだ。 継承するソフトウェアの中に基本機能、基本性能がすでに入っているから、付加機能を付け足すぶんには元の要求を知らなくても作業はできるのだ。 さながら、老舗旅館の旧館、新館、別館、アネックスといったようなもので、結果、継ぎ足しで成り立っている迷路のような構造になることもしばしばだ。 継ぎ足し、修正ばかりやっているソフト技術者はユーザー要
ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2
SESSAMEで6月7日に開催するソフトウェア安全分析・設計セミナの資料を作っているところだ。 4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。（定員は30名なので参加を検討されている方は早めに申し込んで欲しい） 東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。 セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。 なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。（自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい） この記事では、『ソフトウェア安全分析
[SECメルマガ]2015.6.30_第108号：IPA 独立行政法人 情報処理推進機構
SECウェブサイトに利用登録され、メール配信サービスをお申し込みいただいた方へ お送りしております。※配信解除の方法については、文末をご覧ください ┏ SECメルマガ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ ☆ 第108号 2015.6.30 ☆ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ 「ETWest2015」の出展と「SEC特別セミナー」の開催が、無事に終了しました。会場 へお越しいただいた方に、改めて御礼申し上げます。また、ご参加されていない方 にも、SEC journalやメルマガなどで、内容をご紹介していきます。ご期待ください。 ―――――――――――――――――――――――――――――――――――――― INDEX 【1】コラム 【2】トピックス 【3】セミナー開催のお知らせ 【4】直近のソフトウェア高信頼化関連
やさしい機能仕様 パート4: ヒント - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/15 さて、私たちはなぜ仕様書が必要なのか、仕様書の中身は何か、そして誰がそれを書くべきかについて話してきた。このシリーズの最後のパートでは、良い仕様書を書くためのアドバイスをお話ししよう。 仕様書を実際に書いているチームから聞く最大の不平は、「誰も読まない」ということだ。誰も仕様書を読まない場合、それを書いている人たちはひがみっぽくなる。エンジニアが4インチの厚さの仕様書の山を使ってキュービクルを拡張している昔のディルバートの漫画みたいなものだ。典型的な官僚的大企業では、みんな何ヶ月もかけて退屈な仕様書を書いている。仕様書が出来上がると、それは棚に収められ、再び取り下ろされることはなく、製品は仕様書に書かれていることとは無関係にスクラッチから実装される。それは誰も仕様書を読まないから
やさしい機能仕様 パート2: 仕様書とはどんなものか? - The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/3 (パート1はもう読んだ? 読んでなければ、ここにある。) このアーティクル･シリーズで扱っているのは機能仕様であって、技術仕様ではない。人々はこの2つを混同している。標準的な用語があるのかどうか知らないが、私がこれらの用語を使うときに意味しているのは以下のことだ。 機能仕様書は、ユーザの観点から製品がどのように動くか記述する。それはどのように実装されるかは問題にしない。それは機能を話題としており、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。 技術仕様書は、プログラムの内部の実装について記述する。それはデータ構造、関係データベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものを話題としている。 あなたが製品を隅から隅までデザインするとき、最
コードを書く経営者ドワンゴ川上会長「プログラミングこそが基礎教養」 | Biz/Zine
最近の開発って宗教っぽくない? 今のプログラム開発の現場を見て「コンピュータの動作原理を知らない人が作っている」と感じているという。川上氏は、CPUや帯域などの理論から検証するが、今のエンジニアは、実験で計測して原理まで遡らない。川上氏はこれを「宗教的」とコメントした。 アジャイルとか、スクラムとかいろんな方法がありますよね。もちろん方法的には効果があるんでしょうが、ちょっと宗教っぽいなあと。どこが宗教っぽいかというと、宗教の人って、批判すると怒り出すんです(笑)。 自分が考えたり、おこなった結果よりも、誰かがやった結果に頼るエンジニアが増えていると警告する川上氏。最近会った人から得たという、半導体業界の話を披露した。 半導体って過去40年間のムーアの法則で進歩してきた。それで何か生み出したかという問の答えが「膨大な数の二流のエンジニア」なんだそうです。すぐれた回路設計や性能に注入するより
日本のソフトウェア産業は「製造業」 - My Life After MIT Sloan
これは、MIT SloanのCusumano先生が本でも授業でもよく言ってる話。 面白いから忘れないうちに書き記しておく。 Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。 日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。 そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。 Europe: Software as a science －ヨーロッパにとってソフトウェアは「科学」 Japan: Software as production －日本のソフトウェアは「製造業」 India: Software as a service －インドのソフトウェア産業は「（プロフェッショナル）サービス」 U.S.: Soft
標準と基本概念から学ぶ正しいセキュリティの基礎知識
(Last Updated On: 2018年11月6日)今回は一部の技術者が勘違いしているセキュリティ概念の話です。技術者とはWebアプリケーションのソフトウェア技術者を指していますが、他の分野の技術者にも同じ勘違いが多いかも知れません。常識であるべき知識が常識でないのが現状のようです。全ての技術者が知っておくべきセキュリティの基礎知識です。 残念ながらセキュリティ対策の定義どころか、プログラムの構造・動作原理も正しく理解されていないと言える状態です。 セキュアコーディングの構造／原理／原則 ゼロトラストとフェイルファースト ソフトウェア開発には膨大な知識が必要です。目的（ソフトウェアを作ること）以外の知識を取り入れる機会や余裕が無かった方も多いと思います。セキュリティ基礎知識を知らなかった方、安心してください！基本は簡単です。一度知ってしまえば忘れるような難しい事ではありません。勘違い
開発者はセキュリティ問題を自己解決できるのか？
(Last Updated On: 2018年8月4日)ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。 開発者はセキュリティ問題を自己解決できない 開発者はセキュリティ問題を自己解決できないことを前提とした場合 全ての開発者に安全な処理の基礎知識を教えるのは無理である 従って、開発者には「安全に処理する作法」を教えてそれを守らせる といった方針になります。 ”特定の処理”に関する安全性を向上させるにはこのアプローチは効果的です。開発者は何故ソフトウェアに脆弱性が発生するのか考える必要がないこともメリットです。 例えば、SQLクエリのパラメータによりSQLインジェクションを防ぐには、全てのパラメータをプリペアードクエリのパラメータとしてSQL文からデータを分離すると教えて守らせる、JavaScriptにパラ
コードサイニング証明書を買う前に
2022/9/21 わかりやすく一覧にしてみた かれこれ15年以上 いくつかの代理店経由でコードサイニング証明書をとり、雑誌（ハッカージャパン・白夜書房）でも二度にわたり、コードサイニング証明書の取り方を解説してきた。その経験から、これまでの取材内容と合わせて、代理店・主要価格一覧をまとめてみたので、みなさんの参考になれば幸いである。 2022年版に際して(概況) CA（認証局）ブランドの集約が進み、Symantec、thawte、Verisign は DigiCert に一本化された。これと並行して旧ブランドを扱う代理店の契約改廃が進行し、新ブランドに移行しなかった代理店（コードサイニング証明書の扱いをやめた事業者）もあるようだ。 こうした背景から2022年の日本では、DigiCert、GlobalSignのハイブランド2社と、カジュアルブランドのSectigo、2021年末から円建ての
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
今年こそ、社長が喜ぶシステム開発を
「なぜこれほど時間と金がかかり、しかも望んだシステムが出来上がらないのか」――。 情報システムの開発に対して不満を持つ社長は多い。社長が抱く典型的な疑問と開発を成功させる勘所について改めて考えてみたい。典型的な疑問として次の5点を取り上げる。 疑問1・なぜ時間がかかる 疑問2・なぜ金がかかる 疑問3・なぜ簡単にできない 疑問4・なぜ要望が伝わらない 疑問5・なぜ自動化できない ここから先の記述は社長とシステム開発に詳しい友人との対話形式にする。疑問5点に言及後、勘所を説明する。 疑問1・なぜ時間がかかる 社長：営業のやり方と組織を変えようと準備を始めたが、「情報システムの手直しが間に合わない」と情報システム部門の責任者が泣きついてきた。製品別でやってきた営業組織を顧客別に組み直す、ついてはどの顧客にどの製品を納めてきたか分かるようにしてくれと頼んだ。たったそれだけなのに「半年はかかる」と言
LasCon 2014 DevOoops
In a rare mash-up, DevOps is increasingly blending the work of both application and network security professionals. In a quest to move faster, organizations can end up creating security vulnerabilities using the tools and products meant to protect them. Both Chris Gates (carnal0wnage) and Ken Johnson (cktricky) will share their collaborative research into the technology driving DevOps as well as s
システムインテグレーション崩壊、斎藤昌義著、読了 - 未来のいつか/hyoshiokの日記
システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?を読んだ。 編集の傳さんから直々の献本。ありがとうございます。 先日読んだ、倉貫さんの「納品」をなくせばうまくいくが面白かったという日記 *1 を読んだ傳さんが送ってくれた。 刺激的なタイトルである。副題が「これからのSIerはどう生き残ればいいか？」である。このままでいいのか、いやいいわけはない、という問題意識の本である。 わたしは、SIerでもないし、SIerに勤めた経験もないので、あくまで部外者の感想にしかすぎないのだけど、本書で述べられていることはいちいちその通り、おっしゃる通りである。 IPAの「IT人材白書2014」からの引用があるが、それが衝撃的で、ユーザー企業が今後新規／拡大をしていく分野（SaaSやPaaSなど）、IDCサービスへのSIerの関心は低く、SIerの今後の新規／拡大を予定している事業に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
捨てて開発できるチームづくり
http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%883:_%E3%81%A0%E3%81%91%E3%81%A9%EF%BD%A5%EF%BD%A5%EF%BD%A5%E3%81%A9%E3%81%86%E3%82%84%E3%81%A3%E3%81%A6%E6%9B%B8%E3%81
http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%881:_%E3%81%AA%E3%81%9C%E3%82%8F%E3%81%96%E3%82%8F%E3%81%96%E6%9B%B8%E3%81%8F%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82
GSN/D-Case解説ビデオ集 - Qiita
ソフトウェアテスト入門
