イチから全部作ってみよう（3）MINORIに学べ、全ての悪は要求仕様書から生まれる
今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2．要求仕様フェーズでは何をするのか 図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。 2.1 要求仕様フェーズ ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。 取扱説明書は、一般ユーザー向けのドキュメントで、そこには「（1）以下の部品がそろっていることを確認してください……、（
中国人通訳に通じない「しょっちゅう」「ハードルが高い」「反り」
中国人通訳に通じない「しょっちゅう」「ハードルが高い」「反り」：元ソニーマンが教える「中国メカ設計事情」（1/3 ページ） 私が中国に駐在中、中国メーカーの日本語通訳に必ずといって良いほど質問することがありました。それは「『しょっちゅう』の意味を知っていますか？」というものです。 「しょっちゅう」ってしょっちゅう言っていませんか？ 皆さんはじめまして。ロジの小田淳と申します。2016年までソニーでメカ設計エンジニアとして勤務していました。2009～2013年には中国・上海に赴任し、現地部品の立ち上げに携わっていました。現在はコンサルタントとして、中国をはじめとするアジア各国でモノづくりを展開する方々の支援をしています。 さて私が中国に駐在中、中国メーカーの日本語通訳に必ずといって良いほど質問することがありました。それは「『しょっちゅう』の意味を知っていますか？」というものです。 皆さんは驚
ついに登場！ 究極の見積もり技法（その3：最短開発期間）
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」のトレードマークといえる“最短開発期間”の概要を解説する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。第38回のコラムから、パラメトリックス法の1つとして、「SLIM
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
