タグ

ソフトウェア開発に関するbabydaemonsのブックマーク (6)

  • プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原

    「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう? と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら

    babydaemons
    babydaemons 2013/03/04
    日本的ウォーターフォール開発だとこうなるので、アジャイル的には定期的に顧客に味見してもらいますよということか。※だって高くて不味い料理食べたくないでしょ?
  • シーケンス図(Sequence Diagram) - UML入門 - IT専科

    シーケンス図(Sequence Diagram) シーケンス図とは、クラスやオブジェクト間のやりとりを時間軸に沿って表現する図です。機能ごとに相互作用(Interaction)と呼ばれる下記のようなフレーム内に処理内容を記述します。 記述例 下の図は、在庫管理システムの一機能を表したものです。 【要件定義】 店員は在庫管理画面から在庫一覧を確認できる。 この機能は、「店員オブジェクト」、「管理画面オブジェクト」、「倉庫オブジェクト」、「商品オブジェクト」から構成されている。 メッセージと呼ばれる矢印で各オブジェクト間の応答を表し、縦軸(上から下)を時系列として応答の順序を表現しています。 これにより、ある機能(例では在庫一覧)を実現する各オブジェクトが時間に沿ってどのように相互作用しているかがわかります。 ▲PageTop 構成要素 シーケンス図は次の要素で構成されます。 構成要素一覧

    babydaemons
    babydaemons 2010/11/18
    複合フラグメントの「参照(ref)」がうまく使えないって、設計が良くないのかも。もう死にたい。。。
  • アジャイルソフトウェア開発 - Wikipedia

    ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。 概要[編集] ペアプログラミング アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である(アジャイルソフトウェア開発宣言)。すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。

  • クリティカルパス法 - Wikipedia

    5つのマイルストーン(10から50)と6つの作業(AからF)がある7か月間のプロジェクトのPERTネットワーク図。このプロジェクトには2つのクリティカルパスがある。BとC、AとDとFである。作業Eは2か月のフロートがある。 クリティカルパス法(クリティカルパスほう、英: critical path method, CPM)またはクリティカルパス分析(クリティカルパスぶんせき、英: critical path analysis)は、プロジェクトの一連の活動(アクティビティ)をスケジューリングするための数学的アルゴリズムである。効率的プロジェクトマネジメントのための重要なツールである。 歴史[編集] CPMは1950年代にデュポン社が開発した。同じ頃、ジェネラル・ダイナミクスとアメリカ海軍が Program Evaluation and Review Technique (PERT) を開発し

    クリティカルパス法 - Wikipedia
  • 最適な工期は、投入人月の立方根の2.4倍らしい: ある SE のつぶやき

    最適な工期は「投入人月の立方根の2.4倍」、JUASが調査(@IT) (2007.07.06更新) 計算式が「立方根」ではなく「平方根」になっていましたので修正しました。 間違いをご指摘していただいた名無しさん、ありがとうございました! 日情報システム・ユーザー協会(JUAS)が、ユーザ企業102社の357プロジェクトを調査した結果、標準開発工期は「投入人月の立方根の2.4倍」になると発表したようです。 1000人月で計算すると、こんな感じ。 (1 000^(1 / 3)) * 2.4 = 24 24ヶ月ですね。 で、この標準開発工期を30%以上圧縮するには、無理があるとのこと。 ちょっと規模が大きすぎるので、自分がイメージしやすい20人月程度で再計算してみます。 (20^(1 / 3)) * 2.4 = 6.51460228 20人月だと、約6.5ヶ月ですか。 ふむふむ。参考になります

  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

  • 1