タグ

2011年10月9日のブックマーク (5件)

  • [課題管理編]重い課題のまま管理してはいけない

    課題管理表に、どう対処すればいいか分からない「重い課題」が載せられていたことはないだろうか。例えば高いソフトウエア品質が求められるプロジェクトにおいて、納期が迫った時点で、データ連携する外部システムのインタフェース仕様が急遽変更になり、システムの機能を大幅に改修しなければならなくなったとする。その際、「一定の品質を確保しつつ、短期間で機能を改修する」という課題が発生する。 そんな重い課題を課題管理表に載せてメンバーに任せたところで、「外部システム担当者と検討会議を開く」のようなもっともらしい解決策が書き込まれるかもしれないが、解決への道筋は示されていない。結局は解決されずに放置される可能性が高い。PMは、重い課題のまま課題管理表に載せてはいけないのだ。 ロジックツリーで課題を掘り下げる 重い課題である場合、課題管理表に記録する前に、具体的なアクション(解決策)にまで掘り下げることが大切だ。

    [課題管理編]重い課題のまま管理してはいけない
    fragarach_the_sword
    fragarach_the_sword 2011/10/09
    ITPro連載:プロジェクト・マネージャの「やってはいけない」:[課題管理編]重い課題のまま管理してはいけない
  • 「FindBugs」「Jenkins」をサポートし、不具合検出の幅が大きく広がった静的解析ツール「Coverity Static Analysis 5.5」

    2011年10月4日、コベリティは、C/C++Java、C#のソースコード解析ツールの新バージョン「Coverity Static Analysis 5.5」を発表しました。発見が難しく、誤動作の原因となるバグを効率よく検出できる同ツールの新バージョンでは、前バージョンに比べてコード解析速度が向上し、より広範囲な開発環境に対応できるよう強化が施されました。Coverity Static Analysisの特長や新機能から、ソースコード静的解析のメリットについて考えてみましょう。 テストケースの用意は不要。ビルド時に不具合を発見 「Coverity Static Analysis」は、C/C++Java、C#の各言語で記述されたソースコードに含まれるバグを検出できるソフトウェア開発支援ツールです。大規模・複雑化するソフトウェア開発において、ソースコードの不具合は、出荷遅延や修正対応による

    「FindBugs」「Jenkins」をサポートし、不具合検出の幅が大きく広がった静的解析ツール「Coverity Static Analysis 5.5」
    fragarach_the_sword
    fragarach_the_sword 2011/10/09
    「FindBugs」「Jenkins」をサポートし、不具合検出の幅が大きく広がった静的解析ツール「Coverity Static Analysis 5.5」(1/3):CodeZine
  • HTTPベースでバックドア通信を遮断する

    前回の記事で説明したように「新しいタイプの攻撃」における共通脅威パターンは5つあります。この5つそれぞれに対して“出口対策”を施す必要があります。 共通パターンを改めて見てみると、5つのパターンのうちパターン1~3の3つがバックドア通信に関するものです。つまり、バックドアに対する対策が「新しいタイプの攻撃」への対応策として有効ということがわかります。 実際のシステム設計や構築では、まずHTTPプロトコルを使うパターン1と、独自の通信プロトコルを使うパターン2に対して何らかの制限を設け、バックドアの通信を遮断します。この遮断が通過された場合のパターン3に対しても対策を施すという考え方になります(図3-1)。 80番ポートを使う通信に監視の目を光らせる まずパターン1とパターン2について見ていきましょう。パターン1と2はいずれもプロキシを経由せずに、外部と80番ポートを使って通信しようとします

    HTTPベースでバックドア通信を遮断する
    fragarach_the_sword
    fragarach_the_sword 2011/10/09
    ITpro連載:急増する標的型攻撃から社内の情報流出を防げ:HTTPベースでバックドア通信を遮断する
  • [課題管理編]ツールを押し付けてはいけない

    課題管理に向くサーバーソフトやGoogleドキュメントといったクラウドサービスなど、便利なツールを手軽に利用できる環境が整ってきた。そうしたツールを使うと、効率よく課題管理ができる。 しかし、ツールを導入しさえすればうまくいくとは限らない。特に、複数の開発現場を担当する「掛け持ちプロマネ」にとって要注意である。 掛け持ちプロマネは、それぞれのプロジェクトの管理業務に十分な時間を割けないもの。そこで「ツールでカバーしよう」と考え、課題管理のツールを現場に導入し、メンバーにツールを利用してもらって管理の効率化を図ろうとする。そして、ついメンバーにツールの利用を任せきりにしがちになる。 確かにツールは便利なものだ。だが、それを現場に押し付けてはいけない。 入力の煩わしさなどでツールが使われず このことは筆者の実体験から言える。以前に筆者が担当していたあるプロジェクトでのこと。そのプロジェクトでは

    [課題管理編]ツールを押し付けてはいけない
    fragarach_the_sword
    fragarach_the_sword 2011/10/09
    ITPro連載:プロジェクト・マネージャの「やってはいけない」:[課題管理編]ツールを押し付けてはいけない
  • [課題管理編]問題を課題と勘違いしてはいけない

    プロジェクトマネージャやリーダーにとって、課題管理はこなすのが当たり前の仕事だ。ところが現実には、この課題管理をうまく行えていないために、プロジェクトの進行に悪影響を及ぼしていることが少なくない。 課題管理がうまくいかない最たる原因は何か。そういったプロジェクトを支援することが多い筆者の経験から言えるのは、課題管理の方法(How)ではなく、管理すべき課題(What)に誤りがあるからだ。つまり、そもそも管理する「課題」の定義が正しく行われていないのだ。課題ではなく、現場で発生している事象である「問題」を管理していることがとても多い。 ここで言う課題の定義とは、「目的を達成するために解決すべき事柄」である。つまり課題管理で扱うのは、プロジェクトのメンバーが「次にどのような手を打つべきか」を検討したり実施したりできる内容になっていなければならない。 この違いを明確にするために、例を挙げよう。「仕

    [課題管理編]問題を課題と勘違いしてはいけない
    fragarach_the_sword
    fragarach_the_sword 2011/10/09
    ITPro連載:プロジェクト・マネージャの「やってはいけない」:[課題管理編]問題を課題と勘違いしてはいけない