「SIをダメにする負のスパイラル」
きしだൠ(K1S) @kis SIの、元請はユーザー企業の業務をよりよくするために、プロダクトを作るんじゃなくて契約書をつくる。で、元請はそれを下請けにつくらせるんだけど、そのときはユーザー企業の業務をよりよくするためではなく契約を満たすためにプロダクトを作らせる。これが負のスパイラルの発端。 2013-11-15 08:17:14 きしだൠ(K1S) @kis 契約を満たすことが目的でプロダクトを作ってるから、実装段階で気づいたアイデアや欠陥は報告されない。納期や金額なんかの契約は満たさないといけないのに追加仕様や変更が発生してやぶへびだもん。品質は悪くなる。 2013-11-15 08:23:58 きしだൠ(K1S) @kis 品質が悪くなってとられる対策は、技術向上ではなく契約の厳密化。設計書を「きっちり」つくるとか、テストのエビデンス(画面キャプチャのかっこいい言い方)をとるとか、
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
［論点3］どんな開発手法を適用すべきか
みずほ証券がテストの件に加えてもう一つ、東証の重過失に当たるとしたのが「システムの開発手法が適切ではなかった」点だ。開発ベンダーに適切な開発手法を求めなかったため、発注者である東証も責任を免れないとする。 開発手法が適切ではないことを説明するために、みずほ証券は具体的な事例を示した。東証がソースコードを修正する際に、「モジュール詳細定義」などのドキュメントを修正していなかった点だ。 東証はこの事実を認めた上で、「一旦コーディングが済めば、その後の修正は、全てソースコードを中心に行うことが最も効率的であるから、モジュール詳細定義を改訂していなかったことに問題はない」と反論した。「コーディングが済めば、ソースコード自体が、最も詳細なドキュメントである」というわけだ。 これに対してみずほ証券は、ソフトウエア工学の専門家による意見書を引用し、こうした東証の主張を真っ向から否定した。「システムを保守
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
