テンプレートトーク:ソフトウェア開発プロセス

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
ウィキプロジェクトソフトウェア/コンピューティング  (評価されたテンプレートクラス)
ウィキプロジェクトアイコンこのテンプレートは、ウィキペディアのソフトウェアの適用範囲を改善するための共同作業であるウィキプロジェクトソフトウェアの範囲内にあります。参加をご希望の場合は、プロジェクトページにアクセスして、ディスカッションに参加し、開いているタスクのリストを確認してください。
 テンプレート  このテンプレートは、プロジェクトの品質スケールでの評価を必要としません
タスクフォースアイコン
このテンプレートは、ウィキプロジェクトコンピューティングでサポートされています。
 

このテンプレートを使用する場所

このテンプレートは、アクティビティモデルのセクションのすべてのページに属しているように見えますが、必ずしもサポート分野であるとは限りません。プロジェクト管理など、後者の一部はソフトウェアよりも一般的です。--David.alex.lamb 21 39、2006年2月23日(UTC)[[返事]

XP=アジャイル

eXtremeはアジャイル手法であるため、スクラムやその他のアジャイル手法やアプローチとは対照的に、なぜサブプロセスとしてリストされているのでしょうか。--WalterGörlitz 2006年3月31日04:29(UTC)[[返事]

エントリを作成したときに、他のアジャイルメソッドよりもはるかに一般的に言及されていたからです。今では他のどの方法よりも一般的ではない場合は、おそらくそうなるはずですが、私はまだ自分でそうする傾向はありません。David.alex.lamb 07:25、2007年3月8日(UTC)[[返事]

ええと-今は構造が間違っていて誤解を招くので、誰かがそれを削除する必要があります84.112.16.84 11: 53、2007年4月15日(UTC)[[返事]

MISと混同

では、ソフトウェア開発プロセス経営情報システムの違いは何ですか... ??? @ @ ???? --Ramu50 トーク) 2008年8月19日23:10(UTC)[[返事]

1つは、ソフトウェア開発専用のプロセスについて説明しています。もう1つは、ソフトウェア開発が含まれる場合と含まれない場合がある情報を管理するためのプロセスについて説明しています。Oicumayberightトーク)2008年10月17日20:30(UTC)[[返事]

タイトルにソフトウェア工学を追加

テンプレートのタイトルにソフトウェアエンジニアリングを(再)追加しました。ソフトウェア開発プロセスソフトウェアエンジニアリングの要であり、その逆も同様だと思います。このようなテンプレートには、ドメインを記載する必要があります。

ただし、ダブリングのタイトルは完璧ではないことは認めます。たぶん、このテンプレートを水平方向に折りたためるソフトウェアエンジニアリングテンプレートとして再作成することは解決策です。このテンプレートには主な範囲がありますが、ソフトウェア開発プロセスに関連するすべての側面のより良い概要を提供するオプションがあります。現在のテンプレートの範囲はかなり限られていると思います。--Marcel Douwe Dekkerトーク)2008年10月13日08:29(UTC)[[返事]

私は強く反対します。ソフトウェア開発プロセスには、明らかに「エンジニアリング」の領域ではない部分があります。「GreatSoftwareDebates」という本の中で、Alan M. Davisは、「要件」の章の「ソフトウェア開発の欠落部分」のサブチャプターで次のように述べています。
ソフトウェアエンジニアリングは、関連分野としてテンプレートにリストされていました。テンプレートのタイトルにすることで、テンプレート内のすべて(ソフトウェア開発プロセスのすべてのステップ)がエンジニアリングのカテゴリに分類されることを意味します。まるで、すべての製品研究者、開発者、マーケティング担当者が「ソフトウェアエンジニア"。Oicumayberightトーク)2008年10月17日20:14(UTC)[[返事]
二度とあなたを紹介するつもりはありません。このテンプレート全体をソフトウェアエンジニアリングテンプレートsoneに置き換えますが、最初にさらに調査を行います。ここでの問題は、タイトルのソフトウェアエンジニアリングではなく、テンプレートがソフトウェア開発プロセスで提供している非常に選択的なビュー全体です。
今、私はソフトウェア開発プロセスがソフトウェアエンジニアリングの中心的な問題であると私が信じていることをすでに述べましたこれは単なる関連する問題ではありません。ソフトウェア開発の議論に関する1冊の本のサブチャプターへのあなたの言及は私には意味がありません。ソフトウェアエンジニアリングに関する紹介本は数十冊あります。それらの本はソフトウェア工学に関するものではないことを教えてください。--Marcel Douwe Dekkerトーク)2008年10月17日21:53(UTC)[[返事]
私はソフトウェア工学についての本があることを否定していません。それは、アラン・デイビスの主張と矛盾しません。ソフトウェアエンジニアリングがソフトウェア開発プロセスの一部であると主張しているのであれば、私は同意します。ソフトウェア開発がソフトウェアエンジニアリングによって要約されていると主張しているのであれば、私は強く反対します。Oicumayberightトーク)2008年10月18日08:35(UTC)[[返事]
「まとめた」とはどういう意味か正確にはわかりません。しかし、ソフトウェアエンジニアリングに関する本があると述べるのは、かなり控えめな表現です。ここには40年以上の伝統があります。興味がある場合は、元の2つのNATOソフトウェアエンジニアリング会議(1968年と1969年の関係からのレポート)を参照してください。これはすでに、彼らが大規模なソフトウェアシステムのシステム開発プロセスと呼んでいるものに焦点を合わせています。最近のソフトウェアエンジニアリング(研究)の本でも、同様の範囲が見つかります。しかし、私は最初に、メインタイムに起こった欲求についてもう少し勉強するつもりです。--Marcel Douwe Dekkerトーク)2008年10月18日10:09(UTC
簡単な数学的工学用語で:ソフトウェア開発≠ソフトウェア工学。ソフトウェア開発>ソフトウェアエンジニアリング。ソフトウェア開発=ソフトウェアエンジニアリング+マーケティング+他の多くの学際的なスキル。Oicumayberightトーク)2008年10月19日00:15(UTC)[[返事]
これは理論上であり、実践には適合しません。この分野を紹介し、ソフトウェア開発プロセスを中心に構築されたソフトウェアエンジニアリングの本を12冊紹介します。--Marcel Douwe Dekkerトーク)2008年10月20日20:20(UTC)[[返事]

参考文献

  1. ^ アランM.デイビス。Great Software Debates(2004年10月8日)、pp:125-128 Wiley-IEEE Computer Society Press

新しいソフトウェアエンジニアリングテンプレート

このテンプレートを置き換える新しいソフトウェアエンジニアリングテンプレートを設計しました。テンプレートトーク:ソフトウェアエンジニアリングを参照してください。--Marcel Douwe Dekkerトーク)2008年10月20日20:20(UTC)[[返事]

このテンプレートを置き換える必要があることに同意しません。このテンプレートは、ソフトウェアエンジニアリングを含むが、ソフトウェアエンジニアリングによって要約されていない学際的なプロセスに関するものです。ソフトウェアエンジニアリングは、どのプロセスよりもはるかに速く進化するスキルを表します。あなたは、「ソフトウェアエンジニアリング」の傘下ですべてのソフトウェア開発用語を独占しようとすることによって、ソフトウェアエンジニアとソフトウェアエンジニアと一緒に働く人々の両方に不利益をもたらしています。 Oicumayberightトーク)2008年10月21日03:00(UTC)[[返事]
私はここでトーク:ソフトウェアエンジニアリングに回答しました-Marcel Douwe Dekkerトーク)2008年10月21日12:58(UTC)[[返事]
ソフトウェアエンジニアリングが主な分野であると言うことで、それを過度に単純化することを試みることができます。あなたに反対する製品開発者やプロジェクトマネージャーがいると思いますが、それは問題ではありません。重要なのは、ソフトウェア開発は学際的であるということです。あなたは、あたかもそれらの機能が工学のそれほど重要でないサブクラスであるかのように、「ソフトウェア工学」の傘下で工学とはほとんど関係のない「ソフトウェア開発」の分野を引っ張ろうとしています。記事とテンプレートのタイトルは、「ソフトウェアエンジニアリングプロセス」ではなく「ソフトウェア開発プロセス」です。あなたは、開発がエンジニアリングよりも範囲が広いことを否定しています。Oicumayberightトーク)2008年10月22日00:07(UTC)[[返事]
私はここでトーク:ソフトウェアエンジニアリングに応答しました-Marcel Douwe Dekkerトーク)09:56、2008年10月22日(UTC)[[返事]
このテンプレートは、段階的にレイアウトされており、特定の段階にしか興味がなかった可能性のある人にとっては上部に非常に目立つため、より良い方法でした。ソフトウェアエンジニアリングは段階的なプロセスではないことを私は知っているので、ソフトウェアエンジニアリングテンプレートをソフトウェア開発プロセステンプレートに置き換えるのは無駄だと思います。2つの別々のテンプレートが必要です。1つはより広範なソフトウェア開発プロセス用で、もう1つはソフトウェアエンジニアリングの分野またはスキル用です。テンプレートをマージして、両方の主題を単純化しすぎています。Oicumayberightトーク)2008年10月22日22:38(UTC)[[返事]
私はここでトーク:ソフトウェアエンジニアリングに応答しました-Marcel Douwe Dekkerトーク)2008年10月22日23:41(UTC)[[返事]

現在のテンプレートに関するいくつかの質問

今のところ、このテンプレートを保持することに同意しました。要件分析などの画像に干渉してはいけないと思いますこれらの画像が最初に来るはずです。

2番目の質問。最近、データモデルの記事へのリンクを追加しました。これは、もう一度削除したほうがよいと思います。ここにリストされている他のすべての項目は、開発プロセスのモデルに関するものです!?このオフの原因は、テンプレートの目的に適合します。現在、データモデルはモデルの別のカテゴリであるため、削除する必要がありますか?

最後だが大事なことは。テンプレートは現在、プロセス開発モデルのリストを提供していますか?しかし、ここにはもっと多くのプロセスモデルがありません。多くの(古い(?))ソフトウェア開発方法論、たとえばJackson System Developmentも、開発プロセスのモデルを提供しています。今、私はここですべての新しい方法論について確信が持てません。しかし、現在のリストはかなり選択的ではありませんか?--Marcel Douwe Dekkerトーク)2008年10月23日01:07(UTC)[[返事]

最初の質問では、要件分析ページでのテンプレートの処理方法は問題なかったと思います。そのおなじみのテンプレートが上部近くにある限り、記事をすばやく読みたいだけの人のために。
2番目の質問では、データモデルを削除する必要があるかどうかはわかりませんが、「はい」と言う傾向があります。データモデルは、ソフトウェアの開発よりもソフトウェアの使用に関連しているようです。適切なソフトウェアの選択、構成、および場合によってはスクリプトやAPIのプログラミングを含む、データベース設計データベース管理システムデータベース開発によって要約された灰色の領域があることを私は知っています
3番目の質問では、その記事がある場合、あまり多くない場合はそれらを含める必要があります。プロセスが廃止された場合は、テンプレートに廃止されたモデル用の個別のセクションを含めることができます。これらのモデルの一部が新しいモデルによって廃止された場合は、それらのモデルを、違いを説明する新しいモデルの記事とマージする必要があります。記事が1、2を超える場合は、それらすべてをテンプレートから削除して、メインの記事または廃止されたモデルの別の記事にリストする必要があります。Oicumayberightトーク)2008年10月23日01:44(UTC)[[返事]
ご返信ありがとうございます。繰り返しになりますが、一度に1つずつ取るアイテムが複数あります。
--Marcel Douwe Dekkerトーク)2008年10月23日14:27(UTC)[[返事]

記事内のテンプレートの場所

上部にあるテンプレートの場所も大丈夫です。--Marcel Douwe Dekkerトーク)2008年10月23日14:27(UTC)[[返事]

ソフトウェア開発のモデル

リストされているデータモデルについて私が尋ねた質問は、実際、私が決定しようとしている問題の一部です。特にソフトウェアエンジニアリング、および一般的なコンピュータサイエンスの分野には、どのような図/モデルが存在しますか?例えば

  • ここで、論理データモデル論理スキーマ、およびセマンティックデータモデルのサブジェクトが単一のサブジェクトに関するものなのか、それとも異なるものなのかという疑問を提起しました。論理データモデルの記事でそれらをマージすることを提案しました。Talk :論理データモデルを参照してください。
  • 私はウィキコモンズにも積極的に取り組んでいます。たとえば、ここを参照してください。ここでは、コンピューターサイエンスの分野ですべての図を再構築しています。

いいえ、論理データモデルの質問に対する答えはまだ出ていませんか?そして、なぜですか?そして、なぜデータモデルをリストするべきかどうかについてしっかりとした答えを私に与えられなかったのですか?(私はあなたが持っているべきだという意味ではありませんか?)

ここでの主な問題は、これがかなり未定の分野であるということだと思います。ソフトウェア開発におけるモデルについての明確な理解と概要はありません。今、あなたは私がここで物事を単純化しようとしていると主張しました。私はここで、より明確で差別化された見方を得ようとしているだけです。ここで進歩が見込めると思います。ある種の概要が役立つかもしれません!?--Marcel Douwe Dekkerトーク)2008年10月23日14:27(UTC)[[返事]

プロセス開発モデルと方法

テンプレートのモデルのリストには、他にも理解できないことがあります。

これらはすべてここにモデルとしてリストされています。しかし、私にとっては2つの別々のことがあります。

  • ソフトウェア開発プロセスのモデル:スパイラルモデル、ウォーターフォールモデル、Vモデル

そして、私が考える他の項目(排他的なデータモデル):

  • 開発プロセスのモデルを含む開発方法。

これは違いです。私はソフトウェアegineeringテンプレートで作成しようとしています。--Marcel Douwe Dekkerトーク)2008年10月23日14:33(UTC)[[返事]

プロセス開発方法

プロセス開発方法として、ジャクソンシステム開発についてはすでに説明しました。ここで、どのような方法が存在するかを詳しく見ていきたいと思います。何十個もあるような印象を受けました。私はこれに戻ります。--Marcel Douwe Dekkerトーク)2008年10月23日14:37(UTC)[[返事]

さらに一般的なコメント

別の項目にコメントし、ここに一般的なコメントを付けてください。--Marcel Douwe Dekkerトーク)2008年10月23日14:37(UTC)[[返事]

CMM / CMMi

興味がありますが、CMM / CMMiがソフトウェア開発プロセスと見なされない理由はありますか?それは間違いなくこの分野の主要なプレーヤーであるように私には思えます。反対がなければ追加します。 —Topkai22によって追加された前の署名されていないコメントトーク投稿2009年2月3日18:54(UTC)[[返事]

これは、標準とBOKのセクションに配置されています。--Softzen トーク) 2015年8月21日12:20(UTC)[[返事]

実行可能なUMLおよびUML

次の理由で、 Executable UMLUMLに置き換えました(ここを参照)。

  • まず、UMLはまだリストされておらず、実行可能なUMLは(ただ)UMLファミリーの単一言語です。UMLファミリーの1つをリストする必要がある場合、それはUMLである必要があります
  • 第二に、Executable UMLが注目に値することは間違いありませんが、ここにリストするほど注目に値するものではないようです。スクラムRADDSDMRUP UML XPアジャイルのようなリストされた他のアイテムは、ソフトウェアエンジニアリングコミュニティの全体的な動きを引き起こしました。

実行可能なUMLは、リストされている他の項目と同様の影響を与えるようには見えません。--Mdd トーク) 2012年11月29日19:11(UTC)[[返事]

あなたの訂正は間違っています:
  • UMLは開発手法ではないため、このカテゴリには属していません。
  • 実行可能なUMLは、MDAの定義の主要な基盤であり、新しいfUMLイニシアチブのほとんどの基盤です。それがUMLの化身であるか、Shlaer-Mellor法がソフトウェア開発/エンジニアリングに大きな影響を与えていないため、それを主張するのは不誠実です。Lwriemenトーク)2012年11月29日20:09(UTC)[[返事]

私はUMLが開発方法ではないことを認識しており、UMLを一連の開発方法に含めることにすでに疑問を持っていました。それで私はそれを再び削除しました(今のところ)。ただし、現時点では、 ExecutableUMLをここにリストするべきではないと確信しています。まず、その記事に関する問題の解決を試みましょう。--Mdd トーク) 2012年11月29日20:57(UTC)[[返事]

このテンプレートは誤解を招く可能性があります

活動とステップ。ソフトウェア開発作業がこのテンプレートにリストされているアクティビティとステップに有意義に分割できるという経験的証拠の断片はありませんし、これまでもありませんでした。これらのステップは、RUP / IBM/Plan-Drivenの世界観を導きます。それらは、理想化されたエンジニアリングプロセスから翻訳された、超合理化された、過度に単純化された開発の見方を表しています。ソフトウェア開発プロセスにはいくつかの理論があります– SCI理論、FBSフレームワーク、ブーメラン–改善するために利用できますが、約20の異なる記事を変更せずにこれを修正する方法がわかりません。

方法論。スクラムはプロジェクト管理フレームワークです。TDDは実践です。XPはメソッドです。反復は、基本的にすべてを含むメソッドのクラスです。アジャイルは哲学または世界観であり、方法のあいまいなカテゴリです。VとDualVeeは架空の学術的手法であり、これまでに大きな普及はありませんでした。これらすべてを同じカテゴリにダンプすることは誤解を招く可能性があります-それは誤った等価性を意味します。

分野をサポートします。これらは私にはRUPからまっすぐに見えます。

このテンプレートを整理する方法について誰かアイデアがありますか?ポールラルフ(ランカスター大学)トーク)19:56、2013年3月15日(UTC)[[返事]

まず、自分が何をしているのかわからない限り、トークページの[編集]リンクを使用しないでください。WP:+機能を使用します。誤解を招くかどうかはわかりませんが、{{ misleading }} amboxを記事にトランスクルージョンしないでください。記事のコンテンツに問題があるか、{{ Software developmentprocess }}navboxを特定の記事に含めることについて疑問がある可能性があります。場合。Incnis Mrsiトーク)2013年3月15日20:15(UTC)[[返事]
新しいセクションに分割するパラダイムとモデルは、適切な解決策のようです。終わり。--Softzen トーク)2015年8月21日12:48(UTC)[[返事]

LAFABLE

マイク・コーンが数年前にエイプリル・フールのジョークとしてリリースした、大規模なアジャイル・フレームワークに適した大規模なアジャイル・フレームワークのパロディーWebサイトは、ScaledAgileFrameworkページおよびソフトウェア開発プロセスのテンプレートに表面上有効なリンクとして表示まし適切なコメントを付けてこれらを削除しました。これが戻ってくるのに気をつけましょう。Davidjcmorris  Talk  19:15、2017年11月14日(UTC) [[返事]