kizasi.jp:ブログから、話題を知る、きざしを見つけるThis domain may be for sale!
紛争勃発に備えよ！──受け入れ検査時のトラブル対策
紛争勃発に備えよ！──受け入れ検査時のトラブル対策：企業システム戦略の基礎知識（10）（1/2 ページ） 受け入れ検査において、明らかに「欠陥」であると判定できる場合は問題ないが、発注側では欠陥だと思って指摘しても、業者からは「それは欠陥ではなく、仕様書に書いてなかったので仕様変更である」と反論されることが少なくない。これは、業務という抽象的なものを対象としているうえに、要求仕様が日本語特有のあいまいな表現で記述され、発注側の意図が業者に正しく伝わっていないことが要因である。 こうした“見解の相違”は、欠陥であれば業者が無償で是正することになり、仕様変更であれば発注側が追加費用を負担する──つまり両者の利害は対立しているので、容易に紛争へと発展する。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすればよいか考えてみたい。 仕様変更か、欠陥か──それが
第1回 要求仕様に関係する落とし穴
整理術的改善ポイント では、ここから改善のポイントを1つずつ解説していきます。 （1）要求仕様書とリリース製品が正しく保管されていること （2） 要求仕様書とリリース製品が関連付けされていること まず、製品開発時に参照すべき唯一の要求仕様書が、正しく管理されていることが大前提として挙げられます。正しくとは、管理されている要求仕様書が間違いなく参照すべき唯一の要求仕様書であることを識別できること、開発メンバーの全員が同一の要求仕様書を参照していること、勝手な改ざんができないことを意味します。この大前提が成り立っていれば、少なくとも、開発メンバー全員が、同じ要求仕様書を基に同じものを開発しようと試みているといえるわけです。 次に、この要求仕様書を基に出来上がったリリース製品について、いつでも誰でも、要求仕様書とリリース製品を一対一で特定できることが重要です。このためには、何らかの手段で対応を識
Trivial Tracks: Javascriptのクロスブラウザライブラリ
Javascriptを少しでも自分で書いたことある人は、各種ブラウザ間の共通性・互換性の弱さにため息や頭痛を感じた人も少なくないのではないでしょうか サイト上にスクリプトが記載されていて、それをコピペして借用する方法もあるが、経験上こういうコードは意外と完成度が低く、自サイトでは挙動がおかしいということが多々ある。 こう思った人がブラウザ間の差を吸収したライブラリを誰か提供してくれているに違いないと思い探してみるとまず最初に引っかかったのがPrototype.js。 残念ながらこれは間違いではないが、目的がAjaxに重点を置いているため古いブラウザは問題外となっている。 ちなみに正式対応なIEバージョンは6以降と書いてある。 そしてやっと探しあてたのが以下で紹介されている「X Library」 http://www.cross-browser.com/ これの完成度は本当に素晴らし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
