詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
システム化の目的は、Excelの焼き直しであってはならない - GoTheDistance
これは興味深い問題提起。 エクセルでできることができない何百万のシステム・・ 「Excelで出来ることが出来ないシステムとかいうものに、なんで数百万も突っ込む必要があるのか」という話には、キチンと整理して説明できるようにしておきたいもの。 機能面ではExcelには勝てない Excelが提供している豊富な機能群は、世界でも選りすぐりのソフトウエア開発チームが途方も無い期間と金額をかけて作り上げたものです。Excelで出来る機能と同等の機能を提供することは、納期も予算も上限がある業務システム開発プロジェクトにおいて、非常にハードルの高い機能要件でしょう。業者からすると「ウサイン・ボルトに100m走で勝利しろ、期間は2ヶ月で」って言われても的な・・・ でも、「Excelとかいう最強の業務ソフトと同じこと望むなよ、そんなもん無理」で突っぱねてしまうのも違う。Excelには無い価値ってどこにあるかを
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超難関プロジェクトマネージャ試験の合格者の中に小中学生がいるようだと話題に : 市況かぶ全力２階建
