The Perfect Dev/Test Lab: 10 Principles that make it Possible
Sustainable Security Requirements with the ASVS Josh Grossman provides a brief overview of what the ASVS is, but takes a closer look at balancing trade-offs and prioritizing different security requirements. Josh shares how to make the process repeatable and how to implement it as part of your own organization's requirements process.
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
ERRP | Expired Registration Recovery Policy
Please notice: This domain name registration has expired and renewal or deletion are pending. If you are the registrant and want to renew the domain name, please contact your registration service provider. Bitte beachten Sie: Diese Domainregistrierung ist abgelaufen und die Verlängerung oder Löschung der Domain stehen an. Wenn Sie der Registrant sind und die Domainregistrierung verlängern möchten,
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
コードレビューツール 6選 どれが最適？ | Act as Professional - hiroki.jp by HIROCASTER
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
開発チームの改善効果を定量データでアピール！
開発チームの改善効果を定量データでアピール！：今日からできる“CMMI流”開発効率改善術（4）（1/2 ページ） ソフトウェアの測定は一般的に難しく、活用度も低いと言われる。どのように難しいのだろうか。それを明らかにするとともに、CMMIの考え方を適用した定量的なプロセス改善について解説する。 ソフトウェアの世界に定量的な評価は必要か 今回から2回にわたりCMMI（Capability Maturity Model Integration、能力成熟度モデル統合）の考え方を使った定量的なプロセス改善について説明します。 残念ながら、定量的な改善についてソフトウェアの世界ではあまり良い評判を聞きません。皆さんのプロジェクトでは、「この数字、自分にとっては用がないのだけど、何のために報告しているのだろうか」「バグ密度の水準って、いつも実際の数字の範囲とずれているのだけど、参考になるのだろうか」な
「ソフトウェア開発という仕事」と題して講義をしました
社内で新卒向けに講義をしました。社内固有の情報を削除した上で、下記に講義資料を公開します。 ソフトウェア開発における開発者の仕事を理解してもらうために話をしました。 講義対象者の半数以上が開発志望ではなかったので、開発者でない人が、今後、IT業界の中でどう開発者と向き合っていくかを主眼にして話しました。IT業界にいながら、開発者のことを理解できない人たち、あるいは何をしているのか分からない、と偏見を持つ人がいるからです。彼らにそうなって欲しくないからです。共感できるかは別です。考え方や価値観が違うなら違うでもいいと思います。はじめから理解を拒否していたら、いつまでもコミュニケーションが生まれません。 ついでに、半数以上が女性だったので、裏の意図として、プログラマがモテるようになって欲しいと思って話しました。プログラマがモテる世界にしたいと思っているからです。若い女性の前で話す機会を得られた
After Trying To Make Bug Tracking Fun, PlayNicely To Enter The Deadpool | TechCrunch
After Trying To Make Bug Tracking Fun, PlayNicely To Enter The Deadpool PlayNice.ly, the UK startup that set out to make bug tracking fun, is to enter the deadpool. In an email sent out to users, the company has announced that it is shutting down the service in the new year, and in the meantime has released a data export tool so that users can begin migrating away from PlayNice.ly. Co-founder, Ada
5 Rules For API Management | TechCrunch
APIs are the glue that connect apps. It’s as true for consumer apps as it is for the enterprise. API management platforms have come into vogue as apps proliferate across the enterprise. As APIs rise in importance, so has the need for better practices in their creation, development and management. All the major API management services have built strategies that they use as guiding principles when w
IT部門にビジネス感覚を持ってもらうには
Mary Shacklett （Special to TechRepublic） 翻訳校正： 石橋啓一郎 2012-11-14 07:30 IT分野の人たちは、タスク指向で動く傾向がある。そのため、実際のビジネス戦略や、そこにITがどう関わっているかが見えにくくなっている。しかし、最高情報責任者（CIO）や中心的なITマネージャーにとっては、日々の技術的な仕事に事業目標の考え方取り込むことは必要不可欠だ。なぜなら、ビジネスを動かしているものを理解すれば、それだけITを効果的なものにすることができるからだ。では、もともとこういったことに抵抗のあるITスタッフに、どう対応すべきだろうか。 これは、簡単なことではない。多くのITスタッフは、彼らが注意を集中する必要のある、重要な技術分野に注意を取られているからだ。彼らがそのものの見方から脱却して、全体的なものの見方をするようになるのは、特にいつも
時間の見積もりをどうするか？ －「仕事が忙しい！」の9割は思い込みだった【2】
完璧にスケジューリングしたつもりなのに、なぜいつも時間が足りなくなるのか。それは時間リスクの見積もりが甘いからです。 仕事の計画を立てるとき、万が一に備えて手は打ってあると胸を張る人は少なくありません。しかし、その多くは危機（ハザード）管理であって、リスク管理でないことに気づいていない。 ハザードとは、災害や事故といった事態のことであり、危機管理ではハザード発生時のリカバリーに主眼が置かれます。一方、リスクはハザードと違い、日常の中で予定どおりに進まない可能性があるものすべてを指します。たとえば「仕事中に突然、顧客が来訪する」というイベントは、けっして災害や事故ではありませんが、日常的で不確実という点では立派なリスクです。時間のリスク管理とは、こうしたイベントを事前に把握してマネジメントすることをいいます。 普通に仕事をしていれば、さまざまな時間リスクに出合います。「いざ外で仕事をしようと
状態遷移表からの実装
状態遷移表による設計手法について解説。第5回では、「状態遷移表からの実装」をテーマに、状態遷移表（設計書）から実装に落とし込むまでのプロセスとその方法について詳しく説明する。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 前回は、“状態遷移表を使用した設計モデル”をテーマに、拡張階層化状態遷移表を用いた設計手法を紹介しました。ソフトウェア開発とは、当然のことながら、設計書の作成がゴールではありません。最終的に、プログラミング（モデルからの自
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
状態遷移表を使用した設計モデル（拡張階層化状態遷移表）
状態遷移表による設計手法について解説。今回は、前回作成した要求分析モデルを基に、「設計モデル」を作成する。プログラミングを意識したモデリングを行うため、「拡張階層化状態遷移表」による表記を用いる。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です。そして、不具合発生による手戻りコストの削減や開発効率の向上にも役立ちます。 こうした理由から、組み込みソフトウェア開発の世界では、長年、状態遷移系モデルで設計が行われています。 前回は、“状態遷移表を使用した要求分析モデル”をテーマに、要求仕様から状態遷移表を作成するプロセスを紹介しました。今回は、前回作成した要求分析モデルを基に、「設計モデル」を作成したいと思います。 設計
アジャイルフィーバーによる死
アジャイルフィーバーは、一般的に、アジャイルベースのソフトウェア開発アプローチへの移行と関連する時間枠に沿った３つの段階の１つに属するように特徴づけることができる。初期、中期、最終段階である。多くの読者が正しく認識しているように、アジャイルフィーバーの一部は、非常に上手く段階に当てはまるかもしれないし、フィーバーの一部は、ある形で全段階に跨ぐかもしれない、という点で曖昧である。この記事は、 アジャイルフィーバーを完全に分類することにはあまり関心がなく、その症状を識別し、特徴づけることで、できるだけ早くそれらを認識することができ、治療することができるようにすることである。 初期段階のフィーバー 初期段階のアジャイルフィーバーは、集団的で全ての中で最も危険であり、最もかかる人が多く、簡単にかかってしまい、ソフトウェア開発の労力に損害を与える、最高の可能性を秘めている。アジャイルベースの??開発
データモデリングなきアジャイル開発は危ういか？：An Agile Way：オルタナティブ・ブログ
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
達人アーキテクト - 人類未踏の地へ勇敢に進もう
図1. ビジネスステークホルダーと重要な設計判断についてコミュニケーションするためのハイレベルなアーキテクチャスケッチ。 もののあいだを設計する あとになって考えてみると、このシステムのアーキテクトは「目に見える」ものに注目しすぎていたことがわかる。ユーザインターフェイス、ドメイン固有コンポーネント、データ管理、永続化、... しかし、アーキテクチャ上の問題はコンポーネント内ではなくコンポーネント間で発生していた。基盤となる技術インフラを含む他のシステムとのインターフェイスやインタラクション、インテグレーションで問題は発生した。アーキテクチャ仕様はこれらも辛うじて触れていたため、実際に問題が発生するまで、アーキテクトと開発者がそこに注目することはなかった。 これ対して、達人アーキテクトはもっと「もののあいだにあるもの」に注意を払っている。コンポーネントのあいだにあるもの、標準データ型の裏に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Large-Scale Continuous Testing in the Cloud
Slides from GDC 2013 talk "Under the hood of Blizzard's Internal build system"
エラーリストが静的コード解析の必要性を裏付け
