Edge Components 概念、計画とインストール / WebSphere Application ServerGet equipment you can rely on at an affordable price. Shop IBM refurbished servers, storage and parts.
第5回 仕様整理に「デシジョンテーブル」を使ってみよう | gihyo.jp
はじめに 複雑な仕様を整理する。テスト担当者の仕事の1つはこれです。 ソフトウェアが仕様通りに動くかどうかを確かめるのがテストの役目です。ですが、複雑な条件が絡み合った仕様をテストする場合には、まず仕様を把握し、理解しなければなりません。これがなかなか骨の折れる作業です。 もちろん、この悩みはテスト担当者に限ったことではなく、開発設計者にとっても同じように悩ましい問題でしょう。次から次へとクライアントから降ってくる、追加の要求を、すっきりと仕様に整理して、不具合のないシステムを作ることは決して簡単な仕事ではありません。 とりわけ、やってくる要求は既存のシステムの仕様とは無関係にやってきます。追加の仕様を設計、実装する際には、既存の仕様と整合性をとらなくてはなりません。「とりあえず」、で修正してみたものの、テストをしてみると、不具合が発覚。再度修正したら今度は別のところで不具合が発生…
アジャイル契約
この資料では，サプライヤと顧客がアジャイル開発契約を成立させる方法として，４つのモデルを検討します。やがて新しいモデルが登場すると思われますが，現時点で選択肢として存在するのは，概ねこの４つのオプションです。 固定的な契約を覆す 固定された金額，固定された期間，固定されたスコープを持った契約は，依然として IT 業界における契約の標準的ベンチマークであり続けています。この種の契約は，プロジェクトの初期段階で作業のスコープを定義可能である，という考えに基づきます。サプライヤ側はこれを基準として，何が必要か – というより，何人がどれだけの期間必要か – を決定し，金額を算出します。それが完了すれば契約書が正式に署名され，実施に移されます。 このようなモデルは，提供される対象が "もの" ，すなわち一定量の専門的ソフトウェアである，という解釈を基準としています。しかしカスタムソフトウェアを購入
チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する - プログラマの思索
最近は、yuguiさんや色んな人のつぶやきに触れて、励まされたり、ハッとしたりする時が多い。 「Redmineによるタスクマネジメント実践技法」を出版してから、チケット駆動開発が今後進むべき道について再考してみた。 ラフなメモ書き。 【元ネタ】 Twitter / Yugui (Yuki Sonoda): redmineがtracの劣化クローンだった時代など最早信じられないな。機能も著しく向上し、実装も改良され、更にはいろんな先進的なプロジェクト管理の試みをするひとたちが集まるコミュニティを得た。 Twitter / Yugui (Yuki Sonoda): 一読しただけでは微妙に未消化でその時が来たらもう一度読まねばならないけど、『Redmineによるタスクマネジメント実践技法』は良い本だ。Redmineという特定の製品に依存した話はそんなに多くなくて、むしろTiDDの背景解説とパターン
バイアグラ通販ガイド | 欲しいお薬を通販で購入出来る！
人気の「バイアグラ」「レビトラ」「シアリス」といったED治療薬をはじめ、欲しいお薬を通販で購入したいとお考えなら当サイトへお越しください。当サイトではすぐにお薬を発送する通販情報を詳しくご紹介しています。
ポストモーテム 間違った反省会からの脱却/「銀の弾丸」になってしまう仕組み
List ●ポストモーテム 間違った反省会からの脱却（2006/1/1） 「銀の弾丸」になってしまう仕組み（2006/1/1） 間違った反省会からの脱却 TSP（Team Software Process）を原書で取り寄せて中を覗いてみて目に付いたのは「Chapter 10 The Post Mortem」というタイトルでした。３０数年、この世界にいて初めて目にするものでした。辞書で調べてみると「検死解剖」という意味だと分かって妙に納得したことを、いまでも鮮明に覚えています。同時に「どうしてこんなタイトルが考えつくのだろう」とも思ったものでした。（“やっかみ”が含まれていますね） プロジェクトは、多くの場合、満足な結果で終わっていません。途中で仕様変更の頻発に見舞われて混乱し、さらにテストの段階では品質問題で大幅な手戻り工数が発生し、最終的に納期を数ヶ月オーバーして終了するのです。もち
＠IT：初めてのソフトウェアメトリクス（前編）
ソフトウェアメトリクスとは ソフトウェアメトリクス（品質測定：メトリクス）とは、ソフトウェア開発をさまざまな視点から定量的に評価したものです。普段実際の開発現場では触れられることの少ないキーワードですが、本記事では「ソフトウェアの品質向上」という視点からソフトウェアメトリクスに焦点を当て、開発現場へのメトリクスの導入方法やその効果について解説していきます。 ソフトウェアにとっての品質 エンジニアなら誰もが、良いソフトウェアを作りたい、という思いを持っていると思います。ところが現実には、理想的なソフトウェアを作成するための十分な時間も潤沢な予算もなかなかないのが現状だと思います。それは、ソフトウェアの良しあし、すなわち品質ということについて、顧客と開発会社双方に十分な認識がないからです。このような“慣習”がソフトウェアの開発業界において「作りっ放しで終わり」という悲しい風潮をまかり通らせる背
仮想パネル：ソフトウェアアーキテクチャの文書化について
Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。 Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者 Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者 Eoin Woods氏, Barclays Global Inve
InfoQ: コンテキストマッピングによる戦略的ドメイン駆動設計
図１．ユビキタス言語はモデルを表現するのに用いられる唯一の言語でなければならない。チーム内のメンバは誰もが、個別の各用語についてあいまいさの残らない形で合意せねばならず、翻訳する必要がないようにしなければならない。 コードはモデルを表現する主要な形態です。要件なり設計の一部分をとらえる過程においては、それ以外の成果物も必要になるかもしれません。しかし、アプリケーションのふるまいと恒常的に同期しているのはコードそれ自体なのです。このようなモデリングの理想郷は、いくぶん脆弱なエコシステムです。前述したような条件が与えられれば実現は可能ですが、むやみに拡大することはできません。概念的統一性を妥協することなく、モデルを拡大することができる最大の範囲が、コンテキスト（"context"）と呼ばれています。 境界つきコンテキストに踏み込む ドメイン駆動設計において、コンテキストは次のように定義されてい
Webベースバグトラッキングシステム
tracpath（トラックパス）は、ソフトウェア開発で必要な プログラムとソースコードを一元化、 Git / Subversionのホスティングサービスです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Innovate2011 で公開されたソフトウェア開発のイノベーション
)
How to: Obtain Code Coverage Data
診療待ち時間を短縮したキオスク端末｜スーパーの片隅で気楽に医療サービスを受けよう - CIO Online
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
[TiDD] 制約とチケット駆動開発 - ソフトウェアさかば
Amazon.co.jp: ソフトウェア開発はなぜ難しいのか ~「人月の神話」を超えて (技評SE選書) (技評SE選書 5): 大槻繁: 本
テクマトリックス、ソフト開発の進ちょくと品質を管理する「Parasoft Concerto」
効果的な静的解析ツールを選ぶ3つのポイントとは？
検索駆動型ソフトウェア開発とそれを支援するツール (1)(インターネットコム) - livedoor ニュース
プロジェクト管理の課題解決に役立つ3つのホワイトペーパー - ＧＯ！ＧＯ！！ニュ〜〜ス！！！