ソフトウェア開発プロセスのメタ・プログラミングは可能か?

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
ソフトウェア開発プロセスの流れを大まかに分類すると、
御存知のように{ウォーターフォール手法、スパイラル手法、ラピッド・プロトタイピング、イテレーション}等ありますよね?

各手法は、開発対象や開発主体への適合性(目的や優先項目)が異なり、その結果各工程で完了すべき事項や手順も異なり、それが各手法の存在意義となっています。

それでは、上記の各手法をカバーする、汎用の開発プロセスを表現する事は可能でしょうか?
そしてその汎用開発プロセスを、オブジェクト・モデリングして、開発プロセス支援ツールをプログラミングする事は可能なのでしょうか?

Rational RUP が何か言っていた気がします…
2デフォルトの名無しさん:02/12/02 21:44
2







「今すぐKISS ME」「Dream On抱きしめて」「恋をしようよYeah Yeah!」「胸騒ぎのAfter school」「だってそうじゃない?」「every little thing every precious thing」等16曲収録。三方背ボックス仕様です。ボックス,ディスク等なかなか綺麗だと思います。

4デフォルトの名無しさん:02/12/02 21:49
要するに、ウォーターフォールでキッチリ計画立てて分割再統治する方法しか知らないレガシー野郎に、RUP や Agile を理解させるのが目的なんですけど。
5デフォルトの名無しさん:02/12/02 21:57
意図がよくわからん
理論でプログラム組めたら苦労せんわと。

また目的と手段を勘違いしているバカがスレ立てた。
7デフォルトの名無しさん:02/12/02 22:01
>>6
「目的と手段を勘違い」意味が良くわかりません。
よろしかったら、ご高説をお聞かせ下さいませ。

>>1の文章、今読み返すとかなりわかりにくい(汗
井の頭線を下北沢で降りると学生の集団が線路に降りていく。
すわ落下事故かと注目していると彼らはそのまま線路脇のフェンスを越えていった。
どうやら無賃乗車らしい。
私がパリで書生をしていた頃、友人となったパリジャン達がよく改札を飛び越えていたのを思い出す。
東京も都市としてパリ並に成熟してきたのかもしれない。
9デフォルトの名無しさん:02/12/02 22:05
>>6
じゃあ、1を否定してやれば?
10デフォルトの名無しさん:02/12/02 22:06
>>6
「今日を一生懸命生きる」っぽい感じで、毎日の仕事をこなすのが精一杯で、
仕事の勘所を抽出して理論化できないレベルの方でしょうか?
「私」が意識する「現実」と、「彼」が意識する「現実」とが違うものかもしれない、
むしろ絶対に違うと断定できる。それどころか「私」の[現実」への「認識」が、
「私」の「現実」だけでなく、「彼」の「現実」にまで影響を及ぼしているという考え
に取り付かれたのは、目の前のちっぽけな緑色の物体
   アストラクァンタムクリノメーター
―――多重宇宙量子測量器
を手に入れてからのことだった。今から二日前の話しである。
>>1
ツールを作るのが目的なのか?
開発プロセスを改善する手がかり/足場を用意するのが目的なのか?
はっきりしる!
>>3, >>8, >>11
デムーパ発信するのはやめれ。このkitty電波野郎
141:02/12/02 22:14
大見得切った>>6はどこに雲隠れした?
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
>>1は「バカ」に過剰な反応を示しています。何か思い当たるところがあるのでしょう。
性格最悪の1だな。そりゃ荒らしも来るわ。
↓1の数倍のセンスと経験のある人の話
http://pc3.2ch.net/test/read.cgi/tech/1036148120/l50
マ板逝け
191:02/12/02 22:27
>>12
とりあえず「プロセス改善」が目的です。

巷の品質屋さん、プロセス改善屋さんは、
組織内責任体系やら、トレース可能な文書体系整備やらに注力してしまうタイプが多いのですが、
私は、プログラミングの現場で発生する問題の解決や改善に主眼を置いとりまして、
具体的には現場の凄腕プログラマに、自らの開発プロセスをプログラミングさせる事を通じて、問題を解決できないものか?と考えております。

関連スレ:■プロジェクト管理 で欲しいツール■
http://science.2ch.net/test/read.cgi/infosys/1009417487/

>>18
そのスレの何割かは、俺のレスだよ(藁
2017:02/12/02 22:29
俺が悪かった(泣
1ってほんとにバカだね。
221:02/12/02 22:33
わかれば結構。

で、現場の凄腕プログラマというのは、得てしてプロジェクト管理は嫌い or 向いてない事が多いわけですが、果たして彼らに自らの「開発プロセス」をプログラミングし、改善させる事は、可能なのでしょうか?

私の理解では、凄腕プログラマの力量が問われるチャレンジャブルなテーマだと思うのですが。
21 名前:デフォルトの名無しさん 投稿日:2002/12/02(月) 22:30
1ってほんとにバカだね。


22 名前:1 投稿日:2002/12/02(月) 22:33
わかれば結構。



爆笑。
24デフォルトの名無しさん:02/12/02 22:38
>>23
あんたの指摘で爆笑。
25デフォルトの名無しさん:02/12/02 22:38
while ( test() ) {
writeTest();
}
26デフォルトの名無しさん:02/12/02 22:40
要するに、AgileとかRUPとか、借り物の方法論を騙る事しかできない
>>17 リンク先の>>1 に爆笑
27デフォルトの名無しさん:02/12/02 22:45
>>1
開発プロセスのプログラミングって、具体的にはどーするの?
>>27
・答えられない
・奇天烈発言

の馬連で。
29デフォルトの名無しさん:02/12/02 22:55
>>28
・東京kittyのデムーパ嵐
の単勝に、1テスラ
30デフォルトの名無しさん:02/12/02 23:29
>>27
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。
結局さ、50%の人間は「3角形を塗りつぶす」 って所まで分解するのは出来るのよ
でもさ、「3角形を塗りつぶす」がライブラリにないと、どう実現するかって部分で詰まる奴が8割なのさ
さらに、水平線に分解して描画ルーチンを組める奴は1割しかいないのさ。
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


  
35デフォルトの名無しさん:02/12/02 23:39
ウゼェきえろ・・・
      ∧_∧          _ _     .'  , .. .∧_∧
     ( ´_ゝ`)   _ .- ― .= ̄  ̄`:, .∴ '     ( >>1
    /     '' ̄      __――=', ・,‘ r⌒> _/ /
   / /\   / ̄\-―  ̄ ̄   ̄"'" .   ’ | y'⌒  ⌒i
 _| ̄ ̄ \ /  ヽ \_              |  /  ノ |
 \ ̄ ̄ ̄ ̄ ̄ ̄ \__)              , ー'  /´ヾ_ノ
  ||\            \          / ,  ノ
  ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄          / / /
  ||  || ̄ ̄ ̄ ̄ ̄ ̄ ̄||          / / ,'
  ||  ||           ||       /  /|  |
                       !、_/ /
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


   
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


     
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


          
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


                      
>>30
それはどの本の何ページ?是非読んでみたいんだが。
ハァ
    ∧_∧            ((
   ( ´Д`)            ) )
  /    \          ノ
  | |     | \        ((  ((
  | | /⌒|⌒|ヽ二二つ    )    ) 丿パチパチ
  ヽ二二Ο./      \ (( (   ノノ
  (_| |_| |_       \ ∴λ∵ ←>>1
    .(__)__)       //》||ヾミ\
何でこんなに荒れてるの?
43デフォルトの名無しさん:02/12/02 23:58
>>31
「部品化&再利用至上主義」ですか?
グラフィクス・プリミティブのコーディングでしたら、
アルゴリズム本&ライブラリを探せばすぐに対応できますが、
「何が再利用に値する共通構造か?」
「いかにして再利用可能なフレームワークを構築するか?」
「時代の変遷と共に変わりうるアーキテクチャから、
 その上に実装する業務ドメインのオブジェクトを、
 いかに分離し再利用可能にするか?」(MDAとかRASとか出てますが)
てな感じで、まだまだ同意がとれていない問題が、多数あると思います。
44デフォルトの名無しさん:02/12/03 00:00
>>42
kittyちゃんが、その恵まれない己の人生の憂さ晴らしをしているから。
45デフォルトの名無しさん:02/12/03 00:04
test
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う
47デフォルトの名無しさん:02/12/03 00:06
>>1
とりあえず、荒らしのレス削除依頼だしてきて。
ちゃんとした議論をしてれば荒らしはいなくなることが多いよ。
>>43=>>1なんだろうが、用語ばっか出してピントはずれのような……
>>31は「できる人できない人」の話でしょ。
49デフォルトの名無しさん:02/12/03 00:12
>>40
どの分野で仕事してる方ですか?(w
最近本を読んだのは何時で、何の本ですか?(f

例えば、ユースケース駆動とか、テスト駆動は、
それぞれ、顧客要求の実現とか、コーディング対象の仕様化と検証、
に関して明確な方向付けをしており、
「顧客要求の実現度」とか、「ソフトウェア構成要素の仕様の明確さ」
といった内部指標が存在する事を示していると思います。
50デフォルトの名無しさん:02/12/03 00:13
>>48
 >>43 は、話がずれずれですね
5150:02/12/03 00:19
つーか。
>>43 は、できる人:できない人 の比率こそが、
プログラム開発の成功に関する指標、と言いたいんだろうが。

グラフィクス・プリミティブのコーディングで、
素朴にアルゴリズムを思いつく人、あるいはアルゴリズムを暗記している人、
なんてのは、かなり勉強の足りない部類だと、私は感じますが…

そんなテーマ以外に、考えるべき事柄は、たくさんある。
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う
56デフォルトの名無しさん:02/12/03 00:40
>>46
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
62デフォルトの名無しさん:02/12/03 00:58
<閑話休題>

開発プロセスのプログラミングする前に、
嵐の人格矯正プログラミングを議論した方がよさそうだな(藁

</閑話休題>
63ジョソ ◆WQidKPmoYU :02/12/03 00:58
そんな事書いてると、また嵐が来るぞ
>>62
っていうか>>1がしゃべらないと言うのも手だと思うぞ。
65デフォルトの名無しさん:02/12/03 01:02
荒らしにレスするとスレ汚しになるだけ。あぼんされるわけだし。
放置しる!
【隔離】煽り厨に告ぐ!【座敷牢】
http://pc3.2ch.net/test/read.cgi/tech/1038844519/l50

妙なスレまでたったな・・・。>>1の仕事だろうか?
67デフォルトの名無しさん:02/12/03 01:12
/|         |  |_____
  |         |  | ̄ ̄ ̄ /|
  |         |  |   / /
  |        /\ |  /|/|/|                           ド
  |      /  / |// / /|  12月3日だ                 ド
  |   /  / |_|/|/|/|/|   \ │ /                ド
  |  /  /  |文|/ // /    / ̄\                ド
  |/  /.  _.| ̄|/|/|/.    ─(゚ ∀ ゚ )─   (´⌒;;       ド
/|\/  / /  |/ / 秩    . \_/ (´⌒;´⌒;;(´⌒;;    ド
/|    / /  /ヽ         / │ \(´⌒(´⌒;;// 今 (´ド
  |   | ̄|  | |ヽ/l  父         ∩ ∧ ∧∩//( 日 ;(´⌒ド
  |   |  |/| |__|/     ∩ ∧ ∧∩\(゚∀゚ ) /(´⌒も (´⌒ド(´⌒;;
  |   |/|  |/   夜    \(゚∀゚ )/ |    /   さ ⌒;;(´ド;;
  |   |  |/           |    〈 |   |/ い ⌒(´ド⌒;;(´⌒;;
  |   |/     祭      / /\_」 / /\」 た (´;;ド(´⌒;;
  |  /                ̄     / / (´⌒;ま  ド
  |/       /                ̄   /   ド
つか、可視化と文書化の違いに必死になってる人がいて、笑えた。

 
70デフォルトの名無しさん:02/12/03 16:05
>>6
また目的と手段厨ハケーン。
71デフォルトの名無しさん:02/12/03 16:08
RUPは分る人には分る。とにかく一度教科書読んでみれ。
72デフォルトの名無しさん:02/12/03 17:44
>>71
このスレの趣旨と、どう関係があるのか教えてくれ。

RUPの開発プロセスってこんな感じでしょ。

 顧客要求をユースケースで表現
 ↓
 概念モデル作成(分析)
 ↓
 実装モデル作成(設計)←
 ↓↑            |Iteration
 実装モデルを実装   |
 ↓↑            |
 テスト−−−−−−−→

これって、手続き的なプログラムみたいだよね?

RUPに限らず、
開発プロセスをカスタマイズしたり、
開発プロセスの実行を支援/モニタリングするための、
汎用の方法論とかフレームワークって、
ないんでしょうかねぇ?
結局、よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


  

74デフォルトの名無しさん:02/12/03 20:55
「成果物主義」ISO9000でやりがちな、作業をトレース可能な文書体系の構築なんてのは、
       品質保証活動の成果物を「品質の向上」でなく審査に通る「文書」に設定
       した事で、落とし穴に嵌ってるよね。
       つう意味で、不適切な成果物主義は×。

       #最近は、捏造可能な「品質指標」を報告させるんじゃなく、
       #ソフトウェア成果物を個別に識別・構成管理して、それぞれの品質を測定
       #するっつう当たり前の事を、ようやく重視しだしたみたいだけど。
       #また実際のソフトウェア開発活動とは無縁の袋小路に嵌らなけりゃいーけど。

「計画至上主義」:「スケジュールは絶対変えるな。代りに目標を下げろ」ってな話もあるらしいけど…
       なんか、曲解してとんでもない方向に引きずり込まれそうなやり方って気はする。

       #確か、計画経済って、破綻したんだよね?

「プロセス・モニタリングと人手による修正」:
       主旨はわかるんだけど、理解力が低いをっさんが決定権を振り回す
       修羅場しか想像できない…
       
       
       
>>70
ん?
ツール作るときは、開発方法論なり開発プロセスとの関係が重要だと思うけど。
君の「目的」とやらは何なの?
>>1
> ソフトウェア開発プロセスの流れを大まかに分類すると、
> 御存知のように{ウォーターフォール手法、スパイラル手法、ラピッド・
> プロトタイピング、イテレーション}等ありますよね?
あれ、まだこんな詐欺方法論に騙される馬鹿が存在したんだ。

現実を見ろよ。特にデマルコの本はお薦めだ。
>>76







                 ま た 本 厨 か 








>>76
詐欺って、、、君はデムーパか?
>>1は、プロセスの「流れ」だけに着目しても、
上に挙げたような分類ができるって話だよ。

閑話休題
最近、構造化以降を知らない、知恵遅れな化石人種の話しを多少は理解してやるために、
トム・デマルコの「構造化分析とシステム仕様―目指すシステムを明確にするモデル化技法」
  http://www.amazon.co.jp/exec/obidos/ASIN/4822710041/qid=1038917896/sr=1-1/ref=sr_1_2_1/249-8443964-6033134
なんて買って、たまーにちらちら見てるけど、
DOAとかOOAとの連続性が感じられて、古代の文献としてはなかなかいい線逝ってると感じましたです。
7978:02/12/03 21:30
知恵遅れは、言い過ぎたかもしれん。

計画経済と関連付けて言えば、
「計画至上主義で、経済原理と技術革新を無視して、
 予測可能な強制労働をやらされて、
 すっかり時代から取り残されてしまった囚人連中」
くらいが妥当かもしれん
1は人と対話する器が無いみたいだね
「開発プロセスのオブジェクト・モデリング」までたどり着くには、
まだだいぶ時間がかかりそうだな(w
82:02/12/03 21:36
>>80
ん?どうゆう事?
ジサクジエンしまくってるから、
第三者が読んだらそう見えるかも(爆
>>82
「1は人と対話する器が無いみたいだね」
『ジサクジエンしまくってるから、第三者が読んだらそう見えるかも(爆』

確かに会話が成立していない。
じゃぁ、>>1の線に沿って、
君が寝た出ししてくれ。

しばらく付き合ってやるから
85デフォルトの名無しさん:02/12/03 21:46
>>83
寝た振りまだぁ〜?眠いよぉ〜
>>83
やっぱり常駐煽りかよ。相手して損した
2分で物事を放り投げる素敵な方ですね。
素敵だなんて、、、ずばり的中ですよ
で、寝た振りまだぁ〜?
>>81
どうだろうね
91デフォルトの名無しさん:02/12/03 22:15
RUPで全て上手くいくと考えるやしは隠れヘーゲリアン。
あんなもので現実的な問題が全て片付くと考えるなら
結果はソ連のようになるでしょう。

個々の問題に大して柔軟に対処しろっていう当たり前の主張に、
Agileとかいう名前がついているのかな?おれはよく知らんけど。
ふーん

#ごめん、よく判りもせずに、言葉を振り回すタイプなんだ…
ふーん

#よく判りもしない言葉を振り回すタイプですか。ご免仕ります
>隠れヘーゲリアン
禿げ藁
正直開発プロセスのメタプログラミングってなんのことか良くわからんが、
開発プロセスのメタモデルならあるよ。

http://www.omg.org/cgi-bin/doc?ptc/2002-05-04
開発プロセスってすごく興味のあるテーマではあるんだが、
1の言いたいことがよく分からないので、
何を話せばいいのかよく分からない。
というわけで、1はまず、自分の意図するところを正確に伝えるべし。

とりあえず、>>19がよくわからん。
開発プロセスを、「プログラミングする」って、どういう意味で言っているの?
まさか、開発プロセスの流れを擬似コードで書くとかじゃあるまい。
RUPにおいて開発プロセスというのは、ツールにおいて具現化する
ということになっているのだっけ。
1が言いたいのはRationalなんかが現状のソフトウェア開発状況などを
リサーチして、それをツールに落とし込むまでの作業を「手作業」で
やっているようなところ、もう少し自動化させたいということでしょうか。

まあこういったでかい風呂敷広げてる暇があるならもっと実用的な
アプリケーションを作ろうぜって俺は思うけどね。
9998:02/12/04 07:40
>>97
 つか、解釈どうもありがとう

>自動化
っつうよりも、
誰もが再利用可能な開発プロセスのメタ・モデルを探すor作って、
手作業でツールに落とし込めれば充分です、はい。

>こういったでかい風呂敷広げてる暇があるなら
2ちゃんでそーゆー真面目な反応されても、困るのだが…
つうことで、>>75 に書いてあるように、ツール作る/改造するのが主目的です

100デフォルトの名無しさん:02/12/04 07:59
100ずさー
101デフォルトの名無しさん:02/12/04 14:43
>>75
いみふめ
10275:02/12/04 18:13
誤爆ですた。>>6の間違い
1031:02/12/04 21:40
>>95
SPEMっすか、ありがd。
早速読んでみます
104デフォルトの名無しさん:02/12/12 22:58
あげてみよう
105デフォルトの名無しさん:02/12/13 00:06
橋やダムを作るときは、事前にコンピュータでシミュレーションしてから本物を作る。

大規模システムを作るときは、、、、
106デフォルトの名無しさん:02/12/13 00:07

http://petitmomo.com/mm/

ここがちょっぴりエッチ系のめぐが運営している出会いサイトです。
もしよかったら使ってみて、、、
ヨロシクです。

めぐ(^o^)-☆
107デフォルトの名無しさん:02/12/13 18:31
>>105
>大規模システムを作るときは、、、、
 どうなんでしょ?
 小規模システムやプロトタイプ・システムで検証する、
 くらいしか思いつかん。

本当は、小規模システムをベースにして、
いい意味で雪ダルマ式に大規模システムへと拡張?
できればよいのかな?

>>106
事前にコンピュータ上でシミュレーションしてから本番に移れ。
108デフォルトの名無しさん:02/12/14 16:09
で?
109デフォルトの名無しさん:02/12/14 23:34
開発プロセスって、汎用的になればなるほど、
現場の作業とは乖離してくるもんだと思うんだが、1はその辺のこと
どう考えているんだ?
現場のプログラマがやっている自動化作業と、
開発プロセスの汎用的なメタモデルを作ることに、
どういうつながりがあるのかイマイチ見えてこない。
1101:02/12/15 08:47
>>109
おっしゃる意味がイマイチよく見えません。
できれば、具体例を挙げて、もっとー具体的に説明して下さい。

特に、
>開発プロセスって、汎用的になればなるほど、
>現場の作業とは乖離してくるもんだと思うんだが、
てあたり。
汎用モデルと、具体的手法とのマッピングを考慮すべきなのは、
ツール製作者と、追加で現場の一握りの凄腕プログラマでよろしいのではないか?
1111:02/12/15 08:48
あと、
>現場のプログラマがやっている自動化作業
ってあたり、できれば詳しくお教え願えないでしょうか?

1121:02/12/15 09:04
連続レスすんずれぃ。

>>109
私が考えるには、以下の人々は、レガシー開発と現代的な開発手法との
橋渡し、ないしは、統一モデル、を必要としているように思えます。
・品質保証グループの人達
・プロセス改善グループの人達
・レガシー手法(ウォーターフォール+構造化+COBOL)どっぷりからの離脱を志している現場マネージャ
・可能であれば、レガシー手法と現代的手法両方に通用する
 「プロジェクト管理ツール」を供給しようとしている、
 社内「プロジェクト管理ツール」供給者

>>110
>汎用モデルと、具体的手法とのマッピングを考慮すべきなのは、
>ツール製作者と、追加で現場の一握りの凄腕プログラマでよろしいのではないか?
それより先にプロジェクトマネージャ。
114デフォルトの名無しさん:02/12/17 02:06
次は何?他は?
RUPは分る人には分る。とにかく一度教科書読んでみれ。
>>102
なんで?
117デフォルトの名無しさん:03/01/09 03:07
↑誤爆大魔王
======2==C==H======================================================

         2ちゃんねるのお勧めな話題と
     ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数: 138720人 発行日:2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「2ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ!

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
>>800
別に名無しは名無しですが
名無しデフォがフシアナになるわけでもあるまいし
普通の2ちゃん利用者なら、IPログ取られても困らん罠
実際 TELは無理でしょうね。
気遣いやけん制、色々多彩にあるでしょうし。要因が。

 何でもいいですが
 頭の悪くない方であると祈って

助けてくれるとありがたいです。
書けるかな
SETTINGがBBS_SLIP=
って
書き込みのIPが、保存はされてるってこと???




ウルトラマンコスモス
マ板逝け
さん
スイマセン 移動しました。
http://qb.2ch.net/test/read.cgi/sakud/1028262850/405-407n

以降 このスレでは この件は放置をお願いします。m(_ _)m。
今までの暗黙の了解が公になっただけの話では。
 
 せめて照会があってから通知しなさいよ、ログは。
 >西村

記録してもいいけどIP抹消のセキュリティを激甘にして毎日ハッカーに消してもらおう
パスワード・HIROYUKI とか
 
そういやこの頃激しく忍者さんを見かけてないな
さん
ついていきますわ!
======2==C==H======================================================

         2ちゃんねるのお勧めな話題と
     ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数: 139038人 発行日:2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ!

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
これで荒らしや犯罪予告が減ってくれると助かるんだが。
ちょっとした疑問

P2P 掲示板って昔の(今もあるけど)NetNews とどう違うの?

 
じゃ、俺も串で
前スレは、強い電波が検出されちゃったからじゃないかな。。。
匿名性に絡む問題なので反対 27% 381 票
サイトのためになるから賛成 54% 744 票
利用しないから関係ない 9% 132 票
2ちゃんねるってなに? 4% 64 票
アクセスログってなに? 3% 53 票

2chが2chでは無くなるときが来ましたね。
遊び方の解らない馬鹿が増えたから、しかたないのかもしれません。
もう転載しませんので、以後は該当のスレ追っかけてください



27 名前:心得をよく読みましょう 投稿日:03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か?

38 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:22 ID:rLfxQ17l
鋭いです。

73 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:27 ID:rLfxQ17l
>ところで、IPが抜かれて何か今までと変わることってあるのでしょうか?
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

こんなところでしょうか。
ここで3人くらいが「大丈夫だよ」と言ったら、それを信用して
そういう書き込みを続けるんですか?
まあご自由にとしか言いようがありませんね。
どうせなら「授業料」を支払うことになる限界がどこにあるか見つけてください。
プレゼント
2002年2ちゃんねるアニメランキング1位のアニメに・・・・

モナーが出演決定!!!!!!!!!!!!!!!!!!!!!

<<放送時間>>
1/12
大阪 テレビ大阪 (日)9:30〜10:00
東京 テレビ東京 (日)9:30〜10:00
名古屋 テレビ愛知 (日)9:30〜10:00
福岡 TVQ九州放送 (日)9:30〜10:00
札幌 テレビ北海道 (日)9:30〜10:00
岡山・高松 テレビせとうち (日)9:30〜10:00 
リア厨が捕まるんだろうな。
はいはい能書きはいいから
実際問題、仮に削除された奴が
削除されたことに対して文句を言っても無駄でしょ
大袈裟に語らんでよ
荒らしキタ━━━━(゚∀゚)━━━━!!!!!!
>しかし その反証の場が 2ch でなくてはならないというのは ? です。

書き込んだ人間に通知することが合理的に可能な方法としては、
2ch上(削除依頼対象のスレ)でやる以外にないでしょう。

後段はいまいち意味不明。発信者の特定は第三者機関からの要請があってから行えば十分な筈ですが?
なんで書けないのかわからないの!
148山崎渉:03/01/13 18:51
(^^)
DHCぐらいしか知らん
150山崎渉:03/01/15 18:06
(^^)
151山崎渉:03/01/23 22:15
(^^)
素敵だなんて、、、ずばり的中ですよ
153デフォルトの名無しさん:03/02/25 22:16
>>3
> 「今すぐKISS ME」「Dream On抱きしめて」「恋をしようよYeah Yeah!」「胸騒ぎのAfter school」「だってそうじゃない?」「every little thing every precious thing」等16曲収録。三方背ボックス仕様です。ボックス,ディスク等なかなか綺麗だと思います。
Project KISS ?
KISS(Keep It Simple Stupid) princlple?
154山崎渉:03/04/17 16:03
(^^)
155山崎渉:03/04/20 03:55
   ∧_∧
  (  ^^ )< ぬるぽ(^^)
156山崎渉:03/05/28 13:16
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉
PSPってどうよ
Paint Shop Pro?
159デフォルトの名無しさん:03/06/22 16:25
PSPってどうよってどうよ。
160157:03/06/22 16:27
やはり冷たい反応しかないか・・・
161デフォルトの名無しさん:03/06/22 16:30
本出てるから買って。
>>157
進捗をつけるのがだる過ぎる。怠け者ではない開発者向け。

ハンフリー博士の煩悶を読んでみるといいかも。
どうして彼らは私たちの教えを守ってくれないんだろうか
http://www.sei.cmu.edu/publications/articles/practice-preach/practice-preach.html
163157:03/06/22 17:18
レスガアッターヨ
>>162
ちと読んできます。いま\13000の本よんでんだけど、
何かウォーターフォールっぽくて今時流行んないかなあと思って。
結局、拉致監禁してたたき込むしかないと
また、プレステの携帯機の宣伝かよ
Process Dashboadってので、PSP実践環境を構築できるぞ。簡単に進捗をログできるらしい。
ttp://processdash.sourceforge.net

PSPは、統計的手法を使って"やった結果"から次に"やるもの結果"を予測するっつ〜のがキモだと思うなあ。
補修
ウホ週
ウホッ

              ┗0=============0┛
     \===========[_|_|_|_|_|_|_|_|_|_|_|_|_|_]===========/
     /三三三三三三三三三三三三三三三三三三三三\
    0 │ |∞∞∞ |::|∞∞田田田田田田∞∞|::|∞∞∞ | ::|  0
 ...[二] | ::|       |::|┏━━━━━━━━┓|::|       | ::l [二]
........|□|.│ |┌┬┐ |::|┃  /        \  ┃|::| ┌┬┐| ::|. |□|
  )三(...| ::|├┼┤ |::|┃/            \┃|::| ├┼┤| ::|`)三(´
   | ::| | ::|└┴┘ |::|┃ / ̄ ̄ ̄ ̄ ̄\ ┃|::| └┴┘| ::| | ::|
   | ::| | ::|┌┬┐ |::|┃彳 人______ ノ.┃|::| ┌┬┐| ::| | ::|
   | ::| | ::|├┼┤ |::|┃入丿ー◎-◎ーヽミ.┃|::| ├┼┤| ::| | ::|
   |: :| | ::|└┴┘ |::|┃ r   . (_ _)     )┃|::| └┴┘| ::| | ::|
   | ::| | ::|┌┬┐ |::|┃ (  ∴.ノ▽(∴  ノ ┃|::| ┌┬┐| ::| | ::|
   | ::| | ::|├┼┤ |::|┃⌒\_____ノ⌒┃|::| ├┼┤| ::| | ::|
   | ::| | ::|└┴┘ |::|┃    ┗━┛   .┃|::| └┴┘| ::| | ::|
   | ::| | ::|   ... |::|┃   . .>>1  .    ┃|::|      | ::| | ::|
.....┏━━━━━┓| .|┃          ......┃|::|┏━━━━━┓
.....┣┳┳┳┳┳┫|: |┗━━━━━━━━┛|::|┣┳┳┳┳┳┫
     ○    ●        ∫∬∫∬        ●    ○
     ○○  ●●      iiiii iii ii iiii       ●●  ○○
    [ ̄ ̄] [ ̄ ̄]   ( ̄ ̄ ̄ ̄ ̄)    [ ̄ ̄] [ ̄ ̄]
    |_○_|  .|_○_|     |_____|     |_○_|  .|_○_|
 ∧_∧ ∧_∧ ∧_∧ ∧_∧ ∧_∧ ∧_∧ ∧_∧ ∧_∧ ∧_∧
(    )(    )(,    )(,,    )    ,,)(    )(    )(,    )( ゚Д゚ )
171デフォルトの名無しさん:03/08/01 02:57
 
172_:03/08/01 03:06
173デフォルトの名無しさん:03/08/01 04:02
>>170
夏厨か。うざいな。
氏ね
174デフォルトの名無しさん:03/08/01 04:05
ここ数ヶ月のマ板の荒れ様見ると、ホントに哀しくなる。
マ板に常駐する基地外粘着、いい加減自殺してくれ
175デフォルトの名無しさん:03/08/01 04:05
ここ数ヶ月のム板の荒れ様見ると、ホントに哀しくなる。 
ム板に常駐する基地外粘着、いい加減自殺してくれ
176山崎 渉:03/08/02 02:07
(^^)
177山崎 渉:03/08/15 16:11
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン
1は人と対話する器が無いみたいだね
寝た振りまだぁ〜?眠いよぉ〜
ところで>>178は最近会社で見かけないが。
どこに転職されたんでつか(w
>ウォーターフォール手法、スパイラル手法、ラピッド・プロトタイピング、イテレーション
なんすかこれ
プロレス技の名前
ちなみに
ウォータープルーフ手法 → 滝落とし
スパイラル手法 → 竜巻旋風拳
ラピッド・プロトタイピング、イテレーション → 高速回転平手打ち
ではさっそくできの悪い部下にイテレーションをお見舞いしよう
>>181
君はソフトウェア開発管理技法をきちんと勉強すれ。
186185:03/10/09 20:29
ついでに>>1は手法と開発手法モデリングをごっちゃに表現するのをやめれ。
187デフォルトの名無しさん:03/11/14 12:28
すべてのプロセスはプログラミング可能だよ。
そういう信念のない人とは一緒に仕事したくないね。
188名無しさん@Linuxザウルス:03/11/16 17:38
>>186
確かに(笑 基礎のしっかりできていないハッタリ野郎とは、
こっちも一緒に仕事したくないわなー。

>>95
EAでSPEMサポートされてるねぇー。
漬かって無いけど、なんか萌え萌え
189オブジェクト指向促進運動:03/11/16 21:16
IT業界にアージャイル開発とデザインパターンを広めよう!

C言語を使ってかなり苦労したので
その苦労を最小限におさえるために
アージャイル開発、デザインパターンを
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

デザインパターンを使うこと、アージャイル開発することが
プログラマの習慣、常識になってほしい。

なんとか、デザインパターン文化、アージャイル開発文化を押し広げられたら・・・。

IT業界の将来はオブジェクト指向とアージャイル開発が握っています!
190デフォルトの名無しさん:03/11/16 21:20
IT業界にウォーターフォール開発と構造化手法を広めよう!

BASICを使ってかなり苦労したので
その苦労を最小限におさえるために
ウォーターフォール開発、構造化手法を
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

構造化手法を使うこと、ウォーターフォール開発することが
プログラマの習慣、常識になってほしい。

なんとか、構造化手法文化、ウォーターフォール開発文化を押し広げられたら・・・。

IT業界の将来は構造化手法とウォーターフォール開発が握っています!
191デフォルトの名無しさん:03/11/16 21:25
IT業界にごり押し開発とハッタリを広めよう!

Roseを使ってかなり苦労したので
その苦労を最小限におさえるために
ごり押し開発、ハッタリを
多くのプログラマに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

ハッタリを使うこと、ごり押し開発することが
プログラマの習慣、常識になってほしい。

なんとか、ハッタリ文化、ごり押し開発文化を押し広げられたら・・・。

IT業界の将来はハッタリとごり押し開発が握っています!
192デフォルトの名無しさん:03/11/16 21:38
IT業界にドカタ開発と偽装派遣を広めよう!

正社員を使ってかなり苦労したので
その苦労を最小限におさえるために
ドカタ開発、偽装派遣を
多くの営業に使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

偽装派遣を使うこと、ドカタ開発することが
営業の習慣、常識になってほしい。

なんとか、偽装派遣文化、ドカタ開発文化を押し広げられたら・・・。

IT業界の将来は偽経歴指向とドカタ開発が握っています!
ワロタ
194デフォルトの名無しさん:03/11/17 03:58
OO屋が言い出すことは8割方詐欺だな。ソフトウェア開発手法なんて
数理計画法的な定量的なアプローチは一切無視。OO屋の直感と
モデルの整合性だけしか見ない。アホウに本やセミナーを
売りつけるためには、そういう単純さが前面に出たものが一番だからな。
彼等自身の数学コンプレックスからも目を背けることができるしで一石二鳥。

ソフトウェア開発プロセスのプログラミングが可能だとしても
現状のような酷いものではありえないZe。オブジェクト指向を
ダメにしているのもOO屋だってことにおまいらもそろそろ気付け。
195デフォルトの名無しさん:03/11/17 04:18
>>194
OO屋って、ほぼ数学なんだけど。
定量的なアプローチは一切無視って、開発手法しらないだろ。
196デフォルトの名無しさん:03/11/17 10:03
未来(納期)を予測する最良の方法は
自分で未来(ソフトウェア)を作ってしまうことだ。

ウォーターフロー信奉者の馬鹿共の排出する腐敗して崩れ落ちそうな設計を無視して。
1971@ヴァカ撲滅運動実施中:03/11/18 14:06
>>189-192
ヴァカでしょ、君。
俺は君がどんな手法で仕事しようが、どんなに無知だろうが知ったことじゃない。
但し、自分が仕事しようがを進め易いように、周囲を巻き込むだけだが、何か?
1981@ヴァカ撲滅運動実施中:03/11/18 14:07
>>189-192
ヴァカでしょ、君。
俺は君がどんな手法で仕事しようが、どんなに無知だろうが知ったことじゃない。

但し、自分の仕事が進め易くなるように、周囲を巻き込むだけなんだが。何か?
庇うわけじゃないけど、
たしかに>>194の言うようなイメージはあるな〜。
どういうトコが定量的なんでしょうか?
200デフォルトの名無しさん:03/12/24 12:17
EnterpriseArchitectureのSPEMサポート萌え
201デフォルトの名無しさん:03/12/24 13:18
>>199はオブ脳
2chに広告と自動化を広めよう!

手動でカキコしてかなり苦労したので
その苦労を最小限におさえるために
スクリプト、荒らしツールを
多くのスクリプトキディに使って欲しいと思うことがある。

一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように

スクリプトを使うこと、荒らしツールを開発することが
自動化の習慣、常識になってほしい。

なんとか、自動化文化、スクリプト開発文化を押し広げられたら・・・。

2chの将来は山崎渉とぼるじょあが握っています!
つまんね
204デフォルトの名無しさん:04/01/05 03:11
SPEM age。つうか流行ってないだろ
いまいち意味がわからないタイトルだから何かと思ったら
>>1がよくわからないことを言い続けるスレだったんですね。
2061@ヴァカ撲滅運動実施中:04/01/07 00:25
>>205
お前みたいなアフォが居るから、
この業界の底辺レベルが低下するんだよ。
さっさと消えろ。
207デフォルトの名無しさん:04/01/07 00:26




  ◆◆「第4回 MDAテクノロジーフォーラム(MTF)」開催決定◆◆
      2004年1月28日(水)、東京・青山テピアにて
      テーマ「モデル駆動時代の開発プロセス」
         http://www.otij.org/mtf/

オブジェクトテクノロジー研究所では、2004年のMDAテクノロジーフォーラム
(MTF)新春第1弾として、「開発プロセス」をテーマにを開催いたします。

プロセス管理は、最終的なソフトウェアの生産性と品質に大きな影響を与え
るテーマであり、モデルをベースとしたライフサイクル管理を目指すMDA
における重要性はいうまでもありません。

今回のフォーラムは、RUP、SPEMなど、主要な手法や標準について、
実践的な視点から重要なポイントをおさえ、MDAとの関係を明らかにする
ことを目指します。
まず、『実録!オブジェクト指向開発プロセス』(技術評論社)の著者である、
土屋正人氏による問題提起でスタート。なぜ開発プロセスが重要か、RUPと
その適用について、豊富なご経験から得られた知見、アイデアを解説して
いただきます。会場では、書籍販売&サイン会も行う予定です。次いで、
重要な標準であるOMGのSPEM (Software Process Engineering Metamodel)
およびツールをテーマに取り上げます*。

*SPEMは、こちらからダウンロードできます。
http://www.omg.org/technology/documents/formal/spem.htm
208デフォルトの名無しさん:04/01/07 00:29
■内容と講師

◇ 午前
「UML/MDA市場概説、およびUMLフォーラム2004の開催について」
 鎌田博樹 OMG日本代表/オブジェクトテクノロジー研究所

「なぜプロセスが重要か ─ RUPとその適用 ─」
 土屋正人 (株)SRA コンサルティング部 シニアコンサルタント

◇ 午後
「OMGのプロセス標準:SPEM」
 和田周 オブジェクトテクノロジー研究所 技術ディレクター

「主要ツールとその機能、利用」
講師は近日発表します

* 詳細プログラムが決定次第、ご連絡差し上げます。

■開催概要
名称:第U期 第4回 MDA Technology Forum (MTF)
   テーマ:モデル駆動時代の開発プロセス
会期:2004年1月28日(水) 9:30-17:00
会場:青山テピア (地下鉄外苑前駅)
主催:オブジェクトテクノロジー研究所(OMG日本代表)
共催:オブジェクト・マネジメント・グループ(OMG)
協賛:(株)ニルソフトウェア http://www.nilsoft.com/
   (株)UML教育研究所 (UTI) http://www.umlcert.org/

■申込・お問合せ
オブジェクトテクノロジー研究所(旧社名:OMGジャパン)
209元F:04/01/07 00:40
このスレ荒らしてるアフォは、
元F現関連会社の彼と、
2ちゃんネイティブの常駐低脳粘着荒らしだろうな。

まったくFのレベルの低さったらねぇな。人の足引っ張るだけのマネージャ多すぎ。
210デフォルトの名無しさん:04/01/07 00:50
F本体って、関連会社から見ても、
どーしようもない屑が多すぎる。

Fって本来、子会社が新しい領域を開拓して親会社を凌駕する「新陳代謝」が本質の企業なのに、
新しい芽を潰す元F系リストラ幹部社員多過ぎ。
もう辞めちまった企業だから、自分で自分の首絞める元FDQSの痴呆っぷりには、
失笑するしかないけど。

今のFの企業発展プロセスを、UMLモデリングして、
企業体質を改善できる凄腕プログラマが、君らの部下になればいいのにねぇ(失笑
211デフォルトの名無しさん:04/01/24 09:09
>>195
>OO屋って、ほぼ数学なんだけど。
OO屋が数学を踏まえてなんかやってるの見たことないんだけど。
例えばどんなの?
なんだろ。型理論かね?
213デフォルトの名無しさん:04/02/05 22:49
↑おまえ、たかが煽り屋風情の癖に出しゃばり過ぎ。
いつもネタが一緒で、全然展開ねぇのが悲惨だな。
さっさと消えろ。
214デフォルトの名無しさん:04/02/05 22:57
どうせまたあいつでしょ、自称脳科学者、現実には2ちゃんの理系板やらニュース板に一日中張り付いてる廃人。
形式手法は?
>>215
いみふめ
217デフォルトの名無しさん:04/04/11 21:17
ソフトウェア開発プロセスのモデリング、
よく見たら 共立出版のソフトウェアテクノロジー・シリーズ本でも出てたね。

  ソフトウェアプロセス―プロセスと環境トラック ソフトウェアテクノロジーシリーズ
  http://www.amazon.co.jp/exec/obidos/ASIN/4320027817/

この本買って斜め読みしてから、このスレ立てたんだっけ。
2ちゃんには、この辺の話題に興味ある人、居ないのかなぁ〜?
あと、この辺りでいいツール、ありませんかねぇ〜?

#いま居候している現場には、この手のツールが一切欠落している。。。
#随分前に手を入れた、SourceForgeでも、提案してやろうかなぁ。。。
>>32
> 「成果物主義」
これは請負

> 「計画至上主義」
これは委任ですかね。
ほっしゅ
220デフォルトの名無しさん:04/08/26 00:24
>>218
計画至上主義って、プロジェクト計画をウォーターフォールで立ててる大抵の糞SE、糞SIerがそれだよ。

そーいや、サイエンスの研究支援に、ウォーターフォールで対応しようとする御目出度いプロジェクトや、
コンピュータサイエンスの補助金制度に重い成果物主義を課す御目出度い外郭団体もあったなぁ〜
規模や内容によってはウォーターフォールが有効な場合だってあるだろ?バカですか?
>>221

それを言ったら何にもならん
223デフォルトの名無しさん:04/08/29 22:53
>>221
おめでたいなぁ。ヲータフールで済む単純労働ばっかしてる君が羨ましいや(ぷぷ
224デフォルトの名無しさん:04/08/29 23:03
IDE
ウォータフォール=単純労働

という浅はかな図式グッジョブ
226デフォルトの名無しさん:04/09/05 22:33
まぁ、まっとうな頭脳労働者は、
大規模開発をヲーターフールで管理することはあっても、
間違ってもヲーターフールで管理されたいとは思わねぇよな、
ね、>>225単純労働者さんw
むしろ単純労働させてほしい。

オレの単価安いんだぞゴラ!ドキュメントのテンプレ用意したり、
開発手順策定したり、マルチスレッドであれこれやるほど
もらってねぇぞぉぉぉぉ ぉ  ぉ    ぉ
2281:04/09/09 21:53
今漏れは、エンタープライズ・プロセスのメタ・プログラミングをしようしてますが、なにか?
229デフォルトの名無しさん
みんな元気?上期の辻褄あわせで大変?